ADB Logcat: Filtering and Reading Android Debug Logs

Android's logcat subsystem records every event the OS and installed apps emit, from verbose debug messages to fatal crash traces. Reading raw logcat output is overwhelming — thousands of lines per minute scroll past. Knowing how to filter by tag, priority, process, and time window turns logcat from noise into a precise diagnostic tool. This guide covers the full filtering syntax with practical examples for real debugging workflows.

Running Logcat

With ADB connected and USB Debugging enabled, start a live log stream:

adb logcat

Output begins immediately and scrolls until you press Ctrl+C. Each line follows this format:

MM-DD HH:MM:SS.mmm  PID  TID Priority Tag: Message

Priority levels from lowest to highest are: V (Verbose), D (Debug), I (Info), W (Warning), E (Error), F (Fatal), S (Silent — suppresses all output for that tag).

Clear the existing log buffer before starting a capture so you only see events from this session:

adb logcat -c

Filtering by Tag and Priority

The most common form of logcat filtering uses tag:priority specifiers. Pass them as positional arguments after the command:

adb logcat ActivityManager:I *:S

This shows only Info and higher messages from the ActivityManager tag, and silences everything else (*:S). The *:S wildcard is nearly always required — without it, Android also prints all unfiltered tags at their default priority.

To watch multiple tags simultaneously:

adb logcat ActivityManager:I WindowManager:W PackageManager:E *:S

Each specifier is space-separated. The priority letter you provide acts as a minimum threshold — specifying W includes Warnings, Errors, and Fatals for that tag.

To show only errors across all tags:

adb logcat *:E

This is the quickest way to spot crash-level problems without the noise of debug and info messages.

Filtering with grep

Grep-based filtering is more flexible because it matches on any part of the log line, not just the tag field. On Linux and macOS:

adb logcat | grep -i "myapp"

Case-insensitive search for any line containing "myapp". To match crashes specifically:

adb logcat | grep -E "AndroidRuntime|FATAL EXCEPTION"

On Windows Command Prompt, use findstr instead of grep:

adb logcat | findstr "AndroidRuntime"

In PowerShell:

adb logcat | Select-String "AndroidRuntime"

Grep and logcat filters can be combined. The logcat filter narrows the stream first, then grep applies a second pass:

adb logcat *:E | grep -v "Choreographer"

This shows all errors but excludes the noisy Choreographer frame-drop warnings that often clutter error output on slower devices.

Filtering by Process ID

To isolate one specific app's log output, find its process ID first:

adb shell pidof com.example.myapp

Then pass the PID to logcat using the --pid flag (available on Android 7.0 and later):

adb logcat --pid=12345

Replace 12345 with the actual PID from the previous command. This is especially useful on a busy device where many apps are emitting logs simultaneously and tag filtering alone is insufficient.

On older devices without --pid support, pipe through grep on the PID column:

adb logcat | grep " 12345 "

Note the spaces around the PID to avoid false matches against timestamps or message content.

Writing Logcat Output to a File

For reproducible bug reports or offline analysis, write logcat directly to a file:

adb logcat -d > logcat_output.txt

The -d flag dumps the current log buffer and exits rather than streaming. This captures everything already in the buffer (typically several thousand lines) in one snapshot.

For continuous capture to a file while also watching it live, use tee on Linux or macOS:

adb logcat | tee logcat_session.txt

To write the log on the device itself (useful when a PC is not connected during the crash), use the -f flag inside an ADB shell:

adb shell logcat -f /sdcard/crash_log.txt *:E &

This starts logcat on the device in the background, writing error-level messages to the SD card. After reproducing the issue, retrieve the file:

adb pull /sdcard/crash_log.txt .

Reading Crash Logs

Java and Kotlin crashes (uncaught exceptions) always appear under the tag AndroidRuntime. A typical crash block looks like:

E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.example.myapp, PID: 12345
E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke virtual method ...
E AndroidRuntime:     at com.example.myapp.MainActivity.onCreate(MainActivity.java:42)
E AndroidRuntime:     at android.app.Activity.performCreate(Activity.java:8290)

The critical lines are the exception type, the message on the same line, and the first at com.example stack frame — that is the line in your own code that caused the crash. Lines referencing Android framework internals below it are usually secondary context.

Native (NDK) crashes appear under DEBUG tag with a signal description:

adb logcat DEBUG:F *:S

Native crash output includes the signal number (e.g., SIGSEGV), the faulting address, and a stack backtrace with library offsets that can be resolved using ndk-stack.

Log Format Options

The default logcat format is threadtime. You can switch to other formats with -v:

adb logcat -v brief

Useful format options:

• brief — Priority/Tag/PID only, no timestamp. Compact for quick reads.
• time — Adds timestamp without thread ID.
• threadtime — Default. Timestamp + PID + TID + Priority + Tag.
• long — Each log entry on multiple lines, making long messages easier to read.
• json — Machine-parseable JSON output, useful when piping into log analysis scripts.

For structured analysis of a captured log file, JSON format combined with jq enables powerful querying:

adb logcat -v json *:E | jq 'select(.tag=="AndroidRuntime")'

Log Buffers

Android maintains separate log buffers. By default, adb logcat reads from the main, system, and crash buffers. You can specify buffers explicitly with -b:

adb logcat -b crash

Available buffers include main, system, radio (telephony events), events (structured event log), and crash (retains last crash even after reboot). The crash buffer is the first place to check when a user reports a crash but cannot reproduce it immediately:

adb logcat -b crash -d

This dumps the crash buffer without streaming and exits, giving you the most recent fatal exception even if it happened before you connected ADB.