11 Σεπτεμβρίου 2018
Posted by Madan Ankapura, Product Manager, Android
This is the first in a series of blog posts that outline strategies and guidance in Android with regard to power.
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:
In Android 9 Pie, we made further improvements based on these three principles:
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 |
JobScheduler | JobScheduler |
Firebase JobDispatcher | Firebase JobDispatcher |
Background Service | Jobscheduler |
Foreground Service | Foreground Service with action to STOP service |
We recommend the following strategy given the importance for app developers to invest in the right design patterns and architecture:
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.
We will be publishing a series of design pattern guidances in the upcoming weeks. Stay tuned.
Learn more about the Power Series here.
Acknowledgements: This series of blog posts is in joint collaboration with Android Framework and DevRel teams.