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
| Event | Required behavior |
|---|---|
| User leaves screen | Cancel or detach obsolete UI work |
| Timeout | End loading state and expose retry appropriately |
| No network | Return a meaningful recoverable result |
| Process ends | Persist/retry only if the task's contract requires it |
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.
Move the complete blocking operation off the UI thread
Consider a search button whose handler opens a connection, reads the response body and parses a large document. Moving only connection creation to a background executor leaves the later blocking read on the UI thread. Trace the complete synchronous operation, including body consumption and expensive decoding, then choose a supported asynchronous client or an appropriate background execution context for that work.
The platform reference describes the exception's networking boundary. Disabling the thread-policy check does not make a slow server respond faster or keep input events flowing. Likewise, immediately waiting for a background future from the click handler can recreate the original freeze without the same exception message.
Prevent an old response replacing a newer search
Use an illustrative sequence with two queries: the user searches for apple, then orange before the first response arrives. Introduce a controlled delay so apple finishes last. The screen must associate each result with the request that produced it and render only the currently relevant result. Cancellation is useful, but do not assume a cancelled network operation can never complete a callback.
Keep loading and error state tied to that same request identity. When orange fails, an old successful apple result must not be presented as orange's answer. Use explicit connection and read timeout behavior supported by the chosen client, and make retry controls restore a usable screen. Avoid unbounded automatic retry loops on poor connections.
Navigate away while a request is running, then recreate the screen and check that a destroyed view receives no update. Decide whether this short user-visible request should be cancelled or retained in an appropriate state holder. Work that must finish reliably after the user leaves requires its own durable background-work design; spawning an unmanaged thread does not provide that guarantee. Test success, an unreachable endpoint, a slow body and a malformed response separately. Observe input responsiveness during each case and confirm that UI rendering returns to the main thread where required. These observations establish both responsiveness and correct ownership of results rather than merely proving that the exception no longer appears.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
