Background work and notifications cheat sheet

The 7 Background work and notifications interview answers in 30 seconds each, plus quick facts. Printable, free.

One page per topic: print it or save it as PDF from your browser's print menu. Practise these questions

Rules of thumb

  • WorkManager for deferrable, guaranteed work; never for exact times.
  • Unique work names prevent duplicate jobs.
  • Expedited starts now; setForeground runs long.
  • Exact alarms only for user-facing timing, with the permission checked.
  • Channels by purpose, POST_NOTIFICATIONS on Android 13+.

WorkManager basics

Use WorkManager for deferrable work that must run even if the app is closed or the device restarts: uploading logs, syncing, cleaning caches. It persists work requests in its own database, respects constraints like network or charging, retries with backoff, and picks the right system scheduler. It doesn't guarantee exact timing; the system batches work to save battery.

Chaining work and constraints

Use WorkManager.beginWith(a).then(b).then(c).enqueue(), or beginUniqueWork to name the chain. Each worker's output Data becomes the next worker's input; parallel workers' outputs are merged with an InputMerger. If one worker fails, its dependents are marked failed too. Constraints apply per request, so only the upload step may need Wi-Fi.

Expedited and long-running work

setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) asks the system to start the work right away, for short tasks the user cares about, like sending a message. It's limited by a quota. For work longer than about 10 minutes, a long-running worker calls setForeground() with a notification and a foreground service type, so it runs as a foreground service managed by WorkManager.

Doze and App Standby

In Doze, when the device is still and unplugged with the screen off, the system defers jobs, alarms and network access to short maintenance windows. App Standby buckets (active, working set, frequent, rare, restricted) limit how often each app's jobs and alarms run based on how recently it was used. Work isn't lost, but it's delayed, sometimes for hours.

Exact alarms

Exact alarms fire at a precise time even in Doze, but they cost battery, so they're reserved for user-facing timing like alarm clocks, calendar reminders and timers. Since Android 12 you need SCHEDULE_EXACT_ALARM, which users can revoke, and since Android 14 it's denied by default for most new installs. Alarm and calendar apps can use USE_EXACT_ALARM instead. Everything else should use inexact alarms or WorkManager.

Notifications and channels

Create a NotificationChannel (Android 8+) with an importance level once, usually at startup, then build notifications with NotificationCompat.Builder on that channel. On Android 13+ you also need the POST_NOTIFICATIONS runtime permission. Use a content intent with an immutable PendingIntent, and pick channels by purpose so users can turn off marketing without losing order updates.

Push messages with FCM

The app gets a registration token from FCM and sends it to your server, which sends messages to that token through FCM. Notification messages are shown by the system automatically when the app is in the background. Data messages always go to onMessageReceived in your FirebaseMessagingService, so you control display and logic. Tokens can change, so handle onNewToken.

Quick facts

PeriodicWorkRequest minimum
PeriodicWorkRequest can't repeat more often than every 15 minutes.
WorkManager Data limit
WorkManager's input and output Data is limited to about 10 KB.
BOOT_COMPLETED
Alarms are cleared on reboot; apps reschedule them from a BOOT_COMPLETED receiver.
Notification importance
Once a channel is created, only the user can change its importance.