Services & Background Work Quiz
ANDROID › Components
You need to upload analytics logs to your server. The upload should be reliable, can wait for Wi-Fi, and must survive the app being killed or the device rebooting. What should you use?
- A background Service started with startService()
- WorkManager with a network constraint
- AlarmManager with setExactAndAllowWhileIdle()
- A foreground service with a persistent notification
Answer: WorkManager with a network constraint
Deferrable, guaranteed work that must persist across process death and reboot, optionally gated on network type, is exactly WorkManager's job; it persists requests and reschedules after reboot.
A Service's onStartCommand returns START_STICKY. The system kills the service under memory pressure with no pending start intents. What happens?
- The service is not recreated until startService is called again
- The service is recreated and onStartCommand gets a null intent
- The service is recreated and the last start intent is redelivered
- The service restarts, but onCreate is skipped during the restart
Answer: The service is recreated and onStartCommand gets a null intent
START_STICKY recreates the service after a kill and calls onStartCommand with a null intent when there are no pending intents, which is why sticky services must tolerate a null intent.
Targeting Android 14 (API 34), which is now required to legally run a foreground service?
- Nothing beyond the standard FOREGROUND_SERVICE manifest permission
- Calling startForeground() within 10 seconds of the background service being created
- Declaring a specific foregroundServiceType in the manifest and meeting its rules
- Disabling battery optimization for the app in the system settings
Answer: Declaring a specific foregroundServiceType in the manifest and meeting its rules
Since API 34, every foreground service must declare a specific foregroundServiceType in the manifest and satisfy that type's runtime requirements and permissions, or it throws at runtime.
Which statement about a default Service's threading is correct?
- A Service automatically moves its work to a background thread
- A Service runs in a separate process by default, not the app one
- A Service has a built-in coroutine scope for IO-bound work
- A Service runs on the app's main thread and can cause ANRs
Answer: A Service runs on the app's main thread and can cause ANRs
A Service does not create its own thread or process; it runs on the application's main thread, so blocking work must be moved off it to avoid ANRs.
Why is a plain background Service started with startService() discouraged on modern Android?
- API 26+ limits background services when the app isn’t foregrounded
- startService() was removed from the SDK in newer Android releases
- Background services can only be implemented in Java, not in Kotlin
- Services cannot use the network at all, even while the app is running
Answer: API 26+ limits background services when the app isn’t foregrounded
Starting with API 26, the system restricts background services while the app is not in the foreground, which is why WorkManager or a foreground service is preferred for ongoing background work.
Which task is the correct fit for AlarmManager rather than WorkManager?
- Periodically syncing data with a server every few hours
- Compressing images when the device is idle and charging
- Firing a user-facing alarm clock at an exact time
- Retrying a failed upload with exponential backoff
Answer: Firing a user-facing alarm clock at an exact time
AlarmManager is for precise wall-clock execution such as alarms and reminders; deferrable, constraint-based, or retrying background work belongs to WorkManager.
What is the minimum repeat interval allowed for a PeriodicWorkRequest in WorkManager?
- 15 minutes, the minimum periodic interval WorkManager enforces
- 1 minute, matching the shortest JobScheduler periodic window allowed
- 5 minutes, the floor AlarmManager allows for repeating alarms
- 60 minutes, the interval Doze mode forces on all periodic work
Answer: 15 minutes, the minimum periodic interval WorkManager enforces
WorkManager caps periodic work at a minimum interval of 15 minutes to protect battery; requesting less is clamped up to 15 minutes.
A Service is only ever connected to via bindService() with BIND_AUTO_CREATE and is never started with startService(). When does the system destroy it?
- When stopSelf() is called from inside the service
- After about 5 seconds with no active method calls
- When the last bound client unbinds or is itself destroyed
- Only when the device reboots or the process is killed for memory
Answer: When the last bound client unbinds or is itself destroyed
A purely bound service lives only as long as at least one client is bound; once the final client calls unbindService (or dies), the system tears it down. stopSelf applies to started services, not bound-only ones.
A started service does critical work driven by the start intent's data, and you want the system to re-run that exact job if it kills the service before the work finishes. Which onStartCommand return value should you use?
- START_REDELIVER_INTENT
- START_STICKY — restarts service, but with a null intent
- START_NOT_STICKY — won't restart the service after kill
- START_FLAG_REDELIVERY — a flag, not a return value
Answer: START_REDELIVER_INTENT
START_REDELIVER_INTENT recreates the service after a kill and redelivers the last intent, so work tied to that intent's data is retried. START_STICKY redelivers a null intent, and START_NOT_STICKY does not restart at all.
An app calls startForegroundService() but the service never calls startForeground() within the roughly 5-second window the system allows. What is the typical result?
- The system throws a timeout exception and may ANR or crash the app
- The service is silently downgraded to a normal background service
- Nothing happens; the deadline only applies on Android 14 and above
- The system creates a default notification automatically on the app's behalf
Answer: The system throws a timeout exception and may ANR or crash the app
After startForegroundService, the app must promote the service with startForeground within about 5 seconds or the system raises a timeout (ForegroundServiceDidNotStartInTimeException), which can ANR or crash the process.
On Android 12 (API 31), a non-exempt app that is currently in the background tries to start a foreground service. What typically happens?
- It succeeds exactly as it did on older versions
- It is automatically converted into an equivalent WorkManager job
- It starts but the ongoing notification stays hidden from the user
- It throws a ForegroundServiceStartNotAllowedException
Answer: It throws a ForegroundServiceStartNotAllowedException
API 31 blocks starting foreground services from the background in most cases, throwing ForegroundServiceStartNotAllowedException; you must use an allowed exemption or defer the work via WorkManager/expedited work instead.
Inside a WorkManager worker you need to call suspend functions and other coroutine-based APIs. Which base class is designed for that?
- Worker, wrapping the body in runBlocking inside doWork()
- RxWorker returning a Single from doWork()
- CoroutineWorker, overriding its suspend doWork()
- ListenableWorker with a manually managed background thread
Answer: CoroutineWorker, overriding its suspend doWork()
CoroutineWorker exposes a suspend doWork() that runs in a coroutine (Dispatchers.Default by default) and is cancelled cooperatively when the work stops, making it the idiomatic choice for suspend-based work.
Which statement about WorkManager and JobScheduler is correct on modern Android (API 23 and above)?
- WorkManager and JobScheduler can never be used together in the same app
- WorkManager uses JobScheduler internally, so you target WorkManager, not JobScheduler
- JobScheduler survives a device reboot, but WorkManager loses all of its enqueued work on restart
- JobScheduler is mandatory for any work that carries a network-type constraint
Answer: WorkManager uses JobScheduler internally, so you target WorkManager, not JobScheduler
On API 23+ WorkManager uses JobScheduler as its backing scheduler while adding persistence, constraints, chaining, and a single consistent API, so app code targets WorkManager instead of JobScheduler directly.
IntentService is deprecated. For the serialized background work it used to handle, what is the recommended modern replacement?
- Subclass a bare Service and use Thread.sleep() to serialize every incoming queued request
- Move the queue logic into a chained sequence of AsyncTask calls
- Re-enable IntentService via a manifest backward-compatibility flag
- Use WorkManager, or JobIntentService, since background services are now restricted
Answer: Use WorkManager, or JobIntentService, since background services are now restricted
IntentService relied on background-service behavior that API 26+ restricts, so Google recommends WorkManager for deferrable guaranteed work (or JobIntentService as a transitional bridge) instead of resurrecting a background Service.