What is the difference between ANR and crash in Android?
Categories:
ANR vs. Crash: Understanding Android Application Failures

Explore the fundamental differences between Application Not Responding (ANR) errors and application crashes in Android development, and learn how to diagnose and prevent them for a robust user experience.
In the world of Android application development, two of the most critical issues developers face are Application Not Responding (ANR) errors and application crashes. While both lead to a negative user experience and indicate a problem within your app, their underlying causes, symptoms, and diagnostic approaches are distinctly different. Understanding these differences is crucial for effective debugging, performance optimization, and ultimately, delivering a stable and reliable application.
What is an Android Crash?
An Android application crash occurs when an unexpected runtime error causes the app to terminate abruptly. This usually happens due to an unhandled exception in the application's code. When a crash occurs, the Android system immediately stops the app's process, and the user is typically returned to their device's home screen or the previous app. Crashes are often accompanied by a 'Unfortunately, [App Name] has stopped' dialog.
flowchart TD A[User Interaction] --> B{Unhandled Exception Occurs} B --> C[Android System Detects Exception] C --> D[App Process Terminated] D --> E[User Sees 'App Has Stopped' Dialog] E --> F[App Exits Abruptly]
Flowchart of an Android Application Crash
Common Causes of Crashes
Crashes can stem from various programming errors. Some of the most frequent causes include:
- NullPointerException: Attempting to access a member of an object that is
null
. - ArrayIndexOutOfBoundsException: Accessing an array with an invalid index.
- OutOfMemoryError: The app tries to allocate more memory than is available.
- IllegalStateException: An object is in an inappropriate state for the requested operation.
- NetworkOnMainThreadException: Performing network operations on the main (UI) thread, which is strictly forbidden on newer Android versions.
public class CrashExample {
public void causeNullPointerException() {
String data = null;
System.out.println(data.length()); // This line will cause a NullPointerException
}
public void causeArrayIndexOutOfBoundsException() {
int[] numbers = {1, 2, 3};
System.out.println(numbers[5]); // This line will cause an ArrayIndexOutOfBoundsException
}
}
Examples of code that can lead to common Android crashes.
What is an Application Not Responding (ANR) Error?
An ANR occurs when an application's UI thread (also known as the main thread) is blocked for too long, typically more than 5 seconds for an activity or 10 seconds for a broadcast receiver. When the UI thread is blocked, the application cannot respond to user input, draw its UI, or process other events, leading to a frozen or unresponsive state. The Android system detects this unresponsiveness and displays an 'Application Not Responding' dialog, giving the user the option to wait or close the app.
sequenceDiagram participant User participant AppUIThread as "App UI Thread" participant AppWorkerThread as "App Worker Thread" participant AndroidSystem as "Android System" User->>AppUIThread: Taps button AppUIThread->>AppUIThread: Performs long-running task (e.g., 6 seconds) AndroidSystem->>AppUIThread: Checks responsiveness (after 5s) AppUIThread-->>AndroidSystem: No response AndroidSystem->>User: Displays ANR dialog User->>AndroidSystem: Chooses 'Wait' or 'Close app'
Sequence diagram illustrating an ANR event.
Common Causes of ANRs
ANRs are primarily caused by blocking the main thread. Common scenarios include:
- Performing long-running operations on the main thread: This includes network requests, database queries, complex calculations, or large file I/O operations.
- Deadlocks: Two or more threads are blocked indefinitely, waiting for each other.
- Slow or blocked Binder calls: Inter-process communication (IPC) calls that take too long.
- Excessive CPU usage: The main thread is starved of CPU time due to other processes or heavy background tasks.
- Heavy UI rendering: Complex layouts or animations that take too long to draw.
public class ANRExample extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
findViewById(R.id.my_button).setOnClickListener(v -> {
// This will cause an ANR if the network call takes more than 5 seconds
try {
// Simulate a long-running network operation on the main thread
Thread.sleep(6000);
Log.d("ANR_TEST", "Network call finished");
} catch (InterruptedException e) {
e.printStackTrace();
}
});
}
}
Example of code that will cause an ANR by blocking the main thread.
Key Differences and Diagnostic Approaches
The table below summarizes the main distinctions between ANRs and crashes, along with their typical diagnostic tools.

Comparison of ANR vs. Crash
For crashes, the primary tool is the stack trace provided in Logcat or crash reporting services like Firebase Crashlytics. For ANRs, you'll need to analyze traces.txt
files (found in /data/anr/
on the device) which contain stack traces of all threads when the ANR occurred, or use profiling tools like Android Studio's CPU Profiler to identify long-running tasks on the main thread.
AsyncTask
for older projects) to prevent ANRs. Use StrictMode
in development to catch potential ANR-causing operations early.