Doze and App Standby: Android's Battery Savers

WHY IT EXISTS Before these features, any app could wake the device, use the network, and run CPU-intensive tasks in the background, leading to significant battery drain. Doze and App Standby were created to enforce good behavior and extend battery life by strictly limiting what apps can do when the user isn't actively engaged.

THE MENTAL MODEL Think of Doze as the building's master power-saving mode. When the building is empty and still (device is stationary, screen off, unplugged), it shuts down non-essential systems like HVAC and most lights (network access, CPU-intensive jobs). App Standby is more like a janitor noticing a specific office hasn't been used for days and cutting its power individually, while other active offices remain powered.

HOW IT WORKS Doze is triggered when a device is unplugged, stationary, and has its screen off for a period of time. In this state, the system blocks wakelocks, limits network access, and defers standard jobs and syncs. It periodically opens brief "maintenance windows" where apps can execute their deferred tasks in a batch. The longer the device is in Doze, the less frequent these windows become.

App Standby is a per-app restriction. The system determines an app is idle if the user hasn't interacted with it recently (e.g., launched it, or interacted with a notification). Once in App Standby, the app's background network access and jobs are deferred until the device is plugged in or the user actively uses the app again.

WHEN TO USE IT These are system behaviors you must account for, not features you choose to use. The correct approach is to make your app's background work resilient. For deferrable tasks like syncing data or uploading logs, use WorkManager. It is the recommended solution as it is lifecycle-aware and respects Doze and App Standby, guaranteeing your task will eventually run in an efficient manner.

WHEN NOT TO USE IT You cannot opt out of these restrictions. The anti-pattern is trying to fight the system. Do not use persistent wakelocks or rapidly repeating, imprecise alarms to circumvent Doze. This is the exact behavior the system is designed to prevent, and it can lead to poor app ratings and OS-level throttling of your app.

ONE CANONICAL EXAMPLE An RSS reader app is set to fetch new articles every hour using a simple AlarmManager alarm. When the user leaves their phone on their desk overnight, the device enters Doze. The hourly alarms don't fire. Instead, they are all deferred. When the first maintenance window opens hours later, all the queued alarms might fire at once. The correct implementation uses WorkManager to schedule a periodic fetch, letting the system run it during a maintenance window or when conditions are otherwise optimal.