NetworkOnMainThreadException: WorkManager retry timing for low-traffic network requests
0 reputation · 02 Feb 2022, 10:13 UTC
Goal
Confirm whether WorkManager retries a constrained OneTimeWorkRequest immediately after a brief network interruption or defers the attempt until the next scheduled trigger, so low-traffic workloads can estimate wake-up and battery costs accurately.
Constraints
NetworkOnMainThreadException is documented on API level 11 and above when network code runs on the UI thread. WorkManager moves the request off the main thread and accepts constraints such as CONNECTED, but the default retry policy for transient connectivity loss is not fully specified for infrequent jobs. Behavior may vary by API level, and WorkInfo reports status and retry count without exposing the underlying back-off schedule.
Specific questions:
- Does WorkManager retry immediately when the network becomes available again, or does it wait for the next periodic execution window?
- How does the default back-off interval interact with the CONNECTED constraint across API 21 and API 33?
- Can WorkInfo distinguish a connectivity deferral from a hard failure without relying on retry count alone?