Doze Mode: Essence, Phases, and Energy-Saving Mechanism

What Is Doze Mode

Doze Mode is a built-in Android power-saving mechanism that activates when the device is not connected to a charger, the screen is off, and the user has not interacted with the device for a certain period. The goal of Doze is to minimize background app activity to maximize battery life during standby. The system defers JobScheduler, account synchronization, AlarmManager, and network requests.

The mode was introduced in Android 6.0 Marshmallow (API 23) and was significantly refined in subsequent versions. Android 7.0 Nougat introduced a second phase (Light Doze) that activates when the device is moving. Android 8.0 introduced additional restrictions on background services working in tandem with Doze. In Android 12+, Doze was integrated with an updated battery management system that analyzes user behavior.

It is important to understand: Doze Mode does not completely disable apps. It puts them into a state with deferred tasks but does not kill processes. A Foreground Service with a notification continues to work, high-priority push notifications (FCM high-priority) are delivered, and alarms fire on schedule. Doze only affects background operations that the user does not see or expect at the moment.

Activation Conditions

Doze Mode activates when all conditions are met: the screen has been off for more than 30 minutes (first activation), the device is stationary (using the accelerometer), and it is not connected to a charger. If the user picks up the phone or connects a charger, Doze is immediately deactivated. In Android 7+, Light Doze activates after just 5 minutes of inactivity, even when the device is moving.

How Doze Mode Works

Doze Mode manages background activity through the system service DeviceIdleController, which analyzes the state of sensors, the screen, and the charger. When all activation conditions are met, the system puts apps into standby mode, grouping their requests into maintenance windows. Inside these windows, all deferred tasks — network calls, synchronization, AlarmManager — are executed in a batch.

The system PowerManager controls which apps can exit Doze. High-priority push notifications (FCM high-priority) can wake the device to deliver a message. The system also ignores Doze for apps added by the user to the battery optimization Whitelist. All other apps must wait for the next maintenance window.

The duration of maintenance windows in Deep Doze increases exponentially: the first window after 1 hour, the second after 2 hours, the third after 4 hours, and so on up to a maximum interval of 12 hours. This means the longer the device is in Doze, the less frequently apps can perform background tasks — saving battery as aggressively as possible.

Impact on Network Requests

In Doze Mode, all network requests are suspended until a maintenance window opens. The only exceptions are FCM high-priority messages (with the “high_priority” tag in the payload) and signals from AlarmManager with the setAndAllowWhileIdle() or setExactAndAllowWhileIdle() flags. Regular network calls via Retrofit, OkHttp, or Volley will not be executed until a window opens.

Phases of Doze Mode

Doze Mode consists of two phases: Light Doze and Deep Doze. Each phase imposes its own restrictions and has different activation thresholds. Understanding the difference between the phases is critical for a developer designing background tasks that are resilient to power-saving mode.

Light Doze

Light Doze activates after 5–30 minutes of device inactivity (screen off, no movement). In this phase, network requests and synchronization are suspended, but AlarmManager and JobScheduler continue to work with minor delays. Apps can exit Light Doze upon receiving a push notification or when connected to a charger. Light Doze does not require complete immobility — the device can be moving.

Deep Doze

Deep Doze occurs after 60–90 minutes of inactivity with the device stationary (accelerometer detects no movement). In Deep Doze, the system is significantly more aggressive in deferring tasks: maintenance windows open less frequently (with an exponentially increasing interval), AlarmManager only fires with the setAndAllowWhileIdle() flags, and WakeLock does not work in the usual way. Apps not on the Whitelist are almost completely deprived of background activity.

Restrictions in Doze Mode

Doze Mode imposes several categories of restrictions that a developer must consider when designing an app. Ignoring these restrictions leads to background tasks not executing, and the user seeing incorrect app behavior — missing updates, unsent messages, incomplete synchronization.

Network Restrictions

All network requests are blocked until a maintenance window opens. This applies to HTTP calls, WebSocket connections, and file downloads. The exception is FCM high-priority messages, which go through a separate Google Play Services channel independent of Doze. For critical data synchronization, it is recommended to use WorkManager with the NetworkType.CONNECTED policy.

AlarmManager Restrictions

AlarmManager in Deep Doze defers all alarms except those created with the setAndAllowWhileIdle() and setExactAndAllowWhileIdle() methods. However, even these methods have a limitation — no more than 1 firing per 9 minutes per app. Exact alarms with setExact() in Deep Doze do not guarantee firing at the specified time.

WakeLock Restrictions

WakeLock behaves unusually in Doze Mode: the system does not hold the wake lock for apps outside the Whitelist. Even if an app has correctly acquired a PARTIAL_WAKE_LOCK, when Deep Doze begins, the system may forcibly release it. The only way to guarantee task execution in Doze is to use a Foreground Service with a notification.

• Network — all requests deferred until maintenance window, except FCM high-priority
• AlarmManager — exact alarms deferred; setAndAllowWhileIdle — no more than 1/9 min
• WakeLock — forcibly released for apps outside the Whitelist
• JobScheduler — tasks grouped into maintenance windows with exponential interval
• Synchronization — Account SyncManager suspended until exiting Doze

Whitelist and Exceptions

The Doze Whitelist is a list of apps that the system allows to run background activity in power-saving mode with minimal restrictions. Users can manually add apps to the list via Settings → Battery → Battery Optimization. System apps, launchers, and Google Play Services are on the Whitelist by default.

A developer can request to be added to the Whitelist via a system dialog with the Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. This requires the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission in the manifest. However, Google does not recommend requesting an exemption without a valid reason — apps that abuse this capability risk being rejected when published on Google Play.

Without the Whitelist, an app can use FCM high-priority to wake the device from Doze. Each such message gives the app a short window (10–30 seconds) to perform a task. For longer operations, the app must start a Foreground Service, which continues working within Doze maintenance windows. Google also provides an exemption mechanism for certain types of apps: navigation, medical, messaging.

How to Check Whitelist Status

To check whether an app is on the battery optimization Whitelist, use the powerManager.isIgnoringBatteryOptimizations() method. If the method returns false, the app is subject to all Doze restrictions. If true, the app can use Wakelock, AlarmManager, and network without restrictions even in Deep Doze. However, abusing this privilege will lead to poor user reviews.

Testing Doze Mode

Testing app behavior in Doze Mode is a mandatory development step, as Doze can disrupt background functions. Android provides command-line tools via ADB to forcibly transition the device into Light Doze and Deep Doze. Testing must be performed on a physical device or emulator with Android 6.0+.

To enter Light Doze, use the command adb shell dumpsys deviceidle step light. For Deep Doze — adb shell dumpsys deviceidle step deep. The command adb shell dumpsys deviceidle force-idle deep immediately transitions the device into Deep Doze without waiting for the standard timeout. After testing, Doze is exited with the command adb shell dumpsys deviceidle unforce.

# Force Enter Light Doze
$ adb shell dumpsys deviceidle step light

# Force Enter Deep Doze
$ adb shell dumpsys deviceidle step deep

# Force Deep Doze Immediately
$ adb shell dumpsys deviceidle force-idle deep

# Exit Doze
$ adb shell dumpsys deviceidle unforce

# Check Doze Status
$ adb shell dumpsys deviceidle

Checking App Behavior

After transitioning into Doze Mode, check whether network requests work (they should be deferred), whether AlarmManager fires, whether FCM messages are delivered, and whether WorkManager tasks execute correctly. WorkManager continues to work in Doze: its tasks are executed in maintenance windows. However, if a task requires immediate execution, specify setExpedited() or use a Foreground Service.

Best Practices for Doze Mode

Developing an app that is resilient to Doze Mode requires rethinking the approach to background tasks. Google recommends designing the app to work correctly under any Doze restrictions, without relying on immediate execution of background operations. The fundamental principle is to use WorkManager for all background tasks that can be deferred.

Use WorkManager

WorkManager is the recommended Google API for background tasks because it automatically adapts to Doze. WorkManager uses JobScheduler (API 23+) or AlarmManager + BroadcastReceiver on older versions. WorkManager tasks execute in the nearest Doze maintenance window, or immediately if needed via Expedited Work (Foreground Service under the hood).

Foreground Service for Critical Tasks

If a task cannot be deferred (media playback, navigation, VoIP), use a Foreground Service with a mandatory notification. A Foreground Service receives an exemption from Doze: it can hold a WakeLock and execute network requests. However, even a Foreground Service is subject to Deep Doze maintenance window policies for some types of tasks — for example, dataSync.

FCM High-Priority for Notifications

For delivering messages that require immediate attention (incoming call, urgent notification), use FCM high-priority messages. Such messages wake the device from Doze and give the app a short window for processing. Do not use high-priority for regular notifications — this will cause rapid battery drain and may be considered a policy violation by Google Play.

• WorkManager — preferred API for all deferred background tasks
• Foreground Service — for critical tasks with a visible notification
• FCM high-priority — for delivering urgent messages with device wake-up
• Do not request Whitelist without critical need — it worsens user experience
• Test the app in Light and Deep Doze via ADB before release