How to Read Android Logcat: Levels, Tags and Filters

Logcat is Android's system log: a rolling buffer where the OS, system services and your apps write messages. To read it, run adb logcat on a computer with USB debugging enabled, or open a logcat viewer in a tool such as ADBKit. The skill is not reading everything; it is filtering down to the few lines that explain a problem.

What logcat records

Every log entry has a level, a tag and a message. The tag usually names the component that wrote it (ActivityManager, OkHttp, or your own class name). Entries live in several buffers: main (app logs), system, crash and events among them. The buffers are circular, so old lines disappear as new ones arrive.

Log levels run from least to most severe:

Reading a single line

With the -v time format, a line looks like this:

10-06 14:03:21.456 E/AndroidRuntime( 1234): FATAL EXCEPTION: main

From left to right: date and time, level (E), tag (AndroidRuntime), the process ID in parentheses (1234), then the message. The default threadtime format on modern Android also shows the thread ID next to the PID:

10-06 14:03:21.456  1234  1250 E AndroidRuntime: FATAL EXCEPTION: main

The PID is the most useful field when several apps are noisy at once, because one process ID isolates one running instance of your app.

adb logcat essentials

adb logcat                      # stream live output
adb logcat -v time              # use the time format shown above
adb logcat *:W                  # warnings and above, all tags
adb logcat -s MyTag             # only the tag MyTag
adb logcat --pid=1234           # only one process
adb logcat -d                   # dump the buffer and exit
adb logcat -c                   # clear the buffer
adb logcat -b crash             # read the crash buffer

Find an app's PID with adb shell pidof com.example.app. Combine options as needed, for example adb logcat -v time --pid=1234 *:W. Redirect to a file with adb logcat -d > log.txt when you need to share a capture.

Note: Clearing the buffer with -c before reproducing a bug gives you a short, clean log that is easy to read.

Reading a stack trace

When an app crashes, logcat prints a Java or Kotlin stack trace under an E/AndroidRuntime line:

E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.example.app, PID: 1234
    java.lang.RuntimeException: Unable to start activity
        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3449)
    Caused by: java.lang.NullPointerException: Attempt to invoke virtual method ...
        at com.example.app.MainActivity.onCreate(MainActivity.java:42)

Read it in this order:

1. The first line after FATAL EXCEPTION names the exception that surfaced.
2. Scroll to the last Caused by:. That is usually the root cause.
3. Find the first at line that belongs to your own package (here MainActivity.java:42). That is where to start looking in the code.

Frames from android.* or java.* show how the framework got there; they rarely contain the bug itself.

Reading logcat in ADBKit

The ADBKit workspace has a Logcat panel that works in a Chromium-based browser such as Chrome or Edge, with no install and no account. It fetches log entries in batches, every 2 seconds by default, and you can change that to 1, 2, 5 or 10 seconds. It is not a continuous stream.

What the panel gives you:

• Level filter from verbose up to fatal.
• Search with case-sensitive and regex toggles.
• Tag include/exclude, for example Foo, -Noisy shows Foo and hides Noisy.
• PID filter and filter by installed app, so you can see one app without looking up its PID.
• Folded stack traces: the trace lines sit under their error line and expand when you want them.
• Right-click menu to hide or show entries by tag, process or message pattern.
• Pause, clear, copy and export to a text file.

Log data goes only between the browser and your phone; ADBKit has no server that receives it. If the device does not connect, see fixing ADB busy, unauthorized and no-device errors.

A practical debugging workflow

1. Clear the log (adb logcat -c, or Clear in the panel).
2. Set the level to Warning or Error, and pick your app in the app filter or by PID.
3. Reproduce the problem once.
4. Pause the view. Find the first error near the moment of the failure; later errors are often just consequences.
5. Open the stack trace, go to the last Caused by:, then to your own code line.
6. If the cause is unclear, lower the level to Info or Debug and widen the time window around that line.
7. Export or copy the relevant lines for a bug report.

Crashes that kill the process sometimes leave details in the crash buffer, so adb logcat -b crash -d is worth trying after the fact. For a full list of other commands, see the adb commands cheat sheet.

Warning: Logs can contain account names, tokens and other personal data. Review an exported file before attaching it to a public issue.