NetworkOnMainThreadException: Move Blocking Work Off the UI Thread

Identify the blocking call

Use the crash trace to locate the actual network operation, not only the button handler that called it. A library method with a synchronous API can block even when its name sounds harmless.

Look for connection establishment, response reading and parsing that follows the request.

Move the complete blocking segment

Use an appropriate asynchronous API or coroutine/thread execution model. Keep UI updates on the UI thread, but do not immediately call a blocking wait to retrieve the worker result.

The background-work guidance helps distinguish short in-process work from persistent work that must survive app exit. Not every network request belongs in a persistent worker.

Design cancellation and errors

Avoid unbounded retries and duplicate requests after rotation or recomposition.

Keep expensive decoding off the critical path

An asynchronous HTTP call can still cause jank if the callback parses a huge payload or decodes images on the main thread. Measure the whole operation, not just socket activity.

Verify responsiveness under failure

Test slow and unavailable networks while interacting with the UI. Confirm loading indicators, cancellation and retry behavior rather than only checking that a fast request succeeds.

APKLint's code and performance checkers can help flag suspicious patterns, but they do not execute the app's threading model. Keep a trace or reproducible test demonstrating that the UI no longer blocks during the complete network-and-processing flow.