Capture and Analyze Android App Crash Logs

When an app suddenly closes or throws a mysterious error, the most reliable way to find out why is to look at its crash log. Android records a detailed stack trace for every unhandled exception, but the raw output can be overwhelming. This tutorial walks you through a repeatable workflow: enable the necessary developer settings, capture the log with adb logcat, filter for the offending app, and, if the crash involves native code, translate the addresses using Android Studio’s ndk‑stack tool.

Before you start

• Device preparation: Charge your phone to at least 50 % and keep it on a stable Wi‑Fi network or connected via USB.
• Computer setup: Install the Android SDK Platform‑Tools (includes adb) and, optionally, Android Studio if you want symbol decoding.
• Backup: Capturing logs does not modify the device, but enabling USB debugging can expose the device to ADB commands. Only connect trusted computers.

Step 1 – Enable Developer Options and USB Debugging

Why this matters: USB debugging opens a communication channel between adb on your PC and the device, allowing you to pull logs in real time.

Step 2 – Install Platform‑Tools and Verify the Connection

If the device shows as unauthorized, unplug and re‑plug the cable, then accept the debugging prompt again.

Step 3 – Reproduce the Crash

To capture a useful log, you need the crash to happen while adb logcat is running. Follow these steps:

1. Open a terminal window and start a continuous log stream, filtering for the target package (replace com.example.app with the real package name):

   adb logcat --pid=$(adb shell pidof -s com.example.app) *:E

   If you don’t know the package name, find it in Settings > Apps > [App] > App details.
2. Switch back to the phone and perform the action that triggers the crash (e.g., opening a specific screen, clicking a button, or receiving a notification).
3. When the app crashes, Android will display the “Unfortunately, app has stopped” dialog. Dismiss it; the log continues to record the stack trace.
4. Return to the terminal and press Ctrl +C to stop logging.
   Redirect the output to a file for later analysis:

   adb logcat --pid=$(adb shell pidof -s com.example.app) *:E > crash_log.txt

Step 4 – Isolate the Crash Stack Trace

The raw log contains many lines (system events, other apps, etc.). You need the part that starts with FATAL EXCEPTION. Use a text editor or grep to extract it:

grep -A 20 "FATAL EXCEPTION" crash_log.txt

The output will look similar to:

04-01 12:34:56.789  1234  1234 E AndroidRuntime: FATAL EXCEPTION: main
    Process: com.example.app, PID: 1234
    java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.String.length()' on a null object reference
        at com.example.app.ui.MainActivity.onCreate(MainActivity.java:45)
        at android.app.Activity.performCreate(Activity.java:8000)
        ...

This Java stack trace tells you exactly which class and line caused the exception. If the line numbers don’t match your source code, make sure you’re looking at the same build variant (debug vs. release).

Step 5 – Decoding Native Crashes (Optional)

Some apps crash in native code (C/C++) and the stack trace will contain memory addresses instead of readable symbols, e.g., pc 00000000001234ab /data/app/com.example.app-1/lib/arm64/libnative.so. To translate these addresses you need the .so file and its associated .sym or .debug information.

If you don’t have the original symbol files (common for third‑party apps), you can request them from the developer or use the retrace tool with a .map file if the developer provides one.

Step 6 – Verify the Fix (If You Are the Developer)

After you’ve identified the offending line, edit the source code, rebuild the app, and repeat the capture process to confirm the crash no longer occurs. For non‑developers, you can share the extracted stack trace with the app’s support team; it gives them a concrete starting point.

Troubleshooting Common Issues

• Logcat shows no output for the app: Ensure you used the correct package name. You can list running processes with adb shell ps | grep com.example.
• Logcat floods with unrelated lines: Use the --pid filter as shown in Step 3, or add grep "com.example.app" after the log command.
• Device disconnects during logging: Use a high‑quality USB cable and avoid USB hubs. On some devices, enabling “Stay awake” in Developer options (Settings > Developer > Stay awake) prevents the phone from sleeping while connected.
• Native symbols still unreadable: Verify you are using the unstripped .so files. Release builds often strip symbols; you need a debug build.
• Permission denied when writing to file: Run the terminal with appropriate permissions (e.g., sudo on Linux/macOS) or write to a folder you own.

Best Practices for Ongoing Crash Analysis

• Automate log capture: Create a small batch/script that runs adb logcat and timestamps the file, making it easy to keep chronological records.

  # Windows batch example
      @echo off
      set TIMESTAMP=%date:~-4,4%-%date:~4,2%-%date:~7,2%_%time:~0,2%-%time:~3,2%-%time:~6,2%
      adb logcat -d > crash_%TIMESTAMP%.txt

• Use Google Play Console for production apps: It aggregates crash reports from real users, but manual logcat is still invaluable for reproducing the issue locally.
• Keep device firmware up to date: Some crashes stem from OS bugs that are fixed in later Android releases.
• Document each crash: Record the device model, Android version, app version, and steps to reproduce. This context speeds up debugging.

Safety Warning

By following this workflow you can turn a vague “App keeps crashing” complaint into a precise stack trace, whether the problem lies in Java code or native libraries. Armed with that information, developers can fix bugs faster and users can provide actionable feedback to support teams.