A how-to guide to debugging
with Android Logcat

I have recently coded a new open-source collector for the Android SDK. It was my first time working for Android devices so I came with a fresh look at the Android SDK and more specifically its logging part.

When developing and targeting a remote device such as a smartphone or tablet, you are faced with the following issue: how to retrieve all events, logs and metrics from the remote device to your local environment?

Logcat is the solution for the Android stack and solves the issue brilliantly, allowing you an easy access to application and system logs for debugging. I am going to share what I learned here with a how- to guide to debugging with Android Logcat.

I. Android Logcat takes you deep diving into your logs

Android Logcat is a part of the Android monitoring toolbox and an adb (Android Debug Bridge) sub-command. Any developer can thus get all logs and messages from their remote (or emulated) device.

Android Logcat allows you to:

  • View, filter and collect all application logs
  • View, filter and collect all system logs such as the garbage collector events
  • Retrieve all unexpected errors that have occurred

In other words, Android Logcat saves you many hours of searching by informing you what’s causing a problem.

II. Where to get Android Logcat

If you have installed the Android Studio, then you already have it. If not, and in case you just want to access the log stream, you’ll have to install and configure the Android Debug Bridge — the adb command, as is explained in this article from lifehacker.com.

Then, you need to ensure that your targeted phone is in the developer mode and that you have allowed the USB debugging.
Finally, start the adb logcat service just by using that command: adb logcat.

And here we are! You can see all logs coming from your device:

adb Output Android Logcat

The adb Logcat output – No filters

III. Filter logs by application

The raw output is a very verbose one, so it’s quite complicated to find valuable information in it. But Android Logcat provides a way to filter specific events to help you identify information

Let’s have a look at the following example:

01-30 11:50:00.760 12286 12954 E my-android-app: Time to load native libraries: 5 ms (timestamps 9365-9370)

All messages have a priority (E) and a tag (my-android-app) associated with them. Tags identify components from where messages originated while priority indicates severity.

Severities are ordered by levels. Here is the full list of available severities, starting with the lowest and up to the highest:

  • Developing and Debugging
    • V – Verbose
    • D – Debug
  • Audits
    • I – Info
  • Errors and production follow-up
    • W – Warning
    • E – Error
    • F – Fatal
  • Misc
    • S – Silent (mostly used to filter the Logcat output)

Now, let’s look at how to filter messages with the pattern described above.

adb logcat "my-android-app:E" "*:S"

This expression matches all errors (including fatal ones) from “my-android-app”. The first part filters at least all errors from “my-android-app” application. We then add the second parameter using the “silent” priority to force all other logs not to display.

As you can see, priority and tag name are very important. If you wish to easily retrieve your logs, you have to pay special attention when naming them.

Android Logcat Fingerprintserivice

The adb Logcat output – Filter on the FingerPrintService messages

Android Logcat provides 2 more options that can become handy. So, just to make sure they’re on your mind, here they are:

IV. Useful filter patterns

Below are a couple of commands that I find the most useful:

Save all logs into a file

adb logcat -f <output_file>

Get all errors and fatals

adb logcat "*:E"

Use wildcard filter with Android Logcat (Linux only)

adb logcat | grep -i "foo.example." #get all logs related to “foo.example.*” tagname

Get all logs by application name

adb logcat "application_or_tag_name:*" "*:S"

Get all GSM state changes

adb logcat -b events "gsm_service_state_change" "*:S"

Get all Radio events

adb logcat -b radio

V. Bind Android Logs and Logcat

The Android SDK provides a very simple Logger class. By default, each event logged using it is available through the Logcat stream.

Common logging methods include:

Each method reports the message with its corresponding priority. The first argument is about the tag name and the second one is the logged message.

Of course, you can use them in your code just as the following call:

Log.i("MyActivity", "MyClass.getView() — get item number " + position);

The Logcat outputs will then look like:

I/MyActivity( 1557): MyClass.getView() — get item number 1

And this it. The Android logger is a (very) minimalist one!—-

One last word

We’ve seen how Logcat works and what a powerful tool it can be while developing
BUT its main limitation is about debugging and troubleshooting once the application is in production, installed on a user device. Android Logcat can will never be a solution to this specific need.

So, how can you gather logs and metrics from a live application? You need to look for another tool.

Out of this need was born the motivation to develop an open-source handler: logmatic-android. Its goal is to centralize all live logs, events and metrics into one place, no matter what the version of Android is, or where your user is located.

What technology would you like to read on? Feel free to send in ideas or feedback to Feedback@logmatic.io. Would also be glad to connect on Twitter @gpolaert 😀

Related Posts

Get notified when new content is published