Android 12 foreground service restrictions and WorkManager expedited jobs
Tests Android 12 background-start limits. A great answer covers: the API 31 ban on background FGS starts, BOOT_COMPLETED exceptions, and WorkManager setExpedited with out-of-quota fallback. Red flag: starting an FGS in a BroadcastReceiver ignoring quota.
What's really being asked
This question probes your depth on Android 12 behavior changes for background execution, specifically the restriction on starting foreground services from background contexts. Interviewers want to see that you know the modern replacement API, WorkManager expedited jobs, and that you understand quota limits rather than treating background work as unlimited.
The full answer
First, state that Android 12 (API level 31) generally prohibits apps from starting foreground services when running in the background, with only a few narrow exceptions such as receiving a BOOT_COMPLETED broadcast or a high-priority Firebase Cloud Message. Second, explain that WorkManager offers expedited work via setExpedited, which internally runs as a foreground service but is managed by the system and subject to quota limits. Third, mention the OutOfQuotaPolicy parameter, specifically RUN_AS_NON_EXPEDITED_WORK_REQUEST, which defines graceful degradation when the app exceeds its expedited job quota. Fourth, describe the BroadcastReceiver scenario: instead of calling startForegroundService directly from onReceive, you enqueue a OneTimeWorkRequest built with setExpedited and an appropriate fallback policy, letting WorkManager handle the service lifecycle and notification.
The mistakes people make
A major red flag is proposing to start a raw foreground service directly from a BroadcastReceiver without acknowledging the API 31 restriction. Another weak pattern is mentioning JobScheduler instead of WorkManager, since the question explicitly asks for WorkManager's expedited jobs. Candidates who say expedited jobs are identical to normal foreground services also lose points; the interviewer expects you to note the quota system and automatic fallback behavior.
What usually comes next
The interviewer may ask how expedited job quotas are calculated, typically based on app standby buckets and a rolling window. They might also ask what happens if you target Android 13 or 14, where notification permissions and additional foreground service types further constrain behavior. Another common follow-up is how to test this in a unit test or integration test, or how to handle the notification requirement when WorkManager manages the foreground service notification for you.
A concrete example
Suppose your app receives a BOOT_COMPLETED broadcast and must immediately sync critical configuration. Prior to Android 12 you might have called startForegroundService from the receiver. On API 31 and above, you instead create a OneTimeWorkRequest, call setExpedited with OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST, and enqueue it with WorkManager. If your app has quota, WorkManager promotes it to an expedited job running as a foreground service; if quota is exhausted, it falls back to regular work and completes later without crashing or violating platform restrictions.
Interview question
When handling a BOOT_COMPLETED broadcast on an Android 12+ device, why is enqueueing a WorkManager expedited job with OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST preferable to directly calling startForegroundService from the receiver?
- a.Expedited jobs execute with higher priority than any raw foreground service and ignore app standby bucket restrictions
- b.WorkManager handles the foreground service notification and gracefully falls back to regular work if the expedited quota is exhausted, avoiding a crashCorrect
- c.The broadcast receiver automatically grants a temporary quota extension that prevents fallback to regular work
- d.Raw foreground services are prohibited on API 31 and above regardless of context, including during BOOT_COMPLETED
Why? this is the answer
WorkManager manages the notification and service lifecycle, and the fallback policy ensures the task completes later rather than crashing if quota is exhausted. Option D is tempting because API 31 heavily restricts background starts, but BOOT_COMPLETED is explicitly listed as a narrow exception where raw foreground services are still allowed.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #workmanager
- #background execution
- #android 12
- #foreground services
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles