Diagnose and Fix Android App Crashes with Logcat and Android Studio

Why apps crash and why you need the right logs

Most Android crashes end with a generic Unfortunately, app has stopped toast. Behind that message is a stack trace that tells you exactly which class or method threw an exception. Without that information you are guessing, which leads to wasted time and repeated reinstall‑and‑hope cycles. This guide shows you how to capture the stack trace reliably, interpret it, and apply a fix – all without rooting the device.

Before you start

• Device preparation: Enable Developer Options (Settings ▶ About phone ▶ Tap Build number seven times). Then enable USB debugging (Settings ▶ System ▶ Developer options ▶ USB debugging).
• Computer setup: Install the Android SDK Platform‑Tools (adb) and, optionally, Android Studio if you want a graphical view of the logs.
• Charge and connect: Keep the phone charged above 50 % and connect it via a good USB cable. A flaky connection can truncate the log stream.
• Identify the target app: Know the package name (e.g., com.example.myapp). You can find it in Play Store URL or by running adb shell pm list packages | grep myapp.

Method 1 – Capture a crash log with ADB Logcat

Understanding the stack trace

The stack trace is a reverse chronological list of method calls that led to the exception. The topmost line (after the exception type) points to the exact line in your source code that caused the crash. If you have the source, open that file and line number to see the offending code.

• Exception type (e.g., NullPointerException, IllegalStateException) tells you what went wrong.
• Message (text after the colon) often contains the missing value or illegal argument.
• Package name in the stack frames confirms the crash originates from your app and not a system library.

Method 2 – Using Android Studio’s Logcat viewer

From stack trace to fix – a practical workflow

1. Identify the root cause. Look at the exception type and the line number. Common culprits:
   • NullPointerException – a variable wasn’t initialized.
   • ArrayIndexOutOfBoundsException – accessing an array with an invalid index.
   • NetworkOnMainThreadException – performing network I/O on the UI thread.
2. Check surrounding code. Open the file at the reported line. Ask:
   • Is the object guaranteed to be non‑null?
   • Are there any early returns that skip initialization?
   • Do I need to add a null‑check or use ?. (Kotlin) or if (obj != null) (Java)?
3. Apply the fix. Examples:
   • For a null pointer, initialize the variable or guard the call:

     if (userName != null) {
         int length = userName.length();
     }

   • For a UI‑thread network call, move the operation to a background thread using AsyncTask, Executor, or Kotlin coroutines.
4. Re‑build and test. Install the updated APK (via adb install -r app.apk) and repeat the steps that previously caused the crash. Verify that the exception no longer appears in logcat.
5. Optional – add defensive logging. Insert a Log.e() before the risky line to capture variable states in future crashes.

   Log.e("MyApp", "userName=" + userName);
   

Troubleshooting common pitfalls

Logcat shows no FATAL EXCEPTION

• Cause: The crash happens in a native library (.so) and only prints a SIGSEGV without Java stack.
• Solution: Add the -b all flag to capture all buffers, then look for signal 11 (SIGSEGV). Use ndk-stack with the appropriate symbols file if you have native source.

Logcat stops mid‑stream

• Cause: USB connection resets or the device enters sleep.
• Solution: Enable Stay awake in Developer options (Settings ▶ Developer options ▶ Stay awake). Keep the screen on while reproducing.

Multiple apps produce interleaved logs

• Cause: Using a generic adb logcat without filters.
• Solution: Use the --pid filter shown earlier, or create a custom filter:

  adb logcat -s com.example.myapp:D *:S

Advanced tip – Symbolicating ProGuard‑obfuscated builds

If your release APK is built with ProGuard or R8, the stack trace will contain short class names like a.b.c. To translate them back, locate the mapping.txt generated during the build (usually in app/build/outputs/mapping/release/) and run:

java -jar retrace.jar mapping.txt crash_log.txt

The output will show the original class and method names, letting you pinpoint the source of the crash even in an obfuscated build.

Putting it all together – a checklist

• Enable USB debugging and keep the device charged.
• Identify the package name of the crashing app.
• Run adb logcat with a PID or package filter.
• Reproduce the crash and capture the FATAL EXCEPTION block.
• Read the exception type, message, and line number.
• Open the source file, apply a targeted fix, and retest.
• If using an obfuscated release, symbolicate with mapping.txt.
• Optional: Add defensive logging to catch future edge cases.

When to involve the developer community

If after applying the fix the crash persists, or the stack trace points to a third‑party library you cannot modify, consider these steps:

1. Search the exact exception message on Stack Overflow or the library’s issue tracker.
2. Provide the trimmed logcat output (remove personal data) when asking for help.
3. If the library is outdated, check for an updated version that resolves the bug.

With the systematic approach above you’ll move from “my app keeps crashing” to “I know exactly why and how to fix it”, saving hours of blind testing.