In the mobile development ecosystem under Android energy management is one of the most critical tasks. When the user's smartphone is not in use, the system automatically puts the device into a special power saving mode, which is often called standby mode. For an ordinary user, this is just a way to extend battery life, but for a developer, this is a complex restriction mechanism that can break the application if its features are not taken into account at the coding stage.
This mode is a set of system policies, including Doze Mode and App Standby. Starting with version Android 6.0 Marshmallow, Google has tightened the rules for background processes to prevent applications that the user has not opened for a long time from draining the battery. Understanding how the system limits network activity, CPU access, and wakelocks is becoming a must-have skill for creating stable software.
Ignoring these mechanisms may result in your application not receiving important notifications, not synchronizing data, or being forcefully closed by the system. In this article, we'll take a closer look at standby architecture, debugging tools, and strategies for adapting your code to modern battery optimization requirements.
Power Saving Architecture: Doze and App Standby
The power management system Android is divided into two main components that work in tandem. The first is Doze Modewhich is activated when the device is at rest, the screen is turned off, and the phone does not move for a certain time. In this state, the system postpones background tasks and network activity, giving applications short time windows to perform necessary operations.
The second component is App Standby. This mode applies to individual applications that the user has not launched for an extended period. Even if the phone is actively used for other tasks, the "sleeping" application will be subject to restrictions. This prevents a situation where rarely used software continues to consume resources in the background.
⚠️ Attention: System behavior may differ on devices from different manufacturers. Some vendors, such as Xiaomi or Huawei, add their own aggressive process killing algorithms on top of standard mechanisms. Android.
The developer must clearly distinguish between these states, as they require different testing approaches. If your app depends on persistent connections or background geolocation, the standard standby mode will make it inoperable without proper manifest configuration and use of special APIs.
Use the Android Studio emulator to simulate Doze mode without waiting for the device's actual battery to drain. This will speed up testing of energy saving scenarios.
Technical limitations and maintenance windows
When the device enters deep sleep, the system blocks most standard wake-up mechanisms. Network connections are closed and access to the file system is limited. However, the system provides so-called Maintenance windows (maintenance windows). During these short periods of time, apps can perform pending tasks, sync data, or send analytics reports.
The frequency with which these windows appear depends on the battery status and the time that has passed since the device was last used. Initially, windows may appear every 15 minutes, but as downtime increases, the interval can increase to several hours. This means that you can't rely on background tasks running regularly while on standby.
There are exceptions for mission-critical tasks, such as incoming calls in VoIP applications or messages in instant messengers. Use High Priority FCM messages allows you to temporarily wake the application from sleep mode to process the message. But abuse of this mechanism can cause the system to flag your application as an intruder and apply even stricter restrictions to it.
- 🔋 Network: Access is only possible during maintenance windows or through priority messages.
- 📁 Files: Reading and writing are limited unless the application has special permissions.
- ⏰ Alarms: Standard
AlarmManagerdelayed until the next maintenance window. - 📍 Geolocation: Background GPS tracking is paused to save battery.
Debugging tools and forced activation
It is critical for developers to have the ability test the behavior of the application in standby mode without having to wait several hours for the phone to actually go into this state. Android Debug Bridge (ADB) provides powerful commands to force the device into Doze mode and manage the list of exceptions.
To simulate the transition to standby mode, you need to connect the device to the computer and use the console. First, the device is switched to the idle state, and then the Doze mode is forced. This allows you to instantly test how your app responds to network loss and alarm pauses.
adb shell dumpsys battery unplug
adb shell dumpsys deviceidle force-idle
After running the tests, it is extremely important to return the device to normal, otherwise you will not be able to receive notifications or charge your phone as usual. To exit the mode, use the reset command.
adb shell dumpsys battery reset
adb shell dumpsys deviceidle unforce
It is also possible to add your application to the whitelist via ADB to test operation without restrictions. This is useful for debugging, but remember that on real user devices, your application will not have such privileges by default.
☑️ Check idle mode
Code optimization: WorkManager and JobScheduler
In modern realities of development under Android use Legacy methods for background tasks such as Service or direct calls AlarmManagerare considered bad practice. The system can kill such a process at any time when entering standby mode. Instead, it is recommended to use WorkManager a library that is part Android Jetpack.
WorkManager automatically adapts to the state of the system. If the device is in Doze mode, the library will schedule the task for the nearest maintenance window. If the device is active, the task can be completed immediately. This ensures a balance between timely completion of the task and energy efficiency.
For tasks that require precise execution time (for example, an alarm clock), you can still use AlarmManager, but only with the setExactAndAllowWhileIdleflag. However, such tasks consume more energy and should be used with caution. The main data synchronization logic should be transferred to deferred tasks.
⚠️ Attention: Starting from Android 12 (API level 31), restrictions on background running of components have become even stricter. Many implicit service starts are now prohibited unless the application is in the foreground.
Proper application architecture involves separating logic into interactive (UI) and background logic. The background part should be designed to be "interruptible" and resumed without losing data. This is a key principle of survival in an environment with aggressive memory and power management.
Why WorkManager is better than Service?
WorkManager guarantees that the task will complete even after a device reboot or application update, while a regular Service can simply be killed by the system without the ability to automatically restart in low memory conditions.
Exceptions and special permissions
Despite strict rules, there are scenarios when an application needs to run in the background constantly. Vivid examples: navigators, fitness trackers, instant messengers and smart home applications. For such cases, the system provides an exception mechanism, but obtaining these rights requires justification.
The developer can request an exception from battery optimization through the system settings. The user must explicitly confirm this action by going to the battery settings menu. The application cannot automatically add itself to exceptions - this is protection against malware. In the code, this is implemented through a check PowerManager.isIgnoringBatteryOptimizations and an Intent request.
| Task type | Recommended API | Requires an exception? | Impact on the battery |
|---|---|---|---|
| Data synchronization | WorkManager |
No | Low |
| Precise time (alarm clock) | AlarmManager |
No (with flag) | Average |
| Running tracking/GPS | Foreground Service |
Desirable | High |
| VoIP calls | ConnectionService |
Partially | Average |
It is important to understand that the presence of an exception does not give carte blanche for uncontrolled consumption of resources. The system still monitors the application's behavior. If an application with an exception consumes too much power in the background, the user will receive a notification from the system with a recommendation to limit background activity, which may negatively affect the application's rating in the store.
A request to exclude from battery optimization must be justified by the functionality of the application. An unreasonable request reduces user trust and can lead to the removal of the application from Google Play.
The impact of Android versions and Google Play policies
Power management policies evolve with each version of the operating system. What worked in Android 8.0 Oreocan be completely blocked in Android 14. Developers need to constantly monitor changes in system behavior (Behavior Changes), which Google publishes in the documentation for each new version of the API.
In addition, the store rules Google Play explicitly prohibit applications that unreasonably drain the battery. There are automatic scanning systems that identify applications with abnormal power consumption in standby mode. Getting into such a list may lead to the application being deleted from the catalog without the possibility of recovery.
Particular attention should be paid to new features such as “Suspending cached processes” in the latest versions of Android. The system can now freeze application processes that are minimized, effectively pausing them. This requires developers to work even more carefully with State Saving and quick recovery when the user returns to the application.
⚠️ Attention: Details of the implementation of energy saving may change with security updates and major versions of Android. Always check the behavior of your application with the official documentation for the target SDK version (targetSdkVersion).
Testing on different OS versions is mandatory. The behavior of the emulator may differ from the real device, especially when working with motion sensors and network interfaces. Using Firebase Test Lab allows you to run power saving tests on a wide range of real devices.
Frequently asked questions (FAQ)
Why don't my notifications arrive when the screen is off?
Most likely, your application is subject to Doze or App Standby restrictions. Check if you are using priority FCM messages for critical notifications. Regular notifications can be delayed until the user turns on the screen or the device enters the maintenance window.
Is it possible to completely disable sleep mode for your application?
You cannot completely disable system sleep mode, since it is part of the OS kernel. However, you can request the user to exclude battery optimization. This does not guarantee work in the background without restrictions, but it significantly expands the possibilities for background tasks.
How to find out if the device is in Doze mode right now?
You can check this programmatically via PowerManager, but for debugging it is better to use ADB commands: adb shell dumpsys deviceidle. The command output will indicate the current status (IDLE or ACTIVE) and the time until the next maintenance window.
Does standby mode affect the operation of widgets on the main screen?
Yes, it does. Widgets may be updated less frequently than specified in their settings if the system decides to save energy. For widgets, it is recommended to use JobScheduler or WorkManager to schedule updates rather than relying on frequent timers.
What is "Deep Sleep" in a development context?
This is the state that the device enters after a long period of inactivity in Doze mode. In Deep Sleep, the frequency of maintenance windows is minimal and most background processes are completely frozen. Only user interaction or a high-priority system event can bring the device out of this state.