NetworkOnMainThreadException: WorkManager retry timing for low-traffic network requests

Direct Answers

1. Immediate retry on network return. For a OneTimeWorkRequest with a CONNECTED constraint, WorkManager does not wait for a periodic window. When the constraint is satisfied again, the work is dispatched as soon as system resources allow.
2. Back-off only applies after Result.retry(). The default exponential back-off (30 s, 60 s, 120 s …) is triggered only when your Worker explicitly returns Result.retry(). A missing network constraint merely holds the work in ENQUEUED/BLOCKED state; it does not increment the retry counter.
3. WorkInfo cannot distinguish constraint deferral from back-off delay. Both appear as ENQUEUED or BLOCKED with the same runAttemptCount. You must correlate timestamps or log constraint changes yourself.

Confirmed Behavior (API 24+ / JobScheduler)

• WorkManager always runs your doWork() on a background executor, so NetworkOnMainThreadException never occurs inside a Worker.
• Unmet CONNECTED constraint → work stays ENQUEUED/BLOCKED; no retry counter increment.
• Constraint satisfied → work moves to RUNNING at the next scheduler tick (typically seconds, not minutes).
• Result.retry() → exponential back-off timer starts; next attempt fires when both timer expires and CONNECTED is true.

API 21–23 Differences (GCMNetworkManager)

On these versions WorkManager delegates to Google Play Services’ GCMNetworkManager. The same logical rules apply, but wake-up granularity is coarser (often ~1–2 min) and Doze mode interactions are less predictable. Treat timing as “best effort within a few minutes” rather than “seconds.”

Practical Verification Steps

1. Create a Worker that logs System.currentTimeMillis() at start and returns Result.retry() on a simulated failure.
2. Enqueue a OneTimeWorkRequest with setRequiredNetworkType(CONNECTED).
3. Disable network (airplane mode) → observe WorkInfo state BLOCKED, runAttemptCount unchanged.
4. Re-enable network → note timestamp delta until RUNNING appears.
5. Force Result.retry() → verify next run occurs after ~30 s and network present.

One Missing Diagnostic Detail

Are you using PeriodicWorkRequest or OneTimeWorkRequest? Periodic work does respect its interval window even after a constraint delay, which changes the battery-cost model entirely.