Reference

App Standby Buckets

App Standby Buckets are priority tiers Android assigns to apps based on how recently and often they are used, throttling background jobs, alarms, and network for apps in lower buckets to extend battery life.

Android developmentAndroid

App Standby Buckets

Also known as: standby buckets android, app standby, android app standby buckets, usage buckets

App Standby Buckets are priority tiers Android assigns to apps based on how recently and often they are used, throttling background jobs, alarms, and network for apps in lower buckets to extend battery life.

  • Introduced in Android 9 (API 28) with buckets Active, Working set, Frequent, Rare, and Restricted.
  • Lower buckets throttle JobScheduler jobs, alarms, FCM quotas, and background network.
  • Read the current bucket via UsageStatsManager.getAppStandbyBucket(); buckets are usage-driven, not settable.

The five buckets

Added in Android 9 (API 28), the system places each app into one of five buckets: Active (in use right now), Working set (used regularly), Frequent (used often but not daily), Rare (used infrequently), and Restricted (a heavy-use or misbehaving app the user or system has limited). An app's bucket is dynamic and updated as usage patterns change.

The bucket controls how much deferrable background work an app gets. Lower buckets impose harsher limits on JobScheduler jobs, alarms (AlarmManager), Firebase Cloud Messaging quotas, and background network access. An Active app runs with no standby restrictions; a Rare or Restricted app may have its background jobs deferred for many hours.

Why it matters for background work

Standby buckets are one of the main reasons a scheduled task does not run when a developer expects. Combined with Doze and App Standby idle states, the system aggressively delays work for apps the user has not opened recently, even if a periodic job is registered.

Developers can inspect the current bucket with UsageStatsManager.getAppStandbyBucket() but cannot force a higher bucket — frequent legitimate use is what raises it. The practical takeaway is to keep background jobs deferrable and idempotent, since maintenance work for a rarely opened app should expect significant delay rather than precise timing.

Related terms

Keep reading the reference.

Act on it

Guides and tools for this topic.