OneTimeWorkRequest vs PeriodicWorkRequest and minimum repeat interval

WHAT THIS TESTS: This question tests whether you understand the architectural split between one-shot and repeating background work in WorkManager, the API constraints that enforce battery-friendly behavior, and the platform philosophy behind minimum intervals. Interviewers want to see that you know when to use each request type and that you can explain why Android imposes hard limits rather than leaving scheduling entirely to the app.

A GOOD ANSWER COVERS: OneTimeWorkRequest represents a single unit of work that runs exactly once. It supports input and output Data objects, exponential and linear backoff retry policies, and can be composed into chains and graphs of dependent work where the output of one worker feeds into the next. PeriodicWorkRequest represents work that repeats on a fixed cycle. Because the repeating nature means there is no single terminal completion point that can trigger downstream work, PeriodicWorkRequest cannot be chained or used as a prerequisite for other requests. The minimum repeat interval for PeriodicWorkRequest is 15 minutes. The API enforces this floor and will raise or clamp any shorter duration to 15 minutes. The reason for the limit is battery preservation and system-wide batching. Android uses Doze mode and App Standby to defer background activity until maintenance windows. A 15-minute floor allows the OS to align work from many apps into shared wakeups, reducing radio and CPU usage rather than honoring exact per-app alarm-style timing.

COMMON WRONG ANSWERS: A common wrong answer is stating that PeriodicWorkRequest supports chaining or dependent work. Another red flag is claiming the minimum interval is one minute, five minutes, or that there is no enforced floor. Candidates who describe WorkManager as suitable for exact real-time scheduling or who confuse it with AlarmManager for precise repeating alarms also miss the point. Saying the limit exists only to restrict developers rather than to preserve battery is a signal of shallow platform understanding.

LIKELY FOLLOW-UPS: An interviewer might ask how flex intervals affect periodic work execution windows, how to enforce unique work policies with existing periodic requests, or when to prefer AlarmManager plus a broadcast receiver instead. They may also ask about expedited work and how it interacts with periodic constraints, or how to test WorkManager behavior with a custom test driver and mock clock.

ONE CONCRETE EXAMPLE: If you need to sync user notes to a backend every hour, you would use PeriodicWorkRequest with a one-hour repeat interval. The system schedules this within a flexible window and guarantees it runs at most once per interval, but it may defer execution to batch with other apps during a maintenance window. If you need to upload a single photo with post-processing and then send a notification, you would use a OneTimeWorkRequest chain: an upload worker, then a filter worker, then a notification worker. The chain completes once and releases resources.

Source: developer.android.com