Answer First
Definition: Android Doze mode — together with App Standby and OEM battery-optimization settings — is the power-management layer that suspends background app activity when a device is idle, and it is one of the most common silent failure modes in Android automation. When it engages, your task’s app is frozen mid-run: network access is cut, alarms and jobs are deferred, and the process may be killed outright. To the script there is no error — the task just stops making progress.
Why: Cloud phone automation depends on an app working when no one is looking — overnight, on a headless device, between human check-ins. Android’s power management assumes an unattended, motionless, screen-off device is not in use, and saves battery by suspending background work. A task that runs flawlessly in a demo (screen on, plugged in, someone watching) can die at 2 a.m. because the device was judged idle. Operators read a clean log and blame the script; the real cause lives in the device’s power state, not the code.
Example: A monitoring task checks a messaging app every 20 minutes. By 2 a.m. the device has been stationary with the screen off for hours, so deep Doze engages; the next run is deferred, the app never wakes, and nothing is written to the log. At 7 a.m. a human finds the last successful run was hours ago — or a run that stalled halfway, with no error. Clean logs, stopped progress, unattended hours: that is the fingerprint of a power-management kill.
Key Facts
- Doze triggers on idle conditions — screen off, stationary, unplugged — not on anything your script does, escalating from light to deep.
- Doze restricts network access, defers alarms and jobs, and freezes processes; deep Doze grants only brief maintenance windows.
- App Standby buckets apps (active, working set, frequent, rare, restricted); less-used apps get tighter limits on background work.
- OEM battery managers (Xiaomi, Samsung, Huawei, OPPO, vivo, and others) add autostart, battery-saver, and app-freeze settings on top of stock Android, often more aggressive than Doze.
- Signature of a power-management kill: logs end abruptly or stall with no exception; failure only when idle or unattended; the same task succeeds with the screen on.
- Diagnosis is device-level:
dumpsys deviceidlefor idle state, battery settings for exemptions,dumpsys jobscheduler/dumpsys alarmfor deferred work. - Prevention on managed devices is well understood: exemption from battery optimization, a foreground-service model, and a clean device image.
Expert Explanation
What Android’s power management actually does
Android treats idle as the enemy of battery life. Doze begins when three conditions hold: screen off, unplugged, stationary. In light Doze, network access is deferred and jobs and alarms are batched; in deep Doze, processes are frozen entirely and work happens only in brief maintenance windows. All decided by the OS from device state — your script never gets a vote.
App Standby is a parallel system: Android tracks how recently and how often each app is used, and less-used apps get throttled background work — an automation app that only runs at night can be throttled exactly when its job starts.
Then come the OEM layers: most manufacturers ship their own power managers — “autostart,” “battery saver,” “app freeze” — that can suspend apps even when they would be fine under stock Android, including apps running foreground services. Treat them as part of the managed fleet’s device image baseline.
Why the script dies without an error
This is what sends operators down the wrong path. When Doze freezes the app, its code stops executing: no exception, no log line, no server notification — it is simply not running. The failure is produced by the power manager, outside the app; an orchestration-layer timeout just marks the task failed or hung, and the device-side evidence is an empty gap in the log. Mobile automation fails in ways that leave the script silent — which is why AI agents need logs, and mobile automation needs them even more.
Why long unattended AI workflows make this worse
Teams increasingly run AI workflows that are longer, less supervised, and scheduled while a human sleeps — exactly what triggers Doze. “It worked in the demo” is almost guaranteed, because demos run with the screen on; the overnight run is where power management engages. As AI agents become apps, someone still has to handle the mobile operations layer — and that layer is where power-state problems live.
What actually works on managed devices
- Exempt the app from battery optimization. In device settings: battery → app → “don’t optimize”; apps can also request this exemption. This removes the most common cause of idle suspension on stock Android.
- Use a foreground-service model. An app with an active foreground service and visible notification is treated as actively in use and exempt from most idle restrictions. But newer Android versions require a declared type and matching permission — the same permission and audit discipline as the rest of mobile automation — and some types carry runtime limits.
- Disable OEM power managers in the device image. Autostart whitelists, battery-saver exclusions, and app-freeze lists should be configured per manufacturer, baked into the baseline, and verified on a reference device.
- Watch the device, not just the script. A device heartbeat plus battery, idle, and network telemetry tells you whether the device was in Doze when the task stalled — the visibility operations teams actually need in a control tower for mobile workflows.
- Expect suspension anyway. Design retries to be idempotent and make “no progress for N minutes” an alertable condition — because what happens after an agent fails mid-task should be defined before it happens, not after.
Practical limits
- A battery-optimization exemption is a request the system honors, not an ironclad guarantee — and OEM managers can override it.
- Foreground services cost battery, show a persistent notification, and are constrained by type and duration on newer Android versions.
- You cannot exempt an app you don’t control; if automation relies on third-party apps, their background behavior is out of your hands.
- Diagnostics require device access. If your only view is the script log, you may never see the real cause — hence device-level monitoring and human review.
Decision Framework
Use this table to classify the next stalled task before rewriting code.
| Check | How to test | Points to script bug | Points to power-management kill |
|---|---|---|---|
| Timing | Review run history | Fails at any hour, even screen-on | Only fails when idle or unattended |
| Manual rerun | Run with screen on, plugged in | Still fails | Succeeds |
| Log ending | Inspect the last lines | Exception, stack trace, bad response | Clean log; progress just stops |
| Device idle state | dumpsys deviceidle over adb | Normal / not idle | Device in light or deep idle |
| Battery settings | App battery page | — | App in “restricted” or battery-saver list |
| Deferred work | dumpsys jobscheduler, dumpsys alarm | — | Jobs or alarms pending, deferred |
| After exemption | Exempt the app, rerun overnight | Still fails | Runs clean overnight |
Operator checklist: (1) reproduce with the screen on; (2) confirm the log ends clean; (3) check the app’s battery settings; (4) verify device idle state at failure time; (5) only then touch the script. If the failure reproduces only when unattended and disappears after exemption, you were never debugging a script bug.
Key Takeaways
- Most “random” overnight failures in Android automation are power management, not script bugs — the tell is a clean log with stopped progress during idle hours. Verify before rewriting code.
- Prevention is a stack: exemption, foreground-service model, OEM settings in the image, and device-level monitoring.
- Treat “no progress” as an alertable event, not a morning discovery.
- Monitoring plus human review — the discipline that catches silent deaths — is what keeps long unattended AI workflows trustworthy.
FAQ
Q: Does Doze mode affect cloud phones the same way as physical devices?
A: Cloud phones are Android instances running on servers, and they still run Android’s power management. Whether Doze engages depends on the fleet’s device image — screen state, charging emulation, and idle settings vary by provider. The safe assumption is that power management exists until verified otherwise: test overnight runs under idle conditions rather than assuming a server-hosted device behaves like a phone in your hand.
Q: If I exempt the automation app from battery optimization, is that enough?
A: It removes the most common cause on stock Android, but is not a guarantee: OEM battery managers can still suspend the app, and newer foreground-service types carry their own limits. The reliable combination is exemption plus a foreground-service model plus device-level monitoring, so any suspension stays visible.
Q: Why does the script log show no error if the task died?
A: Because the OS froze the app — it never executed code that could throw or log. The failure happened in the power manager, outside the app, so there was nothing for the script to report. Look at device-level signals (idle state, battery settings, deferred jobs) instead of the app log.
Q: How do I tell an app crash from a power-management kill?
A: A crash usually leaves an exception or stack trace and reproduces with the screen on. A power kill leaves clean logs, happens only when the device is idle or unattended, and correlates with device state — a restricted battery list, or the device in Doze at failure time. If the task runs fine with the screen on but dies overnight, suspect power management first.
Sources
- Optimize for Doze and App Standby — Android Developers — Doze idle conditions, light/deep stages, maintenance windows, and the battery-optimization exemption.
- App Standby Buckets — Android Developers — the usage-bucket model that throttles background work for less-used apps.
- Foreground services — Android Developers — how a foreground service keeps an app active, and type/permission requirements on newer Android versions.