Understanding Android ANR: Causes, Trigger Process, Monitoring Techniques, and Analysis

ANR (Application Not Responding) is a watchdog mechanism in Android that monitors component interactions and user input for timeouts, detecting when an app's main thread is blocked or unresponsive.

The article outlines common ANR causes, separating them into application‑level issues (function blocking, lock contention, memory pressure) and system‑level issues (CPU preemption, unresponsive system services, other apps consuming resources).

It describes how to retrieve ANR logs offline using adb pull /data/anr/ and adb bugreport , noting limitations such as missing stack traces.

Various ANR scenarios are detailed, including Service, Broadcast, Provider, and Input timeouts, each with specific timeout values (e.g., Service timeout 20 s, Input dispatching timeout 5 s). The internal trigger flow is explained as a three‑step process: planting a timed bomb, removing it when the operation finishes, and detonating it if the timeout expires.

Key source code snippets illustrate how the system schedules timeouts, sends SERVICE_TIMEOUT_MSG , and ultimately calls appNotResponding to generate the ANR dialog or kill the process.

Two main monitoring approaches are presented:

WatchDog : a background thread posts a runnable to the main thread and checks if it is executed within a timeout, optionally querying ActivityManager.getProcessesInErrorState() for the NOT_RESPONDING flag.

SIGQUIT signal monitoring : by unblocking SIGQUIT, installing a sigaction handler, and forwarding the signal to the original SignalCatcher thread, developers can detect when the system is about to dump stack traces.

To avoid false positives, the article recommends checking the NOT_RESPONDING flag via ActivityManager.ProcessErrorStateInfo and verifying main‑thread staleness by inspecting the MessageQueue ’s current message timestamp.

For complete ANR trace capture, it suggests hooking the native write call (via PLT hooking) that writes to the trace socket, allowing the app to obtain the full stack dump without interfering with the system’s behavior.

Analysis of ANR trace files is demonstrated, explaining how to read thread information, stack states, mutex holdings, and CPU statistics to pinpoint root causes such as long‑running tasks, deadlocks, CPU starvation, memory pressure, or slow system service calls.

The article also discusses limitations of trace‑only analysis and introduces an internal tool called Raster, which records main‑thread message scheduling, aggregates long‑running messages, and uses thread check‑time mechanisms to provide a holistic view of ANR origins.

Finally, it provides a list of references and further reading for deepening understanding of ANR mechanisms and mitigation techniques.