Diagnosing and Fixing Android ANR (App Not Responding) Errors

Why Android Shows an ANR Dialog

When an app blocks the main (UI) thread for more than a few seconds, the system assumes it has become unresponsive. Android then displays the classic “App isn’t responding” (ANR) dialog offering to Wait or Close app. The dialog appears for three main reasons:

• Long‑running work on the UI thread – heavy computation, file I/O, or network calls performed directly in the foreground.
• Deadlock or synchronization issue – two threads waiting on each other, freezing the UI.
• System resource starvation – low memory, full storage, or aggressive battery‑optimization throttling.

Understanding which of these triggers the ANR on your device is the first step toward a permanent fix.

Before You Start

• Charge your device to at least 50 %.
• Enable Developer options → USB debugging (Settings > About phone > Tap Build number 7 times, then Settings > System > Developer options).
• Connect the phone to a PC via USB and verify the connection with adb devices.
• Make sure you have a stable Wi‑Fi or mobile data connection if the app relies on the network.

Step 1 – Reproduce the ANR and Capture the Log

1. Trigger the ANR: Open the problematic app and perform the action that usually leads to the dialog. Note the exact screen and any input you gave.
2. Open a terminal on your PC and run:

   adb logcat -b main -v threadtime *:W > anr_log.txt

   This command records warnings and errors from the main buffer to anr_log.txt. Keep the terminal open while you reproduce the ANR.
3. When the ANR appears, immediately tap Wait (or Close if you prefer). The system will write an ANR entry to the log.

   If you close the app, the log may end before the ANR stack is fully written. Waiting for a few seconds gives the system time to dump the trace.

4. Stop logging by pressing Ctrl+C in the terminal.
5. Locate the ANR trace inside anr_log.txt. Search for the string ANR in or ActivityManager. You will see a block similar to:

   04-12 14:23:45.678  1234  5678 I ActivityManager: ANR in com.example.app (com.example.app/.MainActivity)
   04-12 14:23:45.679  1234  5678 W ActivityManager: pid=12345
   04-12 14:23:45.680  1234  5678 I ActivityManager:  "main" prio=5 tid=1 Runnable
       ...
       at android.os.Handler.handleCallback(Handler.java:789)
       at android.os.Handler.dispatchMessage(Handler.java:102)
       at android.os.Looper.loop(Looper.java:158)
       at android.app.ActivityThread.main(ActivityThread.java:6656)
       ...
   

Step 2 – Decode the ANR Trace

The trace contains three crucial pieces of information:

1. Package name – e.g., com.example.app. Confirms which app is at fault.
2. Thread name – usually main for UI‑thread blocks.
3. Stack frames – the call stack at the moment the system detected the freeze.

Look for the first method that belongs to the app’s own package (not Android framework). That method is the likely culprit.

Step 3 – Quick User‑Level Fixes

If you are not the developer, you can still resolve many ANR occurrences with the following steps. Perform them in order; stop when the problem disappears.

1. Clear app cache and data:
   • Settings > Apps > [App] > Storage > Clear cache.
   • If the issue persists, choose Clear storage/data. This removes login info and settings, so back up anything important first.
2. Update the app via Google Play. Developers often fix ANR‑causing bugs in newer releases.
3. Reinstall the app:
   • Uninstall from Settings > Apps > [App] > Uninstall.
   • Re‑install from Play Store or a trusted APK source.
4. Check storage space. Low internal storage can cause the system to pause background I/O, leading to ANRs. Free at least 10 % of total space.
5. Disable battery optimizations for the app:
   • Settings > Battery > Battery optimization > All apps > [App] > Don’t optimize.
6. Force stop background apps that might be competing for RAM. Recent Android versions limit this, but on older devices it can still help.
7. Boot into Safe Mode to see if a third‑party module (e.g., a launcher or overlay) is causing the freeze:
   • Press and hold the power button, then tap and hold Power off until the Safe Mode prompt appears.
   • Test the app in Safe Mode. If the ANR disappears, a third‑party component is the likely cause.
8. Factory reset as a last resort. Back up all data first; this wipes the device completely.

Step 4 – Developer‑Level Debugging (If You Have Access to Source)

When you are the app developer or have the source code, use the captured stack trace to pinpoint the blocking call.

1. Identify the offending method from the ANR stack (see Step 2). Note the line number if the stack includes it.
2. Move heavy work off the UI thread:
   • Use AsyncTask (deprecated) or, preferably, Executor/HandlerThread for simple background jobs.
   • For network or database operations, adopt WorkManager or Coroutine (Kotlin) to guarantee asynchronous execution.
3. Avoid synchronous wait() or join() on the UI thread. If you must wait for a result, consider a Future with a timeout and update the UI in a callback.
4. Detect and break deadlocks:
   • Review any synchronized blocks that lock multiple objects. Ensure a consistent lock ordering.
   • Use ReentrantLock with tryLock() to avoid indefinite waiting.
5. Profile the app with Android Studio’s CPU Profiler:
   • Run the app on a device, click the Record button, reproduce the ANR, then stop recording.
   • Look for methods that take > 200 ms on the main thread.
6. Test on low‑memory devices using the adb shell am kill‑all command to simulate memory pressure.
7. Publish an updated APK with the fixes and encourage users to update.

Step 5 – Verifying the Fix

After applying a user‑level or developer fix, repeat the logging process (Step 1) to confirm the ANR entry no longer appears.

1. Start adb logcat again.
2. Reproduce the same action that previously caused the freeze.
3. If no ANR line shows up, the issue is resolved.
4. If the ANR persists, compare the new stack trace with the old one. Look for a different method or a repeated pattern.

Common Pitfalls & How to Recover

• Logcat buffer overflow: Android’s log buffers are limited. If you see truncated traces, add the -G 16M flag to increase buffer size before logging:

  adb logcat -G 16M

• Missing USB debugging permission: Some devices ask for confirmation each time you connect. Accept the RSA key prompt, or add the computer’s key to ~/.android/adbkey.pub on the device.
• ANR caused by system services: Occasionally the fault lies in a buggy system app (e.g., a custom OEM launcher). In that case, the only reliable fix is a system update or switching to a different launcher.
• Third‑party overlay apps (e.g., screen dimmers, floating widgets) can inject UI work that blocks the main thread. Disable or uninstall them if ANRs start after installing such tools.

Edge Cases & Advanced Options

Using “adb bugreport” for a Complete Snapshot

If the simple logcat does not reveal the problem, capture a full bug report:

adb bugreport bugreport.zip

The resulting ZIP contains a system_log and a trace_process file. Open trace_process and search for ANR to see a more detailed thread dump, including background threads that might be holding a lock.

Enabling “StrictMode” on a non‑rooted device

Developers can temporarily enable StrictMode via adb shell setprop to force the system to throw an exception when the UI thread does disk or network I/O:

adb shell setprop debug.strictmode 1

After reproducing the ANR, the log will contain a StrictModeViolation entry pinpointing the exact call.

Detecting ANRs Caused by Broadcast Receivers

If the stack trace starts with android.app.ActivityThread.handleReceiver, a broadcast receiver is executing too long. The fix is to move the work to an IntentService or JobIntentService.

Summary Checklist

• Enable USB debugging and connect to ADB.
• Reproduce the ANR while logging with adb logcat.
• Locate the ANR block and identify the first app‑specific method.
• Apply user‑level fixes: clear cache, update, free storage, disable battery optimizations.
• If you control the code, move heavy work off the UI thread, eliminate deadlocks, and profile with Android Studio.
• Verify the fix by logging again; ensure no new ANR entries appear.
• Use bugreport, StrictMode, or broadcast‑receiver analysis for stubborn cases.

By following this systematic approach you can turn a frustrating “App isn’t responding” dialog into a clear, solvable problem—whether you’re an everyday Android user or the app’s developer.