Mobile Development 26 min read

Understanding and Analyzing Android ANR (Application Not Responding)

Android ANR occurs when the UI thread is blocked, triggered by time‑outs such as KeyDispatch, Broadcast, Service or ContentProvider, often caused by long I/O, deadlocks, Binder calls or resource exhaustion; diagnosing involves examining traces.txt, thread states, CPU/memory metrics, and using tools like Looper logs, Choreographer, or Tencent Matrix to prevent future freezes.

37 Interactive Technology Team
37 Interactive Technology Team
37 Interactive Technology Team
Understanding and Analyzing Android ANR (Application Not Responding)

ANR (Application Not Responding) occurs when the UI thread is blocked for too long, causing the system to show a dialog (foreground ANR) or kill the process (background ANR).

Typical ANR types include:

KeyDispatchTimeout – input event not processed within 5 seconds.

BroadcastTimeout – onReceive not finished within 10 seconds (foreground) or 60 seconds (background).

ServiceTimeout – Service lifecycle methods not finished within 20 seconds (foreground) or 200 seconds (background).

ContentProviderTimeout – ContentProvider not finished within 10 seconds.

Common causes of ANR:

Frequent long‑running I/O on the main thread (e.g., database read/write).

Deadlocks in multithreaded code that block the UI thread.

Main thread blocked by a remote Binder call.

System Server WatchDog timeout.

Exhausted system resources (pipes, CPU, I/O).

ANR analysis workflow :

Identify the ANR timestamp and the affected package.

Obtain the /data/anr/traces.txt file (or use adb bugreport ) and locate the relevant process section.

Examine the thread stack traces; focus on the main thread state (BLOCKED, WAITING, TIMED_WAITING, etc.).

Collect additional information such as CPU usage, top‑CPU processes, and native processes (system_server, audio, camera, etc.).

Analyze CPU load ( Load 2.62 / 2.55 / 2.25 ) and memory statistics (allocations, free memory, OOM thresholds).

Example command to retrieve the ANR log:

adb bugreport /Users/xxx/anrlog/anr.zip

Key fields in a thread stack entry:

main – main UI thread.

prio – thread priority (default 5).

tid – unique thread identifier.

group – thread group name.

sCount – times the thread was suspended.

dsCount – times the thread was suspended by a debugger.

state – Java thread state (NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED).

Mapping between Java and native (C++) thread states:

Java State

C++ State

Description

TERMINATED

ZOMBIE

Thread has finished execution.

RUNNABLE

RUNNING / RUNNABLE

Thread is ready or running.

TIMED_WAITING

TIMED_WAIT

Waiting with timeout (sleep, wait, join).

BLOCKED

MONITOR

Waiting to acquire a monitor lock.

WAITING

WAIT

Waiting without timeout.

NEW

INITIALIZING / STARTING

Thread is being created.

If the main thread appears idle (e.g., waiting on MessageQueue.next ), consider:

CPU contention from other high‑priority processes.

Memory pressure indicated by am_meminfo or onTrimMemory logs.

Memory diagnostics example:

04-02 22:00:08.195 1531 1544 I am_meminfo: [350937088,41086976,492830720,427937792,291887104]

Detection tools:

Looper log monitoring – replace the main Looper’s Printer to measure dispatchMessage execution time.

public static void loop() { for (;;) { /* ... */ msg.target.dispatchMessage(msg); /* ... */ } }
public class LogMonitor implements Printer { /* ... */ }

Choreographer callbacks – measure frame intervals; a gap > 16.6 ms indicates a dropped frame.

public static void start() { Choreographer.getInstance().postFrameCallback(frameTimeNanos -> { /* compute diff */ }); }

Tencent Matrix – provides LooperAnrTracer and SignalAnrTracer for ANR detection.

Case studies:

Firebase deadlock: main thread blocked on lock 0x0891a599 held by thread 25, which simultaneously waited for another lock, causing a classic deadlock. Fixed in Firebase messaging 23.1.1.

Custom SDK lock contention: main thread waited on lock 0x0c2c5bc1 held by “RiverSDK #4”, leading to ANR during repeated ad requests.

Large Binder replies (> 300 KB) generated “Unreasonably large binder reply buffer” errors, potentially causing ANR.

Binder transaction failures (error ‑3, ‑22) indicating communication problems between processes.

Memory pressure: high onTrimMemory level (80) and low free memory values trigger process termination.

Summary : Effective ANR troubleshooting requires extracting and parsing traces.txt , correlating thread states with CPU/memory metrics, and employing runtime monitoring tools (Looper log, Choreographer, Matrix) to detect and prevent future occurrences.

debuggingPerformanceAndroidANRcpumemorytracing
37 Interactive Technology Team
Written by

37 Interactive Technology Team

37 Interactive Technology Center

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.