With every new version of Android come promises of better battery and power management from Google, some of which, like Doze, have worked out quite well. With P, one of the new elements coming are called App Standby Buckets. This method effectively segregates apps into different tiers, or buckets; the system then limits device resource allocation based on which group an app is in.
This process is dynamic, since over time, Android learns how and when you use your applications, which is how it determines which bucket to place them in. If an app is put in a lower priority group, but is then used more often, the system will adjust its placement accordingly. It's worth noting that Android will fall back to this usage pattern system to determine app placement only if the device lacks pre-loaded software that would otherwise determine where an application might be placed.
The buckets are broken down into Active, Working Set, Frequent, Rare, and Never. Here's how Google describes these buckets and their behavior:
An app is in the active bucket if the user is currently using the app, for example:
- The app has launched an activity
- The app is running a foreground service
- The app has a sync adapter associated with a content provider used by a foreground app
- The user clicks on a notification from the app
If an app is in the active bucket, the system does not place any restrictions on the app's jobs, alarms, or Firebase Cloud Messaging messages.
An app is in the working set bucket if it runs often but it is not currently active. For example, a social media app that the user launches most days is likely to be in the working set. Apps are also promoted to the working set bucket if they're used indirectly.
If an app is in the working set, the system imposes mild restrictions on its ability to run jobs and trigger alarms.
An app is in the frequent bucket if it is used regularly, but not necessarily every day. For example, a workout-tracking app that the user runs at the gym might be in the frequent bucket.
If an app is in the frequent bucket, the system imposes stronger restrictions on its ability to run jobs and trigger alarms, and also imposes a cap on high-priority FCM messages.
An app is in the rare bucket if it is not often used. For example, a hotel app that the user only runs while they're staying at that hotel might be in the rare bucket.
If an app is in the rare bucket, the system imposes strict restrictions on its ability to run jobs, trigger alarms, and receive high-priority FCM messages. The system also limits the app's ability to connect to the internet.
In addition, there's a special never bucket for apps that have been installed but have never been run. The system imposes severe restrictions on these apps.
Here's the biggest downside: "Every manufacturer can set their own criteria for how non-active apps are assigned to buckets." Google also notes that if your app is already following the best practices for Doze, allowing for Buckets should be easy, though you should always expect problems with things like this.
For us users, it's unlikely that we'll ever notice much of this, except for theoretically better battery life. Still, it's always nice to know what's going on under the hood.