How to Find an App Crash in Logcat: Stack Traces, ANRs, Filters

To find an app crash in logcat, clear the buffer, filter to errors with adb logcat *:E, reproduce the crash, and look for a block that starts with FATAL EXCEPTION under the AndroidRuntime tag. The last Caused by: line in that block is the root cause, and the first at frame from your own package is where to start reading code. This guide covers Java/Kotlin crashes, ANRs and native crashes, the filters that get you there quickly, and how to turn what you found into a bug report. If logcat itself is new to you, start with how to read Android logcat.

What an app crash looks like in logcat

An uncaught exception in a Java or Kotlin app always produces the same shape of output under the AndroidRuntime tag at level E:

E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.example.app, PID: 18422
    java.lang.IllegalStateException: Fragment not attached to a context.
        at androidx.fragment.app.Fragment.requireContext(Fragment.java:960)
        at com.example.app.ui.ProfileFragment.loadAvatar(ProfileFragment.kt:88)
    Caused by: java.lang.NullPointerException: user must not be null
        at com.example.app.data.UserRepository.current(UserRepository.kt:34)
        ... 12 more

The useful lines, in the order you should read them:

Tip: Android keeps a separate crash log buffer. adb logcat -b crash -d prints only crashes, which is handy when you were not watching at the time.

ANRs: when the app freezes instead of crashing

An Application Not Responding dialog is not an exception. The process is alive but its main thread has been blocked too long: about 5 seconds for input, 10 for a broadcast receiver, 20 for a foreground service. In logcat an ANR appears under ActivityManager:

E ActivityManager: ANR in com.example.app (com.example.app/.MainActivity)
E ActivityManager: PID: 18422
E ActivityManager: Reason: Input dispatching timed out (Waiting to send non-key event ...)
E ActivityManager:   96% 18422/com.example.app: 91% user + 5% kernel

The Reason: line names the trigger: Input dispatching timed out means a tap or key was not handled, Broadcast of Intent means a receiver blocked, executing service means a service lifecycle method ran too long. The CPU line tells you whether your process was busy (heavy work on the main thread) or waiting (a lock or a synchronous network call).

The stack of every thread at the moment of the ANR is not in logcat. Android writes it to a traces file, and the simplest way to get it on a modern device is a bug report:

adb bugreport anr-report.zip

Inside the ZIP, look under FS/data/anr/; the thread named "main" shows what the UI thread was doing when the system gave up. Older devices write /data/anr/traces.txt instead.

Native crashes: signal 11 and tombstones

Apps that use the NDK, or libraries that do (video decoders, game engines, crypto wrappers), can crash below the Java layer. There is no FATAL EXCEPTION; instead the DEBUG tag prints a block like this:

F DEBUG   : pid: 18422, tid: 18490, name: RenderThread  >>> com.example.app <<<
F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
F DEBUG   : backtrace:
F DEBUG   :       #00 pc 000000000004f2a8  /data/app/.../lib/arm64/libnative.so (decode_frame+120)
F DEBUG   :       #01 pc 00000000000b113c  /data/app/.../lib/arm64/libnative.so (Java_com_example_app_Decoder_next+44)

signal 11 (SIGSEGV) is an invalid memory access, usually a null or dangling pointer; signal 6 (SIGABRT) is a deliberate abort from a failed assert or CHECK. Frame #00 of the backtrace is where it faulted. Android saves the full dump as a tombstone under /data/tombstones/, included in adb bugreport. If the frames show only hex addresses, the library was stripped and the developer must symbolise the trace with ndk-stack.

Filters that get you to the crash faster

A phone writes thousands of log lines a minute, and the crash is ten of them. These filters cut the rest away.

Combine them. A typical capture is two commands with the reproduction in between: clear, reproduce until the dialog appears, then dump.

adb logcat -c
adb logcat -d -v time *:W > crash.txt

Note: --pid stops matching once the app restarts, because the new process gets a new PID. If the crash makes the app relaunch, search for the package name in the message text instead, or filter by tag.

Dropped logs and the buffer size

If your capture has a gap, or logcat prints chatty: uid=10234 com.example.app expire 180 lines, the device threw lines away. The log buffer is circular and small (often 256 KB), so a chatty app can push the crash out within seconds, and logd also collapses repeated identical lines into chatty or expire counts.

To widen the window, open Settings → Developer options → Logger buffer sizes and raise it to 4 MB or 16 MB before a long reproduction session. From the command line:

adb logcat -g              # show current buffer sizes
adb logcat -G 16M          # set the buffer size

Finding the crash in ADBKit

ADBKit shows logcat in a panel next to the live device screen, so you can watch the app and its logs together without a terminal. It runs in Chrome or Edge over WebUSB; nothing is installed and log data travels only between the browser and the phone.

1. Connect the phone and open the Logcat tool. Set Minimum log level to Error so warnings and chatter disappear.
2. Use the App filter to pick your package, or type the package name in the search box. Stack trace lines are searched too, so a class name works as well.
3. Click Clear logs, then reproduce the crash on the live screen.
4. When the crash appears, click Pause. The view stops moving and the trace stays put. The FATAL EXCEPTION entry folds its trace lines under it; expand it and right-click to Copy stack trace.
5. Click Export logs to save the visible lines as a text file. The level and app filters apply to the export, so the file contains the crash and not the rest of the phone.

Use the Screenshot tool to capture the error dialog, or start a screen recording before you reproduce; see screenshots and screen recording. The panel also shows a logs dropped count; if it climbs, raise the logger buffer size as above.

Writing a bug report that gets fixed

A crash report is useful when a developer can reproduce it without talking to you. Include:

• Steps, numbered, from a known state ("fresh install", "logged in as a test user").
• Device and OS: model, Android version, app build. adb shell getprop ro.product.model and adb shell getprop ro.build.version.release give the first two.
• The log excerpt: the full FATAL EXCEPTION block with every Caused by:, the ANR in block, or the DEBUG backtrace. Attach the exported file; paste only the relevant 20 to 40 lines inline.
• A screenshot or recording of what the user saw.
• Frequency: every time, or one in five attempts.

Warning: Logs can contain email addresses, auth tokens and other personal data. Read the excerpt before pasting it into a public issue tracker and redact what does not belong there.

For the rest of the command-line toolbox see the ADB commands cheat sheet, and if you test builds without an IDE, see testing an APK on a real device without Android Studio.