Android 9 Pie’s Adaptive Battery: Your application may be heavily impacted

Android 9 Pie (API level 28) introduces a new battery management feature: the Adaptive Battery. Depending on the user’s use of the applications, the system will restrict certain mechanisms for the applications.

New feature on Android 9 Pie : Adaptive Battery

The system prioritizes the use of resources on the frequency of use of applications and their recent date of use. 5 classes of applications (buckets) have been implemented:

• Active: The user frequently uses the application. Some architectural criteria are also taken into account: starting activities, foreground service, user clicking on a notification …
• Working set: The application is used frequently but is not always active. For example, a social network application will be assigned as Working set. An application used indirectly will also be in this class.
• Frequent: The application is used frequently but not necessarily daily.
• Rare: An application used irregularly. For example an airline flight reservation application for an individual.
• Never: The application has been installed but has never been used.

The algorithm is based on artificial intelligence (AI), it’s likely that the learning phase will take several days. However many applications will likely be assigned to the Frequent bucket or the Rare one. System applications or Google applications (Maps, Camera…) will probably be in Working Set while the usual applications (Bank, Travel…) may be classified as Frequent. The implementation of the algorithm will also depend on the smartphone manufacturer.

Adaptive Battery restrictions

Depending on the buckets, several restrictions will be put in place:

• Job
• Alarm
• Network
• Firebase Cloud Messaging

This means that several features of your applications could be impacted:

• Network request to update resources
• Information download
• Background process
• Periodic calls to system APIs…

The restrictions will be as follows :

How to increase the ranking of an application?

One of the ways to avoid declassification is to have the user assign your application in the Doze whitelist. Applications freom this whitelist are exempt from restrictions.

• If your application does not have a launcher activity, think about implementing one if possible.
• It’s important that your users can interact with notifications.
• Don’t clutter your user with too many notifications, otherwise the user could block them and your application will be downgraded.

Testing difficulty

It will be difficult to predict which class your app will be assigned to. It’s likely that its usage will be fragmented, hence your application may end up in any of the 5 classes. If you want to know the class of your application (but noly after your own usage), you can use the API :

It’s however necessary to test your application in all of the different cases. For this you can place the application in the desired class using ADB:

adb shell am set-standby-bucket packagename active|working_set|frequent|rare

It’s obvious that such new testing need will increase the duration of the tests.

Note that if you have a multi-apk application, it’s possible that all APKs aren’t in the same class. It’s therefore important to think about a suitable test strategy.

Does the Adaptive battery really reduce battery consumption?

Since the announcement of this feature (associated with the Artificial Intelligence buzzword) many speculations on its operating mode have been heard: Android would store the most used applications, would allow significant energy gains… Google announced a 30% CPU gain during application launch. Now this figure was actually true but in a Google-centric context. We are more likely around 5% off. The implementation of Adaptive battery is indeed more restricted: depending on the use, some treatments, especially in the background, are delayed. This allows for example, in some cases where the user would have little battery left, to postpone a treatement hoping that it happens when the device is charged. But note that if the treatment is postponed, it’s in no way suppressed. (Source). The Adaptive battery will allow for higher gains as developers use alarms and jobs. An Artificial Intelligence that would drastically reduce energy consumption may be a goal for Android, but we are only witnessing the beginnings.

Each new version of Android has brought more energy management features (Doze, Adaptive battery …). However the gains for the end users are hard to quantify. In any case, it all comes down to the battery life of our smartphones, and we are still to witness a game changing extent in its duration. However what these novelties bring to us, is that they shed some additional light on the applications that are detected as high consumers by the system. The consequence may be severe: the user having been alerted may choose to uninstall these applications.

So… what can we do?

It’s difficult right now to predict how the Adapative Battery system will perceive the applications and sort them in the buckets (Frequently used, Rarely …). However three points are of the utmost importance:

• An efficient, fluid and well-designed application will probably be used more often. Beyond the good practices that are given in this article, it’s important to have a high level of quality for one’s application. This involves more testing, high quality control, gather resources consumption and energy metrics …
• Background tasks set via Alarms and Jobs, as well as network treatments are targeted by Android. It’s important to design an effective application architecture and to test the behavior of these tasks. And to do this in various conditions: different network connection, fragmented platforms ….
• OS editors and devices manufacturers are still looking for mechanisms to prevent applications from using too much battery. As an application developer, it’s critical to anticipate this issue. Indeed, the key to the problem is the design of applications. If applications don’t improve their behavior, systems may continue to put constraining – and somwehat inefficient – mechanisms into place.

Olivier PHILIPPOT

Digital Sobriety Expert
Books author «Green Patterns», «Green IT – Gérer la consommation d’énergie de vos systèmes informatiques», …
Speaker (VOXXED Luxembourg, EGG Berlin, ICT4S Stockholm, …)
Green Code Lab Founder, ecodesign software national association