WorkRequest: The Blueprint for Android Background Tasks
A WorkRequest is the blueprint for a background task in Android. It defines *what* work to do and *when*, letting WorkManager handle execution for tasks like syncing data. The footgun is putting logic in the request; it only configures, the Worker acts.
Why it exists
Android needs a reliable way to execute background tasks that can survive app closures and device reboots. Simple asynchronous operations are not guaranteed to finish. WorkManager provides this guarantee, and WorkRequest is the object we use to define and configure the work we want it to perform.
The mental model
A WorkRequest is a job ticket you hand to the WorkManager service. The ticket says: "Run the code in my DataSyncWorker class. But only start when the device has an unmetered network and is charging. If it fails, try again after 10 minutes." WorkManager is the foreman who reads this ticket, waits for the right conditions, and dispatches the worker to do the job.
How it works
You create either a OneTimeWorkRequest or a PeriodicWorkRequest using its builder. This builder lets you specify several key parameters. First, the Worker class that contains the actual code to be executed. Second, a set of Constraints that must be met, such as requiring a network connection or device charging. Third, you can provide input Data as a simple key-value map. Finally, you can define a BackoffPolicy to control retry behavior. Once configured, you hand the request to the system by calling WorkManager.getInstance(context).enqueue(yourWorkRequest).
When to use it
Use WorkRequest for deferrable, guaranteed background work. It's perfect for tasks that don't need to run immediately but must eventually complete, even if the app is killed or the device restarts. Common use cases include syncing local data with a server, uploading analytics, or applying filters to an image in the background.
When not to use it
Do not use WorkManager for tasks that must execute immediately while the user is interacting with the app; use Kotlin Coroutines for that. It is also not for tasks requiring precise timing, where AlarmManager is a better (though restricted) fit. For long-running tasks that the user must be aware of, such as music playback, a foreground Service is the correct component.
One canonical example
To schedule a one-time photo compression task that only runs when the device is idle, you would first define a CompressWorker. Then you'd build the request: val constraints = Constraints.Builder().setRequiresDeviceIdle(true).build(). Then, val compressionRequest = OneTimeWorkRequest.Builder(CompressWorker::class.java).setConstraints(constraints).setInputData(workDataOf("IMAGE_URI" to uriString)).build(). Finally, you enqueue it: WorkManager.getInstance(context).enqueue(compressionRequest). This tells WorkManager to run your worker with the image URI, but only when the device is not in active use.
Interview question
Which statement best describes the primary function of a WorkRequest in Android's WorkManager?
- a.It acts as a configuration blueprint, specifying the Worker class, conditions, and retry behavior for a task.Correct
- b.It contains the actual code and execution logic for a background task.
- c.It directly manages the scheduling and execution of all background operations across the entire device.
- d.It is responsible for immediately executing tasks that require precise timing or user interaction.
Why? this is the answer
A WorkRequest is described as a "blueprint" or "job ticket" that defines *what* work to do (by referencing a Worker class) and *when* (via constraints, input data, and backoff policy). It explicitly states that the request only configures, and the Worker acts, making option B incorrect.
Just read this? Test yourself on what you have been reading.
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
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