How would you implement a constrained photo upload with WorkManager?

Tests knowledge of WorkManager constraints and retry policies for deferrable background uploads. A strong answer names OneTimeWorkRequest with Constraints for charging and unmetered network, plus BackoffPolicy for retry.
WHAT THIS TESTS: This question evaluates whether you understand the modern Android background execution model and when to use WorkManager versus foreground services or AlarmManager. Specifically, it checks if you know how to express constraints, pass data into a worker, handle retries, and persist work across process death without leaking resources or draining battery.
A GOOD ANSWER COVERS: First, subclass CoroutineWorker or Worker and override doWork to perform the upload on a background thread. Second, build a Constraints object using Constraints.Builder and call setRequiredNetworkType(NetworkType.UNMETERED) and setRequiresCharging(true). Third, construct a OneTimeWorkRequest, attach the constraints, set input data with setInputData for the photo URI, and configure retry behavior with setBackoffCriteria using BackoffPolicy.EXPONENTIAL and a delay of at least ten seconds. Fourth, enqueue the request with WorkManager.getInstance and optionally tag it for observation or cancellation. Fifth, mention that WorkManager handles process death automatically and respects Doze and App Standby buckets without additional code.
COMMON WRONG ANSWERS: Suggesting a ForegroundService is a red flag because the task is deferrable and does not need to run immediately while the app is visible. Using AlarmManager or a raw JobScheduler also signals a gap in modern architecture knowledge because WorkManager is the recommended abstraction for deferrable guaranteed work. Another red flag is forgetting to set the network constraint or using NetworkType.CONNECTED instead of UNMETERED, which would burn user data. Failing to mention retry or claiming Android will auto-retry without an explicit BackoffPolicy is also incorrect. Claiming the work runs in real time is wrong because WorkManager is for deferrable execution.
LIKELY FOLLOW-UPS: How would you observe the work status from the UI using LiveData or Flow? How would you handle a requirement to retry only three times? What is the difference between Worker and CoroutineWorker? How does WorkManager behave on devices running API 23 versus API 26 and above? Can you expedite this work, and what are the restrictions on expedited work in recent Android versions?
ONE CONCRETE EXAMPLE: Imagine a user selects a photo in a social app. You create an UploadWorker class extending CoroutineWorker. Inside doWork you read the URI from inputData, open an OkHttp request body, and stream the bytes. You return Result.success if the server responds with HTTP 200, or Result.retry if it returns a 5xx error. You build constraints requiring UNMETERED and charging. You set backoff to EXPONENTIAL with ten seconds. You enqueue the work. Even if the user force-stops the app, WorkManager reschedules the upload when constraints are met.
Source: developer.android.com
Read the original → developer.android.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.