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:
And here we are! You can see all logs coming from your device:
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
- I – Info
- Errors and production follow-up
- W – Warning
- E – Error
- F – Fatal
- 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
“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.
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:
- A way to view messages written directly to the stdout or the stderr output
- A way to view all events that occurred on the device
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:
- Log.v(String, String) (verbose)
- Log.d(String, String) (debug)
- Log.i(String, String) (information)
- Log.w(String, String) (warning)
- Log.e(String, String) (error)
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.