Battery & Power Flashcards
PERFORMANCE › Runtime
- What conditions trigger Doze mode, and what does it defer?
- When the device is unplugged, stationary, and the screen is off for a while, Doze defers background CPU and network access, JobScheduler/WorkManager jobs, sync adapters, standard AlarmManager alarms, and Wi-Fi scans, and it ignores wake locks. Work runs only during periodic maintenance windows.
- What are Doze maintenance windows and how do they change over time?
- Brief periods when the system temporarily exits Doze to let deferred jobs, syncs, and alarms run and apps get network access. They occur less and less frequently the longer the device stays idle, to save more battery.
- Name the App Standby Buckets from least to most restricted.
- Active (in use now), Working set (used often), Frequent (used regularly but not daily), Rare (rarely used), and Restricted (consumes too many resources / not used for ~8 days on API 33+). 'Never' is a special bucket for installed-but-never-run apps.
- What does the Restricted standby bucket limit an app to?
- Roughly one batched job session per day (grouped with other apps' work), about one alarm per day, severely limited network, and far fewer expedited jobs. These limits apply even while charging unless the device is idle on an unmetered network.
- How do you run a deferrable background task that respects power management?
- Use WorkManager. It's the recommended API for deferrable, guaranteed work; it picks JobScheduler under the hood, honors Doze/standby and Constraints, and persists work across reboots and process death.
- Which AlarmManager methods can fire during Doze, and what's the limit?
- setAndAllowWhileIdle() and setExactAndAllowWhileIdle() fire even in Doze, but each can trigger at most once every ~9 minutes per app. setAlarmClock() also wakes the device. Exact alarms additionally need SCHEDULE_EXACT_ALARM or USE_EXACT_ALARM.
- How do you wake an idle app for a time-sensitive push without an exemption?
- Send an FCM high-priority message. The system briefly wakes the app from Doze/standby, granting temporary network access and a wake lock. High priority should be reserved for user-visible, time-critical content or it gets deprioritized.
- Why is a constant background wake lock or polling loop bad, and what replaces it?
- Wake locks keep the CPU awake and bypass Doze savings, draining the battery; polling causes constant radio wakeups. Replace with WorkManager + constraints for deferrable work, FCM for server-pushed updates, and batched/inexact alarms to coalesce radio use.
- How do you test and diagnose Doze, standby, and battery drain?
- Force Doze with adb shell dumpsys deviceidle force-idle and set buckets with adb shell am set-standby-bucket. Profile drain with Battery Historian (from a dumpsys batterystats bugreport) and inspect scheduled work via adb shell dumpsys jobscheduler.