This story was originally published and last updated .
Power management on Android has always been a very real problem. While Google has done what it can over the years to improve battery life (with success, I’d argue), some smartphone companies still don’t think it’s enough. Many make their own adjustments on top of so-called “stock” Android, and in many cases these modifications interfere with normal operations, resulting in issues ranging from delayed notifications, to prematurely killed apps, and even outright breaking behaviors that developers rely on. In fact, the lack of predictability that has ensued under the current laissez-faire power management scheme has become so dire that it recently took the top spot in a developer AMA request thread for Android 11 on reddit. Ultimately, this results in an inconsistent experience for both app-makers and end-users like you and me, and Google needs to put its foot down.
An emergent problem
For a bit of context, back in 2015, Google implemented a feature called Doze with Android 6.0. In essence, it was one of the first times that Android seriously broke the behavior apps could plan around when it came to running in the background, suspending them in a sort of deep sleep mode when the phone was unplugged, stationary, or otherwise not in use. The feature demonstrably improved idle battery life, but apps had to start specifically planning around the effect it would have. Still, it was a single set standard bundled into stock Android that developers could work around with things like Firebase.
Starting in Android 8.0 Oreo, Google further imposed background execution limits that trimmed down the sort of resources available to apps when they aren’t active and in the foreground, and developers that needed to keep their apps or services active in the background had to use an ongoing notification to do it. It was a bit annoying, but in its own way, that was an elegant solution: Developers could keep background functionality, but they had to be more up-front about it, and users were continuously aware of it via that notification.
By themselves, these sorts of changes may have broken certain behaviors developers relied on, but they weren’t really a problem. They were defined, documented, and predictable — developers could modify their apps to plan around these new rules because they knew what to expect.
However, Android as a platform has always allowed manufacturers to make tweaks and on top of the “stock” system, and most of them have taken that opportunity to add their own unique behavioral changes to try to further improve their products’ battery life. Some simply modify a few of Android’s variables to stretch out the time between scheduled wakes, others impose whole “intelligent” systems with machine learning models that dynamically adjust multiple variables in a way that’s ostensibly tuned so that customers won’t notice it. The problem is that even with the best tricks, these changes can break things for both customers and app developers.
How does this affect you?
it’s unreasonable to expect customers to tweak settings for apps to work as they should normally.
Anecdotally, many of us are probably familiar with issues like delayed notifications, which is one of the details most commonly affected by these sorts of changes — things like seeing notifications for messages or app alerts land minutes after they should. As an example, it’s an issue that OnePlus devices have suffered for a long time. Pretty much all of us at Android Police with OnePlus devices recognize delayed notifications as a problem with Oxygen OS and the company’s phones. And it’s kind of a bummer: Notifications are one of Android’s biggest advantage as a platform, and pretty much everyone agrees it’s way better than the notification experience on iOS. Yet Google gives phone manufacturers free rein to ruin it.
Notifications aren’t the only things that are affected, though. Applications that run in the background like activity or sleep trackers (and even media broadcasters like Hulu or Netflix, in my experience) can run into problems with being prematurely killed as a result of overly aggressive power management.
You can usually fix these issues on a per-app basis by disabling “battery optimization” in Settings (though Oxygen OS has a record of wiping your exemptions). But it’s unreasonable to expect customers to tweak settings for apps to work as they should normally. And for folks that aren’t too tech-savvy, this is a pretty deeply hidden setting — Google’s intent was clearly for it not to be frequently changed, and yet some manufacturers force you to just to make apps behave more normally.
Worse: How does this affect developers?
These sorts of modifications to Android’s stock behaviors are such a consistent problem that most developers I spoke to for this story claimed they can actually track which OEMs are making their own heavy-handed changes simply by looking at their Play Store reviews: Customer complaints and negative reviews for apps that rely on background behaviors being predictable are significantly higher for users with phones from companies that make these kinds of aggressive changes to Android. The folks I spoke to specifically called out OnePlus, Xiaomi, Huawei, and Samsung as some of the most frustrating offenders.
Don’t kill my app!’s top six lowest smartphone rankings.
Our readers are also likely familiar with the Don’t kill my app! site, which documents which smartphone manufacturers impose their own arbitrary changes to power management, together with a handful of workaround for each company’s software. According to that site, Meizu and Asus are also problematic. In fact, pretty much everyone but Google and HTC makes some changes that can result in apps breaking, though some companies like Nokia and Sony have been a bit more restrained.
Sleep as Android (and Don’t kill my app!) developer Petr Nalevka tells us that although “we are getting tons of reports from Huawei, Xiaomi and Samsung” that “OnePlus is really the most problematic OEM if you consider the amount of phones they produce.” Tomas Hubalek of the popular Battery Widget Reborn also says that OnePlus users request support for related problems far more frequently than users with other devices and that the company “went too far with their battery optimization… they sacrificed [their] customer’s experience,” while also incurring extra costs for developers like him as a result of increased support overhead. Other developers and users also chimed in with similar angst when we asked about the issue on the Android Developer subreddit (before the scope of our article expanded to discuss how it affected phones outside OnePlus).
I should note, we repeatedly reached out to OnePlus for comment over several weeks while researching this story, given the company said it would change its own overly aggressive background app management last year, but although we were told it was being looked into, it never provided us with any information or statement. Developers that we spoke to also confirmed that OnePlus doesn’t seem to have made any beneficial changes in that time.
As part of this story, Nalevka made a benchmark for us (appropriately also called DontKillMyApp) to better document these issues, since we actually ran into trouble using his company’s Sleep as Android app to try to measure it — it kept getting killed in the background in the middle of the night on my OnePlus phones. His new benchmark is still a work in progress, but it does things like set repeating tasks and scheduled alarms tied to a background service, and measures how frequently results deviate from what developers can and should expect. In fact, the results give you an interesting visualization of precisely how each manufacturer changes things, because each of them does things a little differently.
Results measured by Nalevka for a Huawei phone (left) and Pixel 4 (right)
We haven’t managed to test every device we have on-hand yet, but Google’s Pixels deliver results that are reliable enough to “work as a clock,” in the words of Nalevka, scoring at or near 100% across the board in most benchmarks. In our testing, OnePlus devices running Android 10 varied from 40% up to 96%, with almost no rhyme or reason, though we consistently saw results that would indicate problems for developers.
My own results for a Pixel 3a (left) and the latest OnePlus 8 (right).
In short: Although not all our readers may have run into these issues, although it may not affect all apps, and although different OEM tweaks can break behaviors in subtly different ways, these changes are a clear, documented, and measurable problem for developers. And, for whatever reason, it’s a problem that Google has ignored.
From a certain perspective, Google also gets an unfair advantage here in its combined role as an app maker for the platform that it develops. Google’s Android source documentation says that pre-loaded system apps are usually exempted from these sorts of limitations, meaning that Google’s own apps probably won’t run into these sorts of problems with delayed notifications or background killing. It’s only third-party developers who might be trying to compete with Google’s apps and services that have a problem, and that’s not really fair.
Why won’t manufacturers fix it?
Speaking to XDA Developer’s Mishaal Rahman, who is among the more prominent experts we were able to track down on the subject of background apps and power management in Android, the root of this whole problem comes down to a lack of Google Play Services in China. On Android, Play Services offers an easy, unified notification framework that developers can easily take advantage of. But if developers in China (or international developers also targeting China) want to ensure wide compatibility for their apps, they can’t rely on Play Services to be there, so many of them simply rely on separate notification frameworks. That can mean dozens of apps all using dozens of different frameworks, with dozens of superfluous background services to wreck your battery life.
Chinese manufacturers “fixed” this in 2017, and thus the issue we’re discussing here today: Their solution was to impose their own strict and draconian modifications to power management, memory management, and background apps in Android. We don’t have an explanation for why these companies don’t revert these heavy-handed tweaks for international audiences — it could be that the ease of a shared codebase is to blame, and Rahman speculates product managers may simply believe it’s not actually a problem. If and when Google puts its foot down, these changes can’t be reverted in China either: Customers there would complain about bad battery life with dozens of notification services getting free rein again.
The ball is in Google’s court
We might get more information out of Google about this problem soon, though. The Android engineering team is doing an AMA tomorrow, and as of right now, a question regarding this precise issue is fortuitously the most upvoted one in the AMA. We reached out to Google earlier today to see what the company’s response to that question might be ahead of time (since we’ve been planning our own coverage for some weeks now), and though we’re told the subject will be addressed, the company wouldn’t share its response with us before tomorrow.
The top question on tomorrow’s AMA.
Ideally, we’d like to see Google step up and restrict how Android phone manufactures can make these sorts of changes. While it can’t force them on the Chinese domestic market — where Android is free to use and modify given the nature of open-source software — the company can impose more strict limits as part of its Play Services GMS licensing requirements.
Only Google can fix this.
Whatever solution Google goes for, though, the current situation is untenable. There’s a lack of documentation for developers trying to work around all the various smartphone manufacturer customizations related to background apps and power management, and it’s ridiculous to expect them to even have to. With dozens of OEMs, hundreds of different “Oxygen OS” and “OneUI” versions, and thousands of devices that all might be doing things slightly differently, just reliably delivering a notification on your phone can be a developer nightmare, and Google’s supposed to be fighting this sort of fragmentation, not ignoring it.
Skin-level software customization and exclusive new features from smartphone manufacturers are one thing, but Android should otherwise be a universal experience for both customers and developers. Only Google can fix this. And if the company continues to ignore the problem, it may as well be encouraging it.
Google AMA answer
Google has responded to the question in the AMA:
Expandable embed of the response.
In short, Google is going to update the Compatibility Definition Document (CDD) documents for Android 11 to make it clear users need to be notified when their apps are interfered with in this way, and it will more stringently enforce existing requirements for things like behavior whitelists and other policy violations.
I don’t think this effort goes far enough, and I have a whole lot more to say about it here, but at least Google is aware of the issue. It’s just too bad developers aren’t getting a real solution. Although it doesn’t sound like it, I hope Google can play hardball in its ongoing discussions with manufacturers, and get them to knock it off.