Background work on Android
The app's main thread (also called the UI thread) draws frames and handles touches. Anything that blocks it for more than five seconds turns into an ANR — "application not responding". So every network or file operation must move off it. But "the background" on Android is not one tool but a whole set with different guarantees: a raw thread dies with the process, the Service component sits on the main thread by default, and in power-saving mode the system defers almost everything.
The beginner's trap is to read "background" as "runs forever". In reality the process can be killed at any moment, and Doze mode freezes the network and defers jobs to a maintenance window. The answer depends on the requirements — is the work needed right now and in front of the user, or is it deferrable but guaranteed work that must survive a restart? The full map lives in the layers below.
Topic map
- Background work and Doze — why you cannot load the UI thread, what a raw
Threadrisks, and howDozethrottles the background. - The Service component — started, bound, and foreground
Service, the main-thread trap, and the truth aboutSTART_STICKY. - WorkManager — deferrable, guaranteed work that survives process death, with constraints, retry, and
setForeground.
Common traps
| Mistake | Consequence |
|---|---|
Thinking a Service runs off the main thread by default | Long work blocks the UI thread and triggers an ANR |
Loading a multi-minute task onto a raw Thread | The process gets killed — the work vanishes with no resume |
Assuming a started Service is exempt from Doze | Under Doze the network and timers are throttled until you go foreground |
Believing START_STICKY re-delivers the original Intent | On restart you get a null Intent, not your payload |
Thinking WorkManager can only defer, never run now | It handles both deferred and expedited work; long-running goes foreground |
| Forgetting the ongoing notification for foreground work | The system denies foreground status and kills the task quickly |
Interview relevance
The topic is asked to check whether you separate background mechanisms by their guarantees, not by name. A candidate who says "a raw Thread does not survive process death, so for guaranteed work I take WorkManager, and for visible-right-now work a foreground Service" gets ahead of "well, I'd run it in the background".
Typical checks:
- Why you must not block the UI thread and what an ANR is.
- That a
Servicelives on the main thread by default and you must move work off it yourself. - How
Dozethrottles the background and why foreground bypasses it. - When to reach for
WorkManagerversus a foregroundService, and what happens to the task if the process is killed.
Common wrong answer: "a Service creates its own background thread, and START_STICKY restores the task with its data". In fact a Service runs on the main thread, and START_STICKY restarts the component with a null Intent — restoring state is on you.