NetworkOnMainThreadException penalty delivery under heavy system load

Direct answer

No. StrictMode does not guarantee that the configured penalty is delivered under heavy system load. The NetworkOnMainThreadException itself is thrown synchronously before the blocking socket call, but penalties such as penaltyLog, penaltyDropBox, penaltyDialog, and penaltyFlash are best-effort side effects. Under load, the exception still propagates to the caller, but the penalty may be delayed, truncated, or never rendered.

Confirmed facts vs. likely explanations

Confirmed by platform behavior: the main-thread network check lives in StrictMode$AndroidBlockGuardPolicy.onNetwork() and executes before the syscall. If that check fires, the exception is raised immediately; system load does not suppress it.

Likely or uncertain: penalty visibility. Logcat buffers can wrap, DropBox entries can be throttled, and a dialog or screen flash may not appear if the process is already ANR-bound or crashes first. These are delivery mechanisms, not transactional guarantees.

HttpURLConnection vs. OkHttp timing

There is no measurable timing difference on the same device and API level. Both libraries ultimately call the same platform socket APIs. OkHttp’s dispatcher does not bypass the main-thread guard unless the call is explicitly offloaded to a worker thread. Both throw on the first blocking network syscall executed on the main thread.

Missing penalty interpretation

A missing penalty must not be read as evidence that main-thread networking succeeded. The exception may have terminated the process before the dialog appeared, the log buffer may have rotated, or DropBox may have discarded the entry. Absence of a penalty is not proof of absence of a violation.

Verification steps (API 24+)

1. Enable a policy before the violating call: StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder().detectNetwork().penaltyLog().penaltyDeath().build()).
2. Trigger a main-thread request via HttpURLConnection or OkHttpClient.newCall(...).execute().
3. Capture adb logcat and confirm the stack trace contains android.os.NetworkOnMainThreadException with a frame in StrictMode$AndroidBlockGuardPolicy.onNetwork().
4. Repeat under synthetic load and on at least two API levels (e.g., 24 and 33) to rule out OEM-specific penalty suppression.

One diagnostic detail that changes the advice

Does the suspected network path go through native code (JNI)? If so, the Java-level BlockGuardPolicy check may not apply, and neither the exception nor the penalty should be expected.