With Android’s continuous evolution, power management has become increasingly fine-tuned. Starting from Android 9 (API level 28), Android introduced App Standby Buckets, a dynamic classification system that governs how apps can access system resources based on their usage patterns.

These buckets are essential for developers who rely on background jobs, alarms, or network access to power their app’s core functionality.

In this post, we’ll explore what these buckets are, how they limit your app’s capabilities, and how you can optimize your app to function efficiently within these boundaries.

What Are App Standby Buckets?

App Standby Buckets categorize apps based on how frequently they are used. Android uses a combination of machine learning and user behavior analysis to dynamically assign apps to a bucket.

The buckets help Android prioritize system and battery resources without degrading the user experience.

Here are the five main buckets:

1. Active — App is currently in use or was used very recently.
2. Working Set — App used often, possibly running in the background.
3. Frequent — App used regularly but not daily.
4. Rare — App used infrequently.
5. Restricted — App is misbehaving or user has manually restricted it.

Resource Limits by Standby Bucket

Each bucket determines how much access an app has to jobs, alarms, and network activity. Below is a breakdown of the execution time windows for each resource type:

Active

• Regular Jobs: Up to 20 minutes in a rolling 60-minute period
• Expedited Jobs: Up to 30 minutes in a rolling 24-hour period
• Alarms: No execution limits
• Network Access: Unrestricted

Note (Android 16+): Prior to Android 16, apps in the Active bucket had no job execution limit.

Working Set

• Regular Jobs: Up to 10 minutes in a rolling 4-hour period
• Expedited Jobs: Up to 15 minutes in a rolling 24-hour period
• Alarms: Limited to 10 per hour
• Network Access: Unrestricted

Frequent

• Regular Jobs: Up to 10 minutes in a rolling 12-hour period
• Expedited Jobs: Up to 10 minutes in a rolling 24-hour period
• Alarms: Limited to 2 per hour
• Network Access: Unrestricted

Rare

• Regular Jobs: Up to 10 minutes in a rolling 24-hour period
• Expedited Jobs: Up to 10 minutes in a rolling 24-hour period
• Alarms: Limited to 1 per hour
• Network Access: Disabled

Restricted

• Regular Jobs: Once per day for up to 10 minutes
• Expedited Jobs: Up to 5 minutes in a rolling 24-hour period
• Alarms: One per day (exact or inexact)
• Network Access: Disabled

Regular vs. Expedited Jobs

Android distinguishes between two types of scheduled jobs:

• Regular Jobs: Standard background tasks scheduled via JobScheduler or WorkManager.
• Expedited Jobs: Urgent, high-priority jobs using setExpedited(true) or expedited workers in WorkManager.

Expedited jobs have separate quotas from regular jobs. Once those quotas are exhausted, they may still run under the regular job limits.

Best Practice: Use expedited jobs only for urgent tasks. For everything else, rely on regular job scheduling.

Alarm Limits

Starting with Android 12, alarm limits have tightened:

• Apps in Working Set or below are subject to hourly or daily caps.
• Apps in the Restricted bucket can schedule only one alarm per day (exact or inexact).

If your app depends on alarms, consider alternatives like JobScheduler or WorkManager, especially for non-critical tasks.

Network Access Limitations

Apps in the Rare and Restricted buckets cannot access the network unless they are running in the foreground.

This has big implications for features like:

• Background syncing
• Data uploads
• Real-time updates

Make sure to test network-reliant tasks across all bucket conditions.

Android 13+ Update: FCM Quota Change

As of Android 13, the number of high-priority Firebase Cloud Messaging (FCM) messages an app can receive is no longer tied to the standby bucket.

This change benefits apps that rely on push messages (like messaging or ride-sharing apps), ensuring more consistent delivery.

Developer Tips for Bucket Optimization

1. Track App Usage
    Use UsageStatsManager to monitor your app’s current bucket status.
2. Leverage WorkManager
    It automatically handles job fallback between expedited and regular quotas.
3. Respect Background Limits
    Overusing background resources can land your app in the Restricted bucket.
4. Batch and Defer Tasks
    Reduce battery drain and stay in higher buckets longer by batching non-critical jobs.
5. Test Across Buckets
    Simulate different standby buckets with this ADB command:

adb shell am set-standby-bucket <package_name> <bucket_name>

Conclusion

App Standby Buckets are a key piece of Android’s power management strategy. By tailoring your background behavior to each bucket’s constraints, you not only improve performance and battery life but also ensure a smoother user experience.

Understanding how these limits work — and respecting them — helps you build apps that are efficient, resilient, and Play Store compliant.

FAQs

Q: Can I manually move my app to a different bucket?
 A: No. The system dynamically assigns apps based on usage. You can only simulate bucket placement during testing.

Q: Do background restrictions help battery life?
 A: Yes, but they can also restrict your app’s background capabilities. Design wisely.

Q: How do I test alarms or jobs under low buckets like Rare or Restricted?
 A: Use ADB to simulate conditions, monitor behavior, and fine-tune fallback strategies.