WorkManager periodic task execution drifts beyond expected constraint windows

Likely explanation

The observed timing drift is primarily caused by Android’s battery‑optimization mechanisms that group background work into maintenance windows. On API 23+ the Doze mode can defer work until the next maintenance window, and OEM‑specific power‑save layers (e.g., MIUI, OneUI, EMUI) add further delay. When the battery level falls below roughly 30 % the system may also postpone RequiresCharging work until the charge rises, extending the window.

Confirmed facts

• Doze and app standby are active on API 23+ and cause the system to batch jobs.
• OEM power‑save policies can impose additional background execution limits beyond the AOSP behavior.
• Battery level below the charging‑required threshold triggers a deferral until the device reaches a higher charge.
• setInitialDelay only shifts the first execution; it does not affect the jitter of the repeat interval.
• A custom BackoffPolicy applies only to retry attempts after a failure and does not constrain the scheduler’s choice of when to run a successful periodic work.

Steps to verify and tighten the window

1. Measure the actual start times: tag your PeriodicWorkRequest, log System.currentTimeMillis() in Worker.doWork(), and collect data over several nights.
2. Use adb shell dumpsys jobScheduler or adb shell cmd jobscheduler list to inspect the flex window that the system has granted for the job.
3. Compare the measured variance across devices with different OEM power‑save settings (e.g., with battery optimization disabled for the app). A significant reduction when optimization is turned off confirms the OS/OEM impact.
4. If the observed delay exceeds the flex window you can tighten it by reducing the flex interval when building the request:

   PeriodicWorkRequest request = new PeriodicWorkRequest.Builder(MyWorker.class, 15, TimeUnit.MINUTES)
           .setFlex(5, TimeUnit.MINUTES)   // allows execution within [10,15] minute window
           .setConstraints(new Constraints.Builder()
                   .setRequiredNetworkType(NetworkType.UNMETERED)
                   .setRequiresCharging(true)
                   .build())
           .build();
   

   Note: the flex must be ≥ 15 minutes when the repeat interval is the minimum 15 minutes; otherwise you must increase the repeat interval (e.g., to 30 minutes) and set a smaller flex to keep the window narrow.
5. setInitialDelay can be used to align the first run with the start of your overnight charging period, but it will not reduce jitter for subsequent runs.
6. A custom BackoffPolicy does not help with periodic scheduling; it only controls retry timing after a failure.

Detecting missed deadlines

WorkManager does not provide a direct callback for “work deferred past a deadline,” but you can implement a detection pattern:

1. When you enqueue the PeriodicWorkRequest, record the expected latest run time (e.g., System.currentTimeMillis() + interval + flex) in SharedPreferences or a Room table.
2. In your Worker, after successful completion, update the stored timestamp to the actual run time.
3. Periodically (e.g., via a short‑lived AlarmManager or another WorkRequest with a short interval) check the stored timestamp. If the elapsed time since the last successful run exceeds your acceptable threshold, surface a user‑visible warning (e.g., a notification or in‑app banner).
4. Optionally, observe WorkManager.getWorkInfoByIdLiveData() for the periodic work; if the state remains ENQUEUED or BLOCKED past the expected window, treat it as a deferral.

Missing diagnostic detail

To decide whether adjusting the flex interval is sufficient, please provide the measured average delay (in minutes) you are seeing across devices. If the delay is consistently within the flex window, tightening the flex will help; if it exceeds the flex window, you may need to consider alternative strategies such as using a foreground service with a timeout or alarm‑based fallback.