Diagnosing and Fixing Android ANR Errors Without Root

14 min read Learn step‑by‑step how to capture, analyze, and resolve Android “App Not Responding” (ANR) errors using ADB, Logcat, and system settings—no root required. October 08, 2026 06:00 How to Diagnose and Fix Android ANR (App Not Responding) Errors Without Root

When an Android app freezes long enough for the system to show the dreaded "App Not Responding" (ANR) dialog, you lose productivity and confidence in the device. Unlike a simple crash, an ANR indicates that the app’s main (UI) thread is blocked, often for more than five seconds. This tutorial shows you how to capture the exact moment an ANR occurs, read the relevant logs, and apply practical fixes—all without rooting the phone.

Before you start

  • Backup important data. Some of the fixes (e.g., clearing app data) will erase settings or saved content.
  • Use a charged device or keep it plugged in. Capturing logs can take a few minutes.
  • Have a computer with ADB installed. The tutorial includes a quick setup guide.
  • Make sure you have a stable Wi‑Fi or USB connection between the phone and the computer.

1. Enable Developer Options and USB Debugging

  1. Open Settings → About phone.
  2. Find Build number and tap it seven times. You’ll see a toast confirming "You are now a developer!".
  3. Return to the main Settings screen. A new entry Developer options appears.
  4. Enter Developer options and toggle USB debugging on. Confirm the prompt that appears.

On some OEM skins (e.g., Samsung One UI, Xiaomi MIUI) the path may be Settings > System > Developer options or similar. The wording of the toggle is usually "USB debugging" or "Android debugging".

2. Install ADB on Your Computer

If you already have the Android SDK Platform‑Tools, skip to the next section. Otherwise:

  1. Download the Platform‑Tools zip for Windows, macOS, or Linux.
  2. Extract the zip to a convenient location (e.g., C:\adb or ~/adb).
  3. Add the folder to your system PATH so you can run adb from any terminal.
  4. Open a terminal (Command Prompt, PowerShell, or Bash) and type adb version to verify the installation.

If the command prints a version number, you’re ready.

3. Verify the Device Connection

  1. Connect the phone to the computer via USB.
  2. On the phone, you may see a dialog "Allow USB debugging?" – tap Allow. Optionally check "Always allow from this computer".
  3. In the terminal, run adb devices. You should see a line like xxxxxx device.

If the device shows as unauthorized, re‑authorize the computer on the phone.

4. Capture the ANR Trace When It Happens

Android writes ANR information to two places:

  • The system‑wide /data/anr/traces.txt file (requires root to read directly).
  • The bugreport bundle, which includes the same traces and is accessible via ADB without root.

We will use the bugreport method because it works on any device.

4.1 Start a Continuous Log Capture

  1. Open a terminal window and run:
    adb logcat -v threadtime *:W > anr_log.txt
  2. Leave this window open. logcat will record all warning‑level messages and above.
  3. Reproduce the ANR by using the problematic app until the dialog appears.
  4. When the ANR shows, quickly press OK to dismiss the dialog (or let it timeout). The log will now contain the stack trace.
  5. Return to the terminal and press Ctrl+C to stop logging.

The file anr_log.txt now holds the raw Logcat output. Look for a line containing ANR in – it will be followed by the package name and a stack dump.

4.2 Pull a Full Bugreport (Optional)

If you want a more comprehensive view (including system services), run:

adb bugreport bugreport.zip

After the command finishes, unzip the archive and open bugreport.txt. Search for "ANR" to locate the same trace.

5. Interpreting the ANR Stack Trace

An ANR trace typically looks like this (simplified):

ANR in com.example.myapp (com.example.myapp/.MainActivity)
    pid: 1234
    tid: 1234
    name: main
    uid: 10123
    state: R
    stack:
        at android.view.ViewRootImpl$W.performTraversals(ViewRootImpl.java:2520)
        at android.view.ViewRootImpl$W.handleMessage(ViewRootImpl.java:2362)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loop(Looper.java:164)
        at android.app.ActivityThread.main(ActivityThread.java:7615)
        ...

Key elements to read:

  • Package name – tells you which app triggered the ANR.
  • Thread name (main) – ANRs are always caused by the UI thread being blocked.
  • Method chain – the first few lines indicate the code that was executing when the block happened.

If the top of the stack shows android.database.sqlite.SQLiteDatabase, the app may be waiting on a database lock. If you see java.io.FileOutputStream, it could be a slow file write.

6. Practical Fixes You Can Apply Without Root

Most end‑users cannot modify the app’s source code, but many ANR causes are addressed by system‑level actions.

6.1 Clear App Cache

  1. Open Settings → Apps & notifications (or Apps on older Android).
  2. Find and tap the problematic app.
  3. Tap Storage & cache → Clear cache.

Cache files can become corrupted and cause the UI thread to wait indefinitely on I/O.

6.2 Force Stop and Restart the App

  1. In the same app info screen, tap Force stop.
  2. Re‑open the app from the launcher.

This kills any stuck background threads that might be holding a lock.

6.3 Update the App

Developers often fix ANR‑causing bugs in newer releases.

  • Open Google Play Store, tap your profile icon → Manage apps & device → Updates available.
  • If the problematic app appears, tap Update.

6.4 Reinstall the App

  1. Uninstall the app via Settings → Apps → Uninstall.
  2. Re‑install it from the Play Store or a trusted APK source.

This clears both cache and data, giving the app a clean slate. Warning: Any local data (e.g., offline notes) will be lost unless you back it up first.

6.5 Reset App Preferences

Sometimes a mis‑configured permission or default action can freeze the UI.

  1. Open Settings → System → Reset options (or Advanced → Reset app preferences on some devices).
  2. Tap Reset app preferences. Confirm.

This does not delete app data but restores permission defaults.

6.6 Boot into Safe Mode

Safe mode disables all third‑party apps, letting you test whether the ANR is caused by another app interfering.

  • Press and hold the power button.
  • Long‑press the Power off option until the "Reboot to safe mode" prompt appears.
  • Tap OK. The device restarts with "Safe mode" in the corner.

Now launch the problematic app. If the ANR disappears, a recently installed third‑party app is likely the culprit. Uninstall recent apps one by one to isolate the offender.

6.7 Check for System Updates

Android releases often contain performance improvements and bug fixes that resolve ANR‑related framework issues.

  1. Open Settings → System → System update.
  2. Tap Check for updates and install any available update.

6.8 Reduce Background Work

Heavy background services (e.g., sync, location, or heavy widgets) can starve the UI thread of CPU time.

  • Disable or limit background activity for the app via Settings → Apps → Battery → Background restriction.
  • Turn off battery‑intensive features like Adaptive battery for a short test.

7. Using ADB to Perform Some Fixes Faster

If you prefer command‑line, ADB can clear cache, force stop, or uninstall apps without navigating the UI.

# Clear cache
adb shell pm clear com.example.myapp

# Force stop
adb shell am force-stop com.example.myapp

# Uninstall (keep data) – useful for a clean reinstall
adb uninstall com.example.myapp

# Re‑install from an APK you trust
adb install path/to/app.apk

Replace com.example.myapp with the actual package name you saw in the ANR trace.

8. Advanced: Filtering Logcat for ANR‑Specific Tags

Logcat contains many messages; you can narrow the output to only ANR‑related entries.

adb logcat -b events -v threadtime | grep -i "ANR"

The -b events buffer includes system events like ANR reports. This command prints only lines that contain the word "ANR" (case‑insensitive). If you see nothing, the device may not have recorded the event because the ANR dialog was dismissed too quickly. In that case, repeat the capture with a longer log window.

9. Troubleshooting Common Capture Problems

  • No ANR lines in logcat: Ensure you started logcat before reproducing the issue. Some devices buffer logs only for a short period.
  • Permission denied when pulling /data/anr: This file is protected. Use adb bugreport instead, as described in section 4.2.
  • Logcat shows only "ActivityManager: ANR in ..." without a stack: Some OEM skins truncate the stack. In that case, the safest user‑level fix is to clear cache, force stop, and reinstall the app.
  • Device disconnects during logging: Try a different USB cable or use a wireless ADB connection (see ADB over Wi‑Fi).

10. When All Else Fails – Contact the Developer

If you have exhausted the steps above and the ANR persists, the issue is likely a bug in the app’s code. Provide the developer with the relevant stack trace (copy the lines from anr_log.txt) and a short description of what you were doing when the ANR occurred. Most developers appreciate a reproducible report and may issue a fix in a future update.

Summary of the Workflow

  1. Enable Developer Options and USB debugging.
  2. Install ADB on your computer.
  3. Connect the device and verify adb devices.
  4. Start a logcat capture, reproduce the ANR, then stop logging.
  5. Locate the ANR stack trace in the saved log.
  6. Apply user‑level fixes: clear cache, force stop, update/reinstall, safe mode, system update.
  7. If needed, use ADB commands for faster execution.
  8. Report persistent issues to the app developer with the captured trace.

By following these steps, you can turn an opaque "App Not Responding" dialog into concrete information and a clear path to resolution—without ever needing root access.

User Comments (0)

Add Comment
We'll never share your email with anyone else.