Diagnosing and fixing Android App Not Responding (ANR) errors

When an Android app shows the dreaded App Not Responding (ANR) dialog, the device feels frozen and you’re left wondering what went wrong. This guide walks you through a repeatable workflow to capture the exact cause, interpret the information, and apply concrete fixes – all without rooting the phone.

Before you start

• Back up important data (photos, messages, etc.) – the steps involve clearing app data in a few places.
• Charge the device to at least 50 % or keep it plugged in.
• Install Android Platform‑Tools (ADB) on your PC/macOS/Linux machine.
• Enable Developer options (Settings ▶ About phone ▶ tap Build number seven times).
• Turn on USB debugging (Settings ▶ System ▶ Developer options ▶ USB debugging).

Understanding ANR – why does it happen?

An ANR is triggered when the main (UI) thread of an app is blocked for more than five seconds. Android’s watchdog watches three key queues:

1. Input dispatch – waiting for the app to process a touch or key event.
2. BroadcastReceiver – a broadcast is taking too long.
3. Service – a foreground service is stuck.

If any of those queues exceed the timeout, the system shows the ANR dialog. The good news is that the exact cause is always recorded in system logs, which we can retrieve with ADB.

Step 1 – Capture the ANR log

Step 2 – Locate the relevant ANR entry

Open activity_dump.txt in any text editor and search for the string ANR in. You’ll see a block similar to:

ANR in com.example.myapp (com.example.myapp/.MainActivity)
Reason: Input dispatching timed out (Waiting for event dispatch)
KeyDispatchingTimedOut: keyDispatchingTimedOut
  at android.view.ViewRootImpl$W@... (some stack)
  at android.os.Handler.handleCallback(Handler.java:...)
  ...

The first line tells you which package is at fault. The Reason line explains which queue timed out. The following stack trace shows the exact Java call stack that was stuck.

Step 3 – Common causes and how to fix them

Read the stack trace carefully; the topmost method (the first line after the exception) is where the UI thread was busy.

1. Heavy work on the main thread

Typical stack entries:

at com.example.myapp.network.ApiClient.fetchData(ApiClient.java:45)
at com.example.myapp.ui.MainActivity.onCreate(MainActivity.java:30)

**Why it matters:** Network calls, large database queries, or file I/O on the UI thread block the event queue.

Fixes:

• Move the work to a background thread – AsyncTask (legacy), WorkManager, ExecutorService, or Kotlin coroutines with Dispatchers.IO.
• Show a progress indicator so the user knows something is happening.

2. Long‑running BroadcastReceiver

Stack example:

at com.example.myapp.receiver.SyncReceiver.onReceive(SyncReceiver.java:22)

**Why it matters:** The system expects onReceive() to finish quickly (under 10 ms). Doing heavy work here triggers an ANR.

Fixes:

• Call goAsync() and start a background service or JobIntentService to finish the work.
• If you only need to schedule work, use WorkManager directly from the receiver.

3. Blocking ContentProvider queries

Stack example:

at android.content.ContentResolver.query(ContentResolver.java:1234)
at com.example.myapp.data.ContactRepository.loadAll(ContactRepository.java:57)

**Fix:** Perform the query on a background thread (e.g., via LiveData + Room or coroutines).

4. Service running on the main thread

Even a Service that does not have its own thread runs on the UI thread by default.

**Fix:** Convert the service to an IntentService (deprecated) or better, use JobIntentService / WorkManager for background work.

5. Overloaded UI layout

Very deep view hierarchies or complex custom drawing can cause the UI thread to spend >5 s measuring/layout.

**Fix:** Use ConstraintLayout, flatten the hierarchy, and profile with Android Studio’s Layout Inspector.

Step 4 – Verify the fix with Android Studio Profiler (optional)

If you have the source code, the most visual way to confirm that the UI thread is no longer blocked is the CPU profiler.

1. Open Android Studio, connect the device, and select Profiler from the bottom toolbar.
2. Click CPU, then Record while reproducing the ANR.
3. Stop the recording and look for a long spike on the main thread. The call stack should now show only quick UI work.

If the spike disappears, you’ve likely resolved the root cause.

Step 5 – Quick user‑level fixes (when you can’t modify the app)

Sometimes you’re dealing with a third‑party app and can’t change the code. Try these system‑level actions:

• Clear cache and data: Settings ▶ Apps ▶ [App] ▶ Storage ▶ Clear cache / Clear storage.
• Disable battery optimisation for the app (Settings ▶ Battery ▶ Battery optimisation ▶ All apps ▶ [App] ▶ Don’t optimise). This prevents aggressive Doze‑mode throttling that can masquerade as an ANR.
• Uninstall updates (if the app is a system app) and reinstall from Play Store.
• Free storage space: Android needs free space for temporary files; low storage can cause content‑provider delays.

Step 6 – System‑wide troubleshooting

If multiple apps are showing ANR dialogs, the problem is likely device‑wide:

• Reboot the device – clears temporary locks and frees RAM.
• Check for pending system updates (Settings ▶ System ▶ System update).
• Reset app preferences (Settings ▶ Apps ▶ Menu ▶ Reset app preferences).
• Factory reset as a last resort – back up everything first.

Troubleshooting common capture problems

• No device listed in adb devices:
  • Make sure USB debugging is enabled.
  • Install the appropriate OEM USB driver (Windows) or enable adb access on macOS/Linux.
• Log file is empty:
  • Run the logcat command without the grep filter to verify logging works.
  • Some manufacturers hide the events buffer; try adb logcat -v time instead.
• ANR trace not in activity_dump.txt:
  • Make sure you run the dumpsys activity command *while* the ANR dialog is visible.
  • Alternatively, use adb shell am dumpheap to capture a heap dump for deeper analysis.

Putting it all together – a checklist

1. Enable Developer options and USB debugging.
2. Capture activity_dump.txt and/or filtered logcat during the ANR.
3. Identify the package and the Reason line.
4. Read the stack trace to locate heavy work on the main thread.
5. Apply the appropriate fix (move work off UI thread, use goAsync, etc.).
6. Verify with Profiler or by reproducing the ANR.
7. If you can’t modify the app, try cache clear, battery optimisation toggle, or reinstall.

With the steps above you should be able to turn a frustrating ANR dialog into a clear, solvable problem. Whether you’re a hobbyist developer tweaking your own app or a power user trying to keep third‑party apps stable, the same workflow applies – capture, analyze, fix, and verify.