Battery & Power Quiz
PERFORMANCE › Runtime
An app schedules a WorkManager request with no constraints while the device is deep in Doze. When does the work most likely run?
- Immediately, because WorkManager is fully exempt from Doze
- During the next Doze maintenance window or after Doze ends
- Never, because Doze cancels every WorkManager request outright
- Exactly 9 minutes later, when the next alarm slot opens
Answer: During the next Doze maintenance window or after Doze ends
WorkManager uses JobScheduler, whose jobs are deferred by Doze and run during periodic maintenance windows or once the device leaves Doze. The work is deferred, not cancelled.
Which conditions must all hold for the system to put a device into Doze mode?
- Charging, screen on, and connected to Wi‑Fi
- Unplugged, still, and screen off for some time
- Low battery, Battery Saver on, and idle in background
- Airplane mode on, with the app in the background
Answer: Unplugged, still, and screen off for some time
Doze engages when the device is unplugged from power, stationary (not moving), and has the screen off for an extended period. Movement, screen-on, or plugging in exits Doze.
An app falls into the Restricted standby bucket. What is the approximate limit on its jobs?
- About one batched job session per day, grouped with other apps
- Unlimited jobs as long as the device is charging and plugged in
- One job per hour with full network access and no extra batching
- Ten expedited jobs per day with no batching or other delays
Answer: About one batched job session per day, grouped with other apps
The Restricted bucket allows roughly one batched job session per day (coalesced with other apps), about one alarm per day, and severely limited network, even while charging on a metered connection.
A messaging app needs to deliver a time-critical call notification to a device that is in Doze. What is the recommended approach?
- Hold a permanent partial wake lock in a background service
- Poll the server every 60 seconds with a repeating alarm
- Send an FCM high-priority message
- Schedule a periodic WorkManager task every 15 minutes
Answer: Send an FCM high-priority message
FCM high-priority messages temporarily wake the app from Doze with network access and a wake lock, and are intended exactly for time-sensitive, user-visible notifications like incoming calls.
What is true about Doze maintenance windows over a long idle period?
- They keep occurring every 15 minutes for the entire idle period
- They happen more often so queued work can run sooner and faster
- They happen less often the longer the device stays idle
- They only happen while the app is holding a wake lock
Answer: They happen less often the longer the device stays idle
To maximize battery savings, the system schedules maintenance windows progressively less often the longer the device remains in Doze, so deferred work runs in fewer, spaced-out bursts.
Which WorkManager Constraint would you add so a large upload only runs when it won't hurt the user's battery or data?
- setRequiresCharging(true) with setRequiredNetworkType(UNMETERED)
- setRequiresDeviceIdle(true) alone, ignoring the network type
- setRequiresBatteryNotLow(false) paired with any network type
- No constraints at all, and call setExpedited() to bypass the limits
Answer: setRequiresCharging(true) with setRequiredNetworkType(UNMETERED)
Requiring charging plus an unmetered (e.g., Wi-Fi) network ensures the heavy upload defers until the device is plugged in and not on cellular data, the battery- and data-friendly choice.
Which statement about setAndAllowWhileIdle()/setExactAndAllowWhileIdle() alarms is correct?
- They are ignored during Doze, just like ordinary inexact alarms
- They can fire during Doze, but only about once every 9 minutes per app
- They can fire freely during Doze, with no per-app rate limiting at all
- They require the app to sit on the Doze exemption whitelist first
Answer: They can fire during Doze, but only about once every 9 minutes per app
These special alarm methods are allowed to fire while the device is idle, but the system rate-limits them to roughly once every 9 minutes per app to preserve battery; no whitelist is required.
Regarding WorkManager expedited work (setExpedited) on modern Android, which statement is accurate?
- Expedited jobs ignore the standby bucket and run instantly once enqueued
- They run at foreground-like importance but draw from a standby-limited quota
- They can only be enqueued while the app is in the foreground and visible
- They are deferred exactly like periodic work and never run during Doze
Answer: They run at foreground-like importance but draw from a standby-limited quota
Expedited jobs get elevated importance and run as soon as possible, but each app has an expedited-work quota that depends on its App Standby Bucket, and an OutOfQuotaPolicy decides what happens when the quota is exhausted.
What is true about asking users to exempt your app from battery optimizations via REQUEST_IGNORE_BATTERY_OPTIMIZATIONS?
- Once granted, the exemption can never be revoked and is permanent
- It is granted silently at install time with no user interaction at all
- It also exempts the app from every runtime permission prompt too
- Play limits it to a few justified categories; most apps should work within Doze
Answer: Play limits it to a few justified categories; most apps should work within Doze
Google Play policy limits REQUEST_IGNORE_BATTERY_OPTIMIZATIONS to a small set of justified use cases, so the recommended approach for the vast majority of apps is to schedule work that respects Doze and App Standby rather than seek an exemption.
Which factor most directly determines which App Standby Bucket the system assigns to an app?
- How recently and how often the user actually uses the app
- The size of the APK and how many permissions it declares
- The app's targetSdkVersion and nothing else in practice
- Whether it's signed with a release key instead of a debug key
Answer: How recently and how often the user actually uses the app
The system assigns buckets based on observed usage patterns (recency and frequency of user interaction), using on-device heuristics; APK size, target SDK, and signing key do not drive bucketing.
You want to analyze what kept the device awake and drained the battery overnight. What is the correct way to get data into Battery Historian?
- Point Battery Historian at the running app over USB with no setup
- Paste the raw output of adb shell dumpsys jobscheduler into it
- Capture a bug report with dumpsys batterystats data and load it
- Enable StrictMode and feed it the resulting logcat warnings
Answer: Capture a bug report with dumpsys batterystats data and load it
Battery Historian visualizes a bug report (which includes dumpsys batterystats history); you reset stats, reproduce, then run adb bugreport and load the resulting file.
A non-clock, non-calendar app needs to fire an exact alarm on Android 13 (API 33) or newer. Which is correct?
- Exact alarms were removed entirely, so only inexact alarms remain
- It must hold SCHEDULE_EXACT_ALARM, which users can deny or revoke
- Any app may schedule exact alarms on Android 13+ without any permission
- It should declare USE_EXACT_ALARM, meant for general reminders and timers
Answer: It must hold SCHEDULE_EXACT_ALARM, which users can deny or revoke
On Android 13+ SCHEDULE_EXACT_ALARM is no longer granted by default to newly installed apps and is user-revocable; USE_EXACT_ALARM is reserved for genuine alarm-clock or calendar apps, not general timers.
An app must run ongoing, user-visible work such as live workout tracking with GPS that the OS should not defer during Doze. What is the right mechanism?
- A periodic WorkManager job, scheduled about every 15 minutes in the background
- An inexact repeating AlarmManager alarm that can still be batched by the OS
- A high-priority FCM message sent to the device itself to keep work running
- A foreground service with a persistent notification and foregroundServiceType
Answer: A foreground service with a persistent notification and foregroundServiceType
Continuous, user-aware work belongs in a foreground service, which shows a persistent notification and keeps running with CPU and network access without being deferred by Doze; deferrable schedulers like WorkManager or alarms are the wrong fit.
How does Doze treat a normal-priority FCM message that arrives while the device is idle?
- It wakes the device right away, just like a high-priority message
- It is dropped for good and never reaches the app at all
- It is held until the next maintenance window or Doze ends
- It is raised to high priority so it can wake the app immediately
Answer: It is held until the next maintenance window or Doze ends
In Doze, only high-priority FCM messages get immediate delivery with a temporary network window; normal-priority messages are held and delivered during the next maintenance window or when the device leaves Doze.