Test your app under battery saver and Doze

Android limits background work to save battery. Battery saver is something the user switches on. Doze starts by itself when the phone sits still, unplugged and with the screen off. Many phone makers add their own limits on top. Under these modes background work can be delayed or stopped. Your app should still behave in a way the user can understand.

This list is about visible results: a reminder that does not arrive, data that is stale, a download that never finishes.

Set up the conditions

• Battery saver. Turn it on in the system settings (menu names differ by phone; on many phones it is under Settings > Battery), or set it to start at a high battery level so it stays on during testing.
• Doze (with adb). Android's Doze documentation recommends testing on a device or emulator with API level 23 or higher and gives this sequence (check the page for changes): adb shell dumpsys deviceidle force-idle Afterwards restore normal behavior: adb shell dumpsys deviceidle unforce adb shell dumpsys battery reset
• App Standby (with adb). The same page uses adb shell dumpsys battery unplug and adb shell am set-inactive <package> true to put an app in standby, and ... set-inactive <package> false to wake it.
• Real waiting. Leave a real phone alone, screen off, unplugged, for an hour or more. Slow, but it is the true behavior.
• Manufacturer settings. Many brands have an extra battery or app-launch setting per app. Test with the default and with it restricted.

Checklist

1. Scheduled reminders and alarms. Set one for a few minutes ahead, lock the phone, wait. Per Android's Doze documentation, standard alarms are deferred to the next maintenance window, and the "allow while idle" variants can fire at most once per nine minutes per app. Expect: it fires on time, or the delay is acceptable and documented. If exact timing is a promise of your app, test it hardest.
2. Push notifications. Send a test message while idle. Expect: it arrives, perhaps late. Note how late.
3. Background sync. Change data on another device, wait. Android's docs note that JobScheduler, and therefore WorkManager, does not run during Doze until a maintenance window. Expect: when the user opens the app it catches up quickly and shows no wrong data.
4. Downloads and uploads. Start one, lock the phone. Expect: it resumes or fails with a clear retry.
5. Foreground services. Music, navigation, recording. Expect: they keep running and show a notification.
6. Opening after a long idle. Expect: no crash, no stale login, no blank screen.
7. Battery saver on while using the app. Animations may reduce, background refresh slows. Expect: the app is still fully usable.
8. User-facing explanations. If a feature depends on background work, does the app explain what to do when it is restricted? Expect: a helpful message, not silence.
9. Low battery warnings. Does the app behave when the battery is critical? Expect: no data loss on shutdown; unsaved work is kept.
10. Restricted app setting. Put your app in restricted background mode in app settings. Expect: the app still opens and works in the foreground.

What to report

Device model, Android version, which mode was on, how long the phone sat idle, what was expected and what happened, and the time of each event. Times matter for delayed notifications.

Limits

Behavior differs strongly between brands, and results change with updates. Treat one device as one data point, and ask testers with different brands.

Overview: Android app testing. Related: process death and permissions.

See how AppReviewX works: private, structured feedback from other developers. Ask each tester for phone brand and Android version.