Google's Android AMA is underway, and the team's engineers have already answered the most hotly-anticipated question: How will Google fix the problem of inconsistent background limits across different manufacturers and devices? It's a long-standing problem where overly aggressive power management tweaks break functionality in plenty of apps, resulting in a headache for developers and frustration for users. According to the AMA, Google does plan on making a few changes to help fix things, but the company isn't doing all that it could.
We've been anticipating the answer to this question since it took the top spot of the Android team AMA last week. Before news of the AMA was even released, we'd been working on our own coverage of the subject (which went up just yesterday). In short: Android's open-source nature means that phone manufactures can make some pretty heavy-handed changes to it. That's one of the platform's benefits, but it's also a drawback, because it means manufacturers can come up with their own methods for things like power and memory management, sometimes in ways that kill the default behaviors developers expect and rely on.
It's such an issue, there's a whole site dedicated to keeping track of which manufacturers do it, and how to work around those problems for each one. But that doesn't solve the fundamental issue of it happening in the first place, and the effects can be significant. For some of us, it might just mean delayed notifications, but it can also kill apps we rely on to do stuff in the background, like geofencing and activity or sleep tracking, among plenty of other things.
Google could impose a strict limit, benchmark, or test for expected background and notification delivery behaviors via its Google Mobile Services licensing agreements — which are required for manufacturers to get access to the Play Store, Play Services, and other Google apps — but according to today's answer, the company won't go quite that far (though I believe it should). Instead, it will be updating its compatibility definition document for Android 11 "to make sure device manufacturers are alerting users of app restrictions in a timely manner," — in other words, to let customers know if and when their apps are interfered with as a result of power management, and let them override that action if it happens, probably via a notification.
According to Mishaal Rahman, the proposed language changes are as follows:
If device implementations implement proprietary mechanism to restrict apps and that mechanism is more restrictive than “Rare” standby bucket on AOSP, they:
[C-1-5] MUST inform users if app restrictions are applied to an app automatically. (NEW) Such information MUST not be provided earlier than 24 hours before such restrictions are applied.
(Note)Force Stop is considered to be more restrictive than "Rare" and MUST comply all requirements under 3.5.1, including new 3.5.1/C-1-5
Google further reiterates that it doesn't allow manufacturers to create "allow lists" for apps that circumvent these behaviors, since it hinders competition — though we're pretty sure manufacturers like OnePlus are doing it anyway, given the inconsistency in delayed notifications on messaging services on that company's phones. It also claims that "top manufacturers" have fixed such issues in the latest builds for major flagship devices.
An expandable embed of the AMA question's answer.
Developers can also take advantage of that new crash reasons API to see how and why their app crashed — not that it really matters for customers, and not that developers can actually do anything about it, if it's a result of overly aggressive power management on the part of manufacturers. (I guess it's just nice to know there's nothing you can do when it happens?)
I'd argue these steps really aren't a solution to this issue, though. The CDD change doesn't go far enough; manufacturers have clearly been flouting CDD restrictions already since Google's straight-up pointing to the fact that CDD violations have been fixed in more recent releases. And it's almost impossible to educate customers about this issue, given how technical it is, so they're simply going to continue to point the blame at developers if and when they run into problems.
Google should have its developers' back on this issue, and the company can and should do more here to fix this problem, and I see this as passing the buck. More optimistically, though, at least the problem is actually on Google's radar, and the company should be thinking about it going forward. Hopefully, we can see more stringent steps taken in the future.