Why Background Work Needs Rules
Background work is work that an app must do when the user is not looking at it. Examples include uploading a file and syncing data and cleaning a cache and sending a reminder. The system restricts background work because unrestricted work drains battery and slows other apps and heats the device. A developer who ignores those restrictions will see work killed and users annoyed. A developer who works with the restrictions will see work complete reliably and battery stay healthy.
Older Android versions allowed long running background services with few limits. That freedom created apps that stayed alive forever and consumed resources in the background. Modern Android limits background execution and it encourages deferrable work through a scheduler. Deferrable work is work that can wait for a good moment. The system runs it when constraints are met and when battery and network conditions allow. That model protects the user while still letting apps stay fresh.
The key distinction is between work that must happen now and work that can wait. A music player must play now. A navigation app must track location now while navigating. A photo backup can wait until the device is charging and connected to Wi-Fi. A news sync can wait until the next convenient window. Choosing the right mechanism starts with that distinction. Urgent user visible work needs a foreground service. Deferrable work needs WorkManager.
Services in Plain Terms
A service is a component that runs without a user interface. A started service runs until it stops itself or until the system stops it. A bound service runs while another component is bound to it. A foreground service shows a persistent notification and it receives higher priority from the system. That notification tells the user that work is happening and it gives the user a way to stop it. Foreground services are the correct choice for work that the user started and expects to continue.
A background service without a notification has low priority on modern Android. The system may stop it soon after the app leaves the foreground. That behaviour surprises developers who expect a background service to run forever. The system also restricts starting a background service from the background in many cases. Those restrictions exist to stop apps from waking up silently and consuming resources without user knowledge.
Services still have a place for immediate work. A music player uses a foreground service with a media notification. A fitness tracker uses a foreground service while recording a workout. A file download that the user started may use a foreground service with progress in the notification. Each case is user visible and user initiated. The notification is not a burden in those cases because it matches user expectation.
WorkManager in Plain Terms
WorkManager is a scheduler for deferrable and guaranteed work. A developer defines a worker that does one unit of work. The developer defines constraints such as network availability and charging state and storage state. The developer defines a schedule such as one time work or periodic work. WorkManager then runs the worker when constraints are met. It survives app restarts and device restarts for persistent work. It chooses the best underlying scheduler for the device.
Guaranteed execution is the strongest promise of WorkManager. If the app is killed then the work remains scheduled. If the device restarts then the work remains scheduled for persistent work types. The system will run the work when conditions allow. That guarantee makes WorkManager the right choice for uploads and syncs and database maintenance that must eventually complete. It is not a timer for exact moments. It is a promise of eventual execution under the right conditions.
WorkManager also handles chaining and uniqueness. Chained work runs in order and later work can depend on earlier results. Unique work prevents duplicate schedules for the same logical job. A sync job can be marked as unique so that two triggers do not create two competing syncs. That control prevents wasted work and conflicting writes. It also simplifies code because the developer does not need a separate lock for the job.
Constraints and Scheduling Choices
Constraints describe the conditions that must be true before work runs. A network constraint waits for a connection. A charging constraint waits for power. An idle constraint waits for low device usage. A storage constraint waits for sufficient free space. Combining constraints narrows the window but it increases the chance that work runs at a good moment. A photo backup with charging and network constraints will run overnight rather than draining battery during the day.
One time work runs once when constraints are met. It can include an initial delay. It can be retried with a backoff policy when it fails. Periodic work runs repeatedly at an interval. The interval has a minimum that prevents very frequent polling. Periodic work is suited to regular syncs and cleanups. It is not suited to exact alarms or to real time updates. Exact timing needs a different mechanism with explicit user need.
Expedited work is a middle path for important work that should run soon. It requests faster execution while still going through WorkManager. It is not a replacement for a foreground service for long user visible work. It is useful for a short important task that must complete quickly after a trigger. Developers should use it sparingly because frequent expedited work undermines battery savings.
Foreground Services Done Right
A foreground service must declare its type and it must show a notification promptly after starting. The type describes the work such as media playback or location tracking or data sync. The notification must describe the work in plain language. The user must be able to stop the work from the notification or from the app. A foreground service that hides its purpose will be seen as intrusive even when the work is legitimate.
Long running foreground services should be used only while the user expects the work to continue. A music player stops its service when playback stops. A workout tracker stops its service when the workout ends. A download service stops when the download completes or fails. Stopping promptly returns resources to the system and it builds trust. A service that lingers after its job ends wastes battery and invites system restrictions.
Foreground service types also affect permission handling. Location work needs location permission. Media work needs media handling. Data sync work needs a clear type and a clear notification. The manifest declaration and the runtime permission must match the actual work. A mismatch can cause the service to fail to start or to be stopped by the system. Testing on a real device reveals those mismatches early.
Designing Reliable Workers
A worker should do one job well. A sync worker should sync one data set. An upload worker should upload one file or one batch. A cleanup worker should clean one cache. Small workers are easier to test and easier to retry. A large worker that does many jobs will retry all of them when one fails. That waste grows with the size of the worker. Splitting work into chained workers gives finer retry control.
A worker should be idempotent whenever possible. Idempotent work gives the same result when it runs twice. An upload that checks for an existing server copy is idempotent. A sync that applies changes by identifier is idempotent. Idempotence protects against duplicate runs caused by retries or by overlapping schedules. It also protects against a worker that is interrupted and then rerun.
A worker should return a clear result. Success means the job completed. Retry means the job should run again after backoff. Failure means the job cannot succeed without a change. Returning retry for a permanent failure wastes battery through repeated attempts. Returning failure for a transient network error loses work that could have succeeded later. The distinction between transient and permanent failure is a core design decision for every worker.
Battery and System Behaviour
Doze mode and app standby buckets change how background work runs. A device in Doze delays background work to maintenance windows. An app in a rare bucket receives fewer execution opportunities. An app in a frequent bucket receives more. User interaction moves an app to a better bucket. An app that the user rarely opens should not expect frequent background execution. Its work should be deferrable and tolerant of delay.
Battery optimisation settings can further restrict an app. A user may exempt an app from optimisation for a legitimate reason such as a workout tracker. Most apps should not ask for exemption without a clear user visible need. Asking for exemption for a simple sync will look suspicious and may be denied. WorkManager already handles most sync needs without exemption. Exemption is a last resort rather than a default.
Testing under Doze and under low battery reveals real behaviour. A worker that runs instantly on a developer device may wait hours on a user device in Doze. The team should test with the device idle and with battery saver on. The team should also test after a device restart. Work that survives restart and Doze will behave predictably in the field. Work that only works on a charging developer device will disappoint users.
Connections to Nearby Topics
Background design connects to state design because a worker may finish while the user interface is gone and the app must present the result cleanly when the user returns and the guide to app state and lifecycle events explains how restored screens should show completed background results. Storage design also connects because a worker often writes to a local database and the comparison of shared preferences versus Room database helps a team choose the right store for worker output. Layout work connects less directly but a user who returns after background work needs a clear screen and the guide to responsive layouts in Jetpack Compose shows how that returning screen can adapt to any device.
Migration From Old Services
Migration should start by listing every background service in the app and classifying each one as urgent or deferrable. Urgent user visible work stays as a foreground service with a proper notification and type. Deferrable work moves to WorkManager with constraints that match the original intent. Work that runs on a fixed timer for no user reason should be questioned rather than migrated blindly. Some old timers exist only because no scheduler was available at the time.
Each migrated job needs a test for restart survival and for constraint behaviour. Kill the app after scheduling the job and confirm that the job still runs. Restart the device and confirm that persistent work still runs. Disable network and confirm that a network constrained job waits rather than failing permanently. Enable network and confirm that the job then runs. Those tests prove that migration preserved the original promise.
Monitoring after migration matters as much as the migration itself. Log worker results and retry counts and failure reasons. A worker that retries constantly signals a permanent failure misclassified as transient. A worker that never runs signals a constraint that is too strict. A worker that runs too often signals a duplicate schedule. Telemetry turns background work from invisible behaviour into observable behaviour.
Common Mistakes to Avoid
One common mistake is using a background service for deferrable sync. The service will be killed and the sync will fail silently. Another mistake is using WorkManager for exact timing. The work will run late and the user will miss the expected moment. A third mistake is scheduling periodic work with a very short interval for polling. The battery cost will be high and the system may throttle the app.
Another mistake is ignoring idempotence. A retried upload creates duplicates on the server. A retried sync applies the same change twice. A further mistake is returning retry for every failure. A permanent failure will then loop forever and drain battery. A final mistake is forgetting to stop a foreground service. The notification lingers and the user loses trust in the app.
// WorkManager request example in Kotlin
// val request = OneTimeWorkRequestBuilder<SyncWorker>()
// .setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build())
// .build()
// WorkManager.getInstance(context).enqueueUniqueWork("sync", ExistingWorkPolicy.KEEP, request)
