How to Diagnose and Fix Android ANR Errors with ADB

Seeing the dreaded "App isn’t responding" dialog is frustrating, especially when it happens to a favorite app. Android shows this dialog when the main (UI) thread has been blocked for more than five seconds. The block can be caused by anything from a slow network call to a misbehaving broadcast receiver. This tutorial walks you through a repeatable, low‑risk workflow that captures the exact moment the ANR occurs, decodes the log, and gives you concrete actions to fix the problem.

Before you start

Step 1 – Reproduce the ANR while capturing Logcat

At this point you have a raw log file that includes the system’s diagnosis of why the UI thread stalled.

Step 2 – Filter the log for the ANR entry

Step 3 – Decode the stack trace

The stack trace appears a few lines after the ANR line and starts with something like DALVIK THREAD or main. Example:

04-12 14:23:45.130  1234  5678 D AndroidRuntime: Shutting down VM
04-12 14:23:45.131  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.132  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.133  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.134  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.135  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.136  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.137  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.138  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.139  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.140  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.141  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.142  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)
04-12 14:23:45.143  1234  5678 D AndroidRuntime: threadid=1: still suspended after undo (sc=1)

What you are looking for are lines that reference the main thread or a specific component such as ActivityThread. The deepest method call before the block tells you what code was executing when the UI stopped responding.

Step 4 – Map the call to a real‑world cause

Typical culprits fall into three categories:

• Long‑running work on the UI thread – network requests, database queries, or heavy image processing.
• BroadcastReceiver or Service timeout – a receiver that does more than 10 seconds of work, or a background service that never calls startForeground().
• ContentProvider query – slow cursor operations, often due to missing indexes.

Match the method name from the stack trace to one of these categories. For example, a line like com.example.myapp.network.ApiClient.fetchData(ApiClient.java:112) points directly to a network call on the UI thread.

Step 5 – Apply the appropriate fix

5.1 – Simple user‑level remedies

1. Clear cache: A corrupted cache can cause repeated ANRs in apps that read large temporary files.

   adb shell pm clear com.example.myapp

   This command clears both cache and data, so be sure you have a backup if the app stores important information locally.
2. Force stop and restart:

   adb shell am force-stop com.example.myapp

   Then open the app again.
3. Update the app: Open Google Play, check for an update, and install it. Developers often fix ANR‑causing bugs in newer releases.
4. Uninstall and reinstall if the problem persists after an update.

5.2 – Targeted fixes based on the stack trace

If the log points to a specific component, you can try more focused actions.

• Network on the main thread – The offending call is usually a .execute() or .get() on an HttpURLConnection or Retrofit call.
  • Install a third‑party “Network Monitor” app (e.g., NetGuard) to see if the app is trying to reach a server that is currently unreachable. If the server is down, the app may be stuck waiting.
  • Switch the device to airplane mode, then back on, to reset the network stack.
• BroadcastReceiver taking too long – The log may show BroadcastQueue.processNextBroadcast.
  • Boot the device into Safe mode (press and hold the power button, then long‑press “Power off” and confirm). Safe mode disables third‑party receivers, letting you verify if the ANR disappears.
  • If the ANR vanishes, the culprit is a third‑party app that registered a receiver. Consider disabling or uninstalling that app.
• Service timeout – Look for ServiceRecord.startRequested followed by a long pause.
  • Check battery optimization settings: Settings → Apps → [App] → Battery → “Optimized”. Turning off optimization for a misbehaving service can prevent the system from killing it before it finishes its start‑up work.
• ContentProvider query – Stack trace shows android.database.CursorWrapper.
  • If the app uses a local SQLite database, clear the app’s data (see 5.1) – this forces the app to rebuild its tables and indexes.

Step 6 – Verify the fix

Advanced diagnostics (optional)

When the basic steps don’t pinpoint the problem, you can gather a full bug report.

1. Run:

   adb bugreport bugreport.zip

   This creates a compressed archive containing system logs, tombstones, and the last ANR report.
2. Extract the archive and open system_log.txt. Search for ANR again – the bug report often includes extra fields like ActivityManager: ANR in … (reason=…) that clarify whether the timeout was caused by a broadcast, a service, or a content provider.

Advanced users can also use adb shell dumpsys activity services to list all running services and their start times, helping you spot a service that never finishes its initialization.

Troubleshooting common pitfalls

• Logcat shows nothing after the ANR – Ensure you did not accidentally filter out the main buffer. Use adb logcat -b all to capture every buffer.
• Device not detected by ADB – Install the OEM USB driver, enable USB debugging (Security settings) on Android 12+, and try a different cable or USB port.
• Log file is huge and hard to read – Limit capture to a time window: adb logcat -b main -v time -t 60 > anr_last_minute.txt captures only the last 60 seconds.
• Clearing app data wipes important information – Before running pm clear, export any needed data via the app’s own export feature or by copying its files from /sdcard/Android/data/… (if accessible).

Preventing future ANRs

Even after you fix the immediate issue, it’s worth tightening the device’s overall health to avoid new ANRs.

• Enable StrictMode (Developer option): Settings → Developer options → StrictMode enabled. This flashes a visual cue whenever an app does disk or network I/O on the UI thread, nudging developers (and power users) to spot problem code early.
• Limit background work with Android’s App Standby Buckets. Apps that sit idle for long periods are moved to a lower bucket, reducing the chance they will block the UI when you finally open them.
• Keep the system and apps updated. Security patches and runtime optimizations often include ANR‑related fixes.
• Regularly clear cache for heavy apps (e.g., browsers, media players) via Settings → Apps → [App] → Storage → Clear cache.

When to seek deeper help

If you have tried the steps above and the ANR persists with the same stack trace, the root cause is likely inside the app’s code. In that case:

• Contact the app developer with the extracted stack trace – most developers appreciate a precise log.
• Consider filing a bug on the app’s issue tracker (GitHub, GitLab, or the Play Store “Send feedback” link).

Providing a clear, timestamped snippet from your Logcat makes it far easier for developers to reproduce and fix the bug.

Summary

ANR dialogs are Android’s way of telling you that something on the UI thread is taking too long. By capturing Logcat with ADB, filtering for the ANR line, and interpreting the stack trace, you can quickly identify whether the problem lies in the app’s cache, a network call, a broadcast receiver, or a service. The tutorial walks you through safe user‑level fixes – clearing cache, updating, or disabling the offending component – and offers advanced diagnostics for stubborn cases. With these tools in hand, you’ll turn “App isn’t responding” from a mystery into a manageable, solvable event.