Your users care a lot about battery — if it runs out too quickly, it means they can’t use your apps. Being a good steward of battery power is an important part of your relationship with the user, and we’re continuing to add features to the platform that can help you accomplish this.
As part of our announced Play policy about improving app security and performance, an app’s target API level must be no more than one year older than the current Android release. Keeping the target API level current will ensure that apps can take advantage of security and performance enhancements offered in the latest platform releases. When you update your app’s target API level, it’s important that you evaluate your background and foreground needs, which could have a significant impact on power & performance.
Past releases of Android included a number of features that helped manage battery life better, like:
- Job Scheduler in Android 5.0 Lollipop, which allows deferring work
- Doze and App Standby in Android 6.0 Marshmallow, which disables network access and suspends syncs and background work – when device or apps are unused for a prolonged period.
- Doze improvements in Android 7.0 Nougat, which applies a subset of Doze restrictions when the screen is off and not stationary.
- Background limits in Android 8.0 Oreo, which prevent background services and throttle location updates.
In Android 9 Pie, we made further improvements based on these three principles:
- Developers want to build cool apps
- Apps need to be power-efficient
- Users don’t want to be bothered to configure app settings
This means that the OS needs to be smarter and adapt to user preferences while improving the battery life of the device. To address these needs, we have introduced App Standby Buckets, Background Restrictions, and improved Battery Saver. Please test your app with these features enabled on a device running Android 9 Pie.
Battery Saver and Doze operate on a device-wide level, while Adaptive Battery (app standby buckets powered by a Deepmind ML model) and background restrictions operate on a per-app basis. The diagram below helps understand when a scheduled work will run.
As you update your apps to target Oreo or above, please review this checklist and follow the below table for background work
|Currently Using||Porting to Oreo|
|Firebase JobDispatcher||Firebase JobDispatcher|
|Foreground Service||Foreground Service with action to STOP service|
Note: when the WorkManager API becomes stable, we will be recommending WorkManager for most of these use cases
We recommend the following strategy given the importance for app developers to invest in the right design patterns and architecture:
- Do the needed work when the user is actively using the app
- Make any work/task that is done in the background deferrable
- Use foreground services but provide an action in the notification so user can stop the foreground service
Similarly, other OS primitives like alarms, network, and FCM messages also have constraints that are described in the developer documentation on power-management restrictions. You can learn more about each of these features via Google I/O presentation, DevByte and additional power optimization developer documentation.