App Standby — What It Is, Standby Levels, and How It Works

What Is App Standby

App Standby is a component of the Android power management system, introduced in Android 6.0 (API 23) and significantly reworked in Android 9 (API 28). Its job is to identify which apps the user rarely uses and restrict their background activity: network requests, synchronization, JobScheduler, and AlarmManager. Unlike Doze, App Standby does not depend on screen state or device movement.

The system classifies apps into four buckets (levels): Active, Working Set, Frequent, and Rare. Each level determines how heavily background activity is restricted. Transitions between levels happen automatically based on the app’s usage patterns: how often the user opens it, receives notifications, interacts with widgets.

App Standby works alongside Doze Mode but does not replace it. While Doze limits the background activity of all apps when the device is idle, App Standby restricts specific apps regardless of device state. An app at the Rare level will face restrictions even when the phone is actively used, if the user has not opened it for several days.

Buckets in Android 9+

Starting from Android 9 (API 28), Google introduced App Standby Buckets — a formal classification with numeric values. The system uses machine learning to predict the next time an app will be launched. If the model predicts the app will be opened within the next few hours, it gets an Active bucket. If the prediction indicates rare usage — it is assigned Rare.

How App Standby Works

App Standby analyzes several factors to determine the bucket: time since the user last opened the app, interaction frequency (number of launches per day/week), receiving FCM notifications, presence of active widgets on the home screen, and subscription to AlarmManager. The longer an app goes unused, the lower its bucket and the stricter the restrictions.

The system service UsageStatsManager collects app usage statistics and passes them to StandbyController — a framework component that calculates the bucket for each app. StandbyController also takes system events into account: after an app update, its bucket is reset to Active for a few days so the user can evaluate new features.

An important feature: App Standby does not kill the app process, but limits its background capabilities. The app continues to work if the user is interacting with it (Active bucket). As soon as the user minimizes the app and does not return to it, the system starts counting idle time and may lower the bucket to Working Set or Frequent.

FCM Impact on Bucket

Receiving an FCM high-priority message can temporarily raise the app’s bucket to Active. This gives the app an opportunity to perform a task (process the message, sync data) without restrictions. However, after processing completes, the bucket returns to its original value. Google recommends using this mechanism for delivering important notifications, not for keeping the app alive.

App Standby Levels

App Standby uses four levels (buckets) to classify apps. Each level determines the delay time for background tasks: the lower the level, the longer the delay. The system automatically moves the app between levels based on usage statistics collected over the last 7–14 days.

Active — Active App

Active — an app the user has recently interacted with (launched, received a notification, or used a widget). In this bucket there are no restrictions: JobScheduler runs immediately, network is available, AlarmManager fires precisely. The app stays in Active until the user stops interacting with it for several hours.

Working Set and Frequent

Working Set — the app is used regularly (several times a week). Background task delay up to 2 hours. Frequent — the app is used several times a month. Delay up to 4 hours. In both levels, the network is only available in maintenance windows, and AlarmManager may be deferred. JobScheduler runs tasks in the nearest window.

Rare — Rarely Used

Rare — the strictest level, assigned to apps the user has not opened for more than 30 days. Background task delay reaches 24 hours. Network is completely blocked outside maintenance windows, AlarmManager only fires with setAndAllowWhileIdle() flags with a limit of once every 9 minutes. FCM high-priority notifications are still delivered but cannot raise the bucket.

Restrictions in App Standby

App Standby imposes restrictions on several categories of background operations. Unlike Doze, App Standby restrictions apply independently of screen state and charging status. The developer must design the app with these restrictions in mind, especially if the target audience uses the app irregularly.

JobScheduler and WorkManager

JobScheduler — the primary API affected by App Standby. Depending on the bucket, task execution delay ranges from 2 to 24 hours. WorkManager, which uses JobScheduler under the hood (on API 23+), is also subject to these delays. For time-critical tasks, use Expedited Work, which launches a Foreground Service under the hood and is not affected by the bucket.

Network Restrictions

Apps in the Working Set, Frequent, and Rare buckets cannot perform arbitrary network requests at any time. The system only allows network access during maintenance windows, which are synchronized with Doze. To send critical data, use FCM high-priority with subsequent synchronization in the maintenance window.

AlarmManager

AlarmManager in App Standby follows the same rules as in Doze: exact alarms (setExact()) are deferred, and setAndAllowWhileIdle() is limited to 1 firing per 9 minutes. For the Rare bucket, delay can reach 24 hours, making AlarmManager unsuitable for precise task scheduling in rarely used apps.

• JobScheduler — tasks are deferred for 2–24 hours depending on bucket
• Network — access only in maintenance windows for Working Set and below
• AlarmManager — exact alarms are deferred; setAndAllowWhileIdle — 1/9 min
• SyncManager — account synchronization is delayed until the maintenance window
• Widget updates — widget update frequency may be reduced

How to Get an Exemption

An exemption from App Standby can be obtained in two ways: through the user’s battery settings (manual Whitelist) or through the system Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. However, Google strictly regulates access to exemptions — apps without a valid reason risk being rejected on Google Play.

The user can manually disable restrictions for a specific app via Settings → Apps → [App] → Battery → Optimization → Don’t optimize. This completely removes App Standby and Doze restrictions for the selected app. The developer can show the user instructions or a system dialog, but cannot forcibly add an app to the exemptions.

Foreground Service with a notification automatically gets a temporary exemption from App Standby. While the service is running and displaying a notification, the app is moved to the Active bucket regardless of its actual level. After the service stops, the bucket returns to its original value. This is the most reliable way to guarantee background work without requesting system exemptions.

When to Request an Exemption

Requesting a Whitelist only makes sense for apps with critically important background functionality: real-time navigation, health monitoring, VoIP calls, device protection. For most apps, it is sufficient to use Foreground Service or WorkManager. Google Play may reject the publication if the app requests an exemption without a clear necessity.

// Request App Standby Exemption
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Check Current Status
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Testing App Standby

Testing App Standby via ADB allows you to forcibly assign any bucket to an app and verify its behavior. This is critically important for apps that rely on background synchronization, notifications, or periodic updates. Testing must be performed on a physical device or emulator with Android 9+.

To forcibly set a bucket, use the command adb shell am set-standby-bucket [package] [bucket], where bucket can be: active, working_set, frequent, or rare. To view the current bucket — adb shell am get-standby-bucket [package]. The system also allows simulating prolonged app inactivity via the command adb shell dumpsys usagestats.

# Set Rare Bucket for the App
$ adb shell am set-standby-bucket com.example.app rare

# View Current Bucket
$ adb shell am get-standby-bucket com.example.app

# Reset All Buckets to Active
$ adb shell dumpsys usagestats clear

# View All System Buckets
$ adb shell dumpsys usagestats

What to Check

After setting the bucket to Rare, check: whether the WorkManager task executes within 24 hours, whether AlarmManager fires, whether FCM notifications are delivered, and whether Foreground Service works without restrictions. WorkManager with Expedited Work policy should execute immediately even in the Rare bucket, since it uses Foreground Service. Regular WorkManager tasks will be deferred according to the bucket.

Best Practices

Developing an app resilient to App Standby requires a thoughtful approach to background tasks. The main principle: do not assume the app is always in the Active bucket. Design background work so it correctly performs with the delays characteristic of the Frequent and Rare buckets.

Use WorkManager with Expedited Work

Expedited Work (WorkManager 2.7+) launches a Foreground Service under the hood, giving the task immediate execution regardless of bucket. This is the optimal choice for tasks that cannot be deferred: sending a message, synchronization after payment, processing an incoming call. Regular WorkManager tasks run in maintenance windows according to the bucket.

FCM for Reactivation

Use FCM high-priority messages to wake an app from App Standby. When the app receives such a message, its bucket is temporarily raised to Active, allowing it to perform necessary tasks (sync, update data). After processing completes, the bucket returns to its original level.

Avoid Constant Memory Retention

Do not try to bypass App Standby with persistent background services, WakeLock, or periodic FCM messages. Google actively fights such practices — the app may be flagged as power-hungry and restricted even more strictly. Use WorkManager for periodic tasks and Foreground Service only when the task is truly visible to the user.

• WorkManager — preferred API; Expedited Work executes tasks without delay
• FCM high-priority — temporarily raises bucket to Active for message processing
• Do not bypass App Standby — this leads to the app being blocked by the system
• Foreground Service — temporarily moves the app to Active while running
• Test the app in Rare and Frequent buckets via ADB before each release