Debug Android ANRs: Start with the Blocked Main Thread

Identify the ANR category

The ANR guide describes different causes and timing contexts. Do not apply one universal timeout number to every input, service or broadcast situation.

Capture the reported reason, process, affected version and thread traces. A stack showing an idle main thread can be a late snapshot rather than proof that no blockage occurred.

Follow the dependency chain

Inspect other threads as well as the main stack. Moving work to a background thread does not help if the UI immediately blocks waiting for its result.

Correlate surrounding events

Use Logcat and available system traces to align the ANR with user actions, lifecycle events, SDK initialization and resource pressure.

Avoid discarding timestamps or process information when redacting logs. Remove credentials and personal data while preserving the timing needed for diagnosis.

Fix ownership and scheduling

Make blocking work asynchronous with lifecycle-aware completion. Reduce lock scope, avoid calling unknown external code while holding a lock, and keep broadcast/service work within the appropriate execution model.

Do not hide the symptom by adding a longer application timeout when the system's responsiveness requirement still applies.

Verify under stress

Test slow storage/network, repeated navigation and representative lower-end devices. APKLint's Crash / ANR Analyzer can help interpret redacted traces, but it cannot reconstruct every scheduling event from one stack snapshot. Confirm the fix with a reproducible scenario and watch the affected release cohort after rollout.