Understanding and Analyzing Android ANR (Application Not Responding) Issues

ANR Issues in Android Development

ANR (Application Not Responding) problems occur with low probability but are hard to reproduce, severely affecting user experience. This article explains the principles, analysis methods, and case studies of ANR to help developers understand and handle them.

Goals

After reading this case, you will master:

1. The concept of ANR

2. The four types of ANR and their underlying mechanisms

3. Analysis approaches for ANR problems

4. How to avoid ANR in development

Concepts and Principles

1. ANR Concept

ANR stands for Application Not Response. When the UI thread is blocked for too long, the system shows a dialog asking whether to wait or close the app.

1.1 Causes of ANR

Typical causes include:

Frequent time‑consuming I/O on the main thread (file read/write, network access)

Deadlocks caused by multithreading

Binder communication timeout

WatchDog service failures

System resource exhaustion (CPU, I/O)

1.2 Types of ANR

The four main categories are:

KeyDispatchTimeout : Input event not processed within 5 seconds.

BroadcastTimeout : Broadcast handling exceeds 10 seconds (foreground) or 60 seconds (background).

ServiceTimeout : Service processing exceeds 20 seconds (foreground) or 200 seconds (background).

ContentProviderTimeout : ContentProvider does not finish within 10 seconds.

ANR Trigger Mechanism

The Android system monitors app responsiveness through a three‑step countdown:

The AMS starts a timeout when the app begins an operation.

If the operation finishes before the timeout, the countdown is cancelled.

If the countdown expires, the system shows the ANR dialog.

2.1 ServiceTimeout ANR

Sequence:

App process requests a service via Binder.

System process notifies AMS to start the timeout.

System forwards the request to the target service.

Service processes the request.

Service completes and notifies the system.

AMS cancels the timeout.

If steps 2‑7 exceed the timeout, an ANR occurs. Front‑end services timeout at 20 s, background services at 200 s.

2.2 BroadcastQueueTimeout ANR

Process:

Broadcast is sent to AMS.

AMS queues the broadcast and starts timeout detection.

Broadcast is delivered to the target app via Binder.

App places the broadcast in its message queue.

App processes the broadcast.

After processing, the app notifies AMS.

If the timeout is reached, an ANR dialog appears.

2.3 ContentProviderTimeout ANR

Occurs when a ContentProvider is started for the first time and exceeds the 10 second limit.

2.4 InputDispatchingTimeout ANR

InputReader reads events, InputDispatcher distributes them. If processing exceeds the timeout, an ANR is triggered.

ANR Analysis Workflow

Typical steps:

Identify the process and ANR type from the system dialog.

Examine system logs to locate the phase where the ANR occurred.

Check system load (CPU, memory, I/O) to see if the issue is resource‑related.

Inspect the stack trace to find blocking operations or long‑running tasks on the main thread.

Common cases:

Case 1: Main thread performing time‑consuming work – Look for “RUNNABLE” or “NATIVE” states in the trace.

Case 2: Main thread blocked – Search for locked objects and identify which thread holds the lock.

Trace File Interpretation

The trace file provides detailed thread information such as thread name, priority, tid, state, CPU usage, stack address, and lock type. Understanding these fields helps pinpoint the root cause of ANR.

Conclusion and Best Practices

To reduce ANR occurrences, follow these guidelines:

Avoid heavy I/O, database, or network operations on the main thread.

Keep broadcast receivers lightweight; offload heavy work to background threads.

Do not perform complex tasks in Activity/Service lifecycle methods.

Control loop boundaries to prevent infinite loops.

Design proper synchronization to avoid deadlocks.

Understanding ANR principles and analysis methods not only helps solve current issues but also improves overall coding quality.