The Android 9 device new features for improving power management. These changes, along with the features already available in previous versions, help ensure that system resources are given to the apps they need most.
Power-management facilities come in two categories:
App standby bucket- The system limits access to apps to device resources, such as CPUs or batteries, based on user usage patterns. This is a new feature for Android 9.
Battery saver improvements- When the battery saver is turned on, the system bans all apps. This is an existing feature which is better with Android 9.
Note: These changes apply to all the apps, the Android training in Chandigarh provide the information regardless of whether they target Android 9 or not.
App Standby Buckets
Android 9 features a new battery management feature, the app standby bucket. The app helps to prioritize applications’ requests for resources on the standby bucket system, based on recent usage of applications and how often. Depending on the app usage pattern, each app is placed in one of the five primary buckets. This system limits the device resources available to each app, which has an app’s bucket.
Five buckets prefer apps in groups by following attributes:
Active:- If the user is currently using the app, then the app is in the active bucket, for example:
- The app has started an activity
- App running a foreground service
- The app has a sync adapter connected to the content provider used by the foreground app
- User clicks on notification from app
If an app is in active bucket, then the system does not impose restrictions on app jobs, alarms or FCM messages.
Working set:- An app is in working set bucket if it runs frequently but it is not currently active. For example, the social media app that a user is expected to launch in most days is in the working set. If they are used indirectly, the app is also promoted in the work set bucket.
If an app is in the working set, then the system has a light ban on the ability to run jobs and trigger the alarm.
Frequently:- An app is constantly in bucket if used regularly, but not every day is necessary. For example, the gymnastic-tracking app that runs in the gym can be continuously in a bucket.
If an app is constantly in a bucket, then the system imposes a strong ban on the ability to run jobs and trigger the alarm, and impose a cap on high priority FCM messages.
Rare:- An app is in rare bucket if it is not often used. For example, a hotel app that runs during a hotel while in the hotel can be in a rare bucket.
If an app is in a rare bucket, then the system strictly prohibits the running of jobs, triggering alarm and the ability to obtain high priority FCM messages. This system also limits the app’s ability to connect to the Internet.
Never:- Apps that are installed but never run are never assigned to the bucket. The system places serious restrictions on these apps.
The system assigns each app dynamically in the priority bucket, and reassigns the application as needed. The system can rely on a preloaded app that uses machine learning to determine how each app can be used, and assigns the app to the proper bucket. If the system app is not present on any device, the default is to sort the application based on how the system is used recently. More active apps are assigned to the bucket, which gives the app a high priority, so that more system resources are available in the app. Specifically, the bucket determines how often the app’s jobs run, how often an app can trigger an alarm, and how often the app can get high priority cloud messaging (FCM) messages. These Android device 9 new features restrictions apply only when the device is on battery power; The system does not apply these restrictions to the application when the device is charging.
Each manufacturer can set their own criteria to determine how non-active apps are allocated to the bucket. You should not try to influence what bucket your app is assigned to. Instead, be sure to check that your app behaves well in whatever bucket it may contain. Your app can find out which bucket it is currently by calling the new method UsageStatsManager.getAppStandbyBucket ().
Note: Apps on the DOS whitelist are exempt from app standby bucket-based restrictions.
If your app is already following best practices for dodge and app standby, then it should not be difficult to handle new power management features. However, some app behaviors that used to work well in the past can now create problems.
- Do not try to manipulate the system to put your app in a bucket or some other. System bidding methods can change, and each device manufacturer can choose to write their own bucket app with their own algorithms. Instead, make sure your app behaves appropriately no matter what bucket it is in.
- If there is no launcher activity in an app, it can never be promoted in the active bucket. You would like to redesign your app for this kind of activity.
- If the app’s notifications are not functioning, users will not be able to trigger the promotion of the app in the active bucket by interacting with the notifications. In this case, you would want to redesign some appropriate notifications so that they respond to the user.
- Similarly, if the Android 9 device new features app does not show notification when receiving high priority FCM messages, then it will not give the user the chance to interact with the app and thus, it will promote the active bucket. In fact, the only purpose for the high priority FCM messages is to push the notification to the user, so this situation should never happen. If you incorrectly mark any FCM message as a high priority, then this user does not trigger interaction, then it can cause other negative results; For example, this may result in your app ending its quota, so that immediate FCM messages can be considered as a general priority.
- Note: If the user repeatedly rejects the notification, then the system gives the user the option of blocking that notification in the future. Do not spam the user with notifications to try to put your app in active bucket!
- If apps are split across multiple packages, those packages can be in different buckets and thus, there are different access levels. To ensure that the app behaves properly, you should make sure to test such apps with the packages given to various buckets.
Battery saver improvements
Android 9 does many improvements in battery saver mode. The device manufacturer determines the exact restriction imposed. For example, AOP creates, the system applies the following restrictions:
- Instead of waiting for the app to become inactive, the system keeps the app more aggressively in standby mode.
- Despite their target API level, the background execution limit applies to all apps.
- Background apps do not have network access.
- In addition, there are others, device-specific power optimization too.
As always, it’s a good idea to test your app when battery saver is active. You can manually turn on battery saver through device settings> battery saver screen.
Testing and troubleshooting
New power management features affect all apps running on Android 9 devices, whether or not the app targets Android 9.Be sure to test the main usage cases of your app under different management situations, to see how power management facilities interact with each other. You can use the Android debug bridge command to turn on and off some features.