Logcat: Tips, Tricks & Clicks

Android developers often find themselves using Logcat when debugging their applications.
In this blog post, I would like to share some useful tricks and tips for Logcat.

Tips & Tricks

Getting Help

Use adb logcat -h to get the usage menu of logcat (this option doesn’t exist and logcat just prints the usage text and exits).

Filtering Outputs

The official docs state that you should use:

to filter for log messages with a given tag and loglevel. The *:S parameter tells logcat to omit all other outputs. Note that it’s easier to simply use:

because this doesn’t provoke any shell autocompletion feature triggered on the asterisk.

When the application uses multiple but similar tags, I find it actually far more easier to use grep:

A pretty need way to get all logs from an app without relying on tags is to actually filter logcat’s output by the process id of the application:


Using more Unix magic, we can view the logs and simultaneously write them to a file:

(We need to use line buffering mode in grep because the input stream from logcat is continuous and we want to grep & tee while logcat is still running)

Colourised Output

I made Python script (based on Jeff Sharkey original script) which allows you to colourise logcat’s output:

Coloured Logcat

Saving the logs

By running adb logcat ADB actually calls the /system/bin/logcat binary on the phone and gets its output from there.
This means that the -f option (writing the output to a file) expects a file on the device and not on the development machine:


(-d tells logcat to only output log messages up to now and exit)

If you regularly pull log files from the device, it’s helpful to call adb logcat -c before running adb logcat -f.
This will flush the latest log and help you to now find the same logs in subsequent log files.

Make logs “clickable”

When you’re debugging in Java you’re used to directly click on that nasty NullPointerException in your console output in order to jump to the line in question. While developing an Android application, it would be handy to know where the logcat output came from. Unfortunately, the log message created by android.util.Log.*() won’t allow you to do this. However, we can use Java’s introspection to get information such as filenames or line numbers from the current stack trace. With this information, we can construct a log message which corresponds to the pattern Eclipse recognizes as “clickable”.

Here’s a little example on how you could do this:


The idea is to use a wrapper around android.util.Log that will always output two log messages. The first message is your actual log output. The second output imitates exactly the clickable stack trace you’re used to when something goes wrong in Java. So, when used like this:


The logcat output will look like:

... MyTag MyMessage
... MyTag at com.example.MainActivity(MainActivity.java:5)

When clicking on the second message in Eclipse’s LogCat view, you’ll land directly on line 5 of the MainActivity.java. Android Studio recognises the (MainActivity.java:5) and lets you click there right away. Using reflection, you could also remove the mandatory Tag argument:

Logcat can be quite tricky and it helps to know how to tame the beast. Hope you enjoyed the ride!

[Thanks to XDA News Writer jaseglenn4 for the photo!]




Have something to add?

Loading Facebook Comments ...

Leave a Reply