Development and debugging of applications on the Android platform is impossible without a deep understanding of the internal processes of the operating system. When an application crashes, freezes, or behaves unpredictably, the developer is faced with the need to look “under the hood” of the device. This is where Android Logcat comes into the picture - a powerful tool built into the Android SDK that allows you to view system logs in real time.
Using this mechanism makes it possible to monitor messages generated by the system and applications, analyze the call stack during crashes, and diagnose performance problems. Without the skills to work with logs, searching for bugs turns into guessing from tea leaves, while competent analysis logcat provides comprehensive data about the state of the device at a specific point in time.
In this article we will look in detail at how to set up the environment, connect the device and effectively filter data streams in order to find only the information that is really important for solving your problem.
Preparing the environment and installing ADB
Before you can intercept system logs, you need to prepare your workplace. The main tool for interacting with the device is Android Debug Bridge (ADB). This is a universal command line utility that allows your computer to communicate with an emulator or connected Android device.
First, you will need to install Android Studio or download the minimum Platform Tools package from the official Google developers website. After downloading the archive, you need to unpack it into a convenient directory. It is important to add the path to the folder with the executable files to the PATH system variable so that the commands are accessible from anywhere in the terminal.
The next critical step is to configure the smartphone or tablet itself. By default, debug mode is disabled for security reasons. You need to go to the device settings, find the “About phone” item and quickly tap on the build number seven times to unlock the developer menu.
⚠️ Attention: After enabling USB debugging mode, do not connect the device to unfamiliar computers or public charging stations, as this may open access to your data.
Now in the “For Developers” menu that appears, activate switch USB debugging. When you connect the cable to your computer for the first time, you will be prompted to confirm debugging with your RSA key fingerprint on your smartphone screen. Be sure to click "Allow", otherwise ADB will not be able to establish a connection.
☑️ Checking readiness for work
Basic commands and starting monitoring
After the cable is connected and rights are confirmed, open a terminal or command line on the computer. The first command to run is to check the visibility of the device. Type adb devices and press Enter. If everything is configured correctly, you will see the serial number of your gadget and the status device.
To start a continuous flow of logs, use the command adb logcat. Executing this instruction will display an endless stream of text messages from all system processes to the console. However, the “raw” output is often too voluminous and difficult to understand due to the huge amount of overhead information.
adb logcat -v timeAdding a flag -v time makes the output more readable by adding timestamps to each line. This is critical when analyzing the sequence of events that led to the error. You can determine exactly at what second the failure occurred and what actions preceded it.
You can also redirect the output to a file for later detailed study. This is convenient when you need to analyze the logs after the fact or transfer them to a colleague. The command adb logcat -d > logfile.txt will save the current log buffer to a text file and exit the utility.
Use the adb logcat -c command before starting the test to clear the current log buffer and get clean output only from the moment the problem began to be reproduced.
Filtering logs by tags and priorities
Working with a full data stream is inefficient, so filtering is a key skill when using Android Logcat. Each message in the log has a Tag, which usually corresponds to the name of the class or component, and a Priority, which indicates the importance of the event.
Priorities in Android have a strict hierarchy. Knowing these levels helps you quickly filter out information noise. The main levels include:
- 🔇 Verbose: Detailed debugging information, usually disabled in release builds.
- ℹ️ Debug: Messages for developers that are useful when debugging application logic.
- ⚠️ Warning: Potential problems that do not cause an immediate crash, but require attention.
- ❌ Error: Critical errors due to which the functionality does not work or the process crashes.
- 🛑 Assert: A message that something impossible has happened from the point of view of the app logic.
To filter the output, leaving only errors of a specific application, you can use specialized syntax. For example, the command adb logcat MyTag:E *:S will show only messages with a tag MyTag level Error and higher, ignoring all others (S means Silent).
Often developers use their own tags to mark events in the code. Searching for a specific tag speeds up diagnostics significantly. If you know that your network module logs data under a tag NetworkManager, filtering by this word will instantly isolate the required lines from thousands of other system records.
Analyzing the structure of a Logcat message
Each line in the utility output has a strictly defined structure, understanding of which is necessary for correct interpretation of the data. Ignoring the format may lead to false conclusions about the nature of the error.
A standard log line consists of several components: priority, process identifier (PID), thread identifier (TID), tag and the message itself. Separators and format may vary depending on the output format used (brief, process, thread, time, threadtime).
| Component | Description | Example value |
|---|---|---|
| Priority | Severity level messages | I (Info), E (Error) |
| PID | Application process ID | 12345 |
| TID | Thread ID within the process | 12346 |
| Tag | Message source (class/module) | MainActivity |
| Message | Log text or call stack | NullPointerException... |
Particular attention should be paid to the PID field. If an application crashes, its process is terminated and the PID is released. However, there may be “tails” from previous runs in the logs. Make sure that you analyze the logs of the exact process instance that crashed at the moment.
It is also worth noting that messages from different applications can be mixed in the general thread. Using the format threadtime helps you better navigate time by showing the date, time, PID, TID and log level in one line.
Analysis of PID and TID allows you to distinguish the logs of the main UI thread from background_worker_threads, which is critical when diagnosing interface freezes._
Finding causes of crashes (Crash)
The most common task when using Android Logcat is finding out the reason for the application crash (Crash). When an application closes abnormally, the system automatically generates an error report that is recorded in the log.
Look for lines starting with FATAL EXCEPTION. This is a marker of a non-fatal error that the application handler was unable to catch. Immediately after this line there is usually the name of the thread in which the error occurred and the type of exception, for example java.lang.NullPointerException or java.lang.OutOfMemoryError.
⚠️ Attention: If you see the message “Process killed” in the logs without an explicit exception, this may mean that the system killed the process due to lack of RAM (OOM Killer), and not due to an error in the code.
Below the line with the exception type is the call stack (Stack Trace). It shows the chain of methods that led to the error. The top line of the stack indicates the place where the exception directly occurred, and the bottom lines reveal the app execution path up to that point.
To simplify reading stack traces, you can use a tool adb bugreportthat collects complete dump information about the system, or specialized plugins for IDEs that automatically highlight lines of code in the project when you click on the log.
What to do if the call stack is truncated?
Sometimes the log buffer overflows and an important part of the stack is lost. In this case, increase the buffer size with adb logcat -G 4M to accommodate more data before overwriting it.
Advanced techniques and buffering
The Android logging system supports multiple independent buffers. By default adb logcat reads the main buffer (main), containing application logs. However, there are other buffers, such as radio (for telephony and network), events (for system events) and crash (only for crash reports).
Switching between buffers is carried out using the flag -b. For example, the command adb logcat -b radio will allow you to debug problems with communication and view modem logs. This is especially useful when diagnosing problems with SMS, calls or mobile data.
The size of the log buffer is limited, and old entries are overwritten by new ones. Long debugging sessions may require increasing this limit. The command adb logcat -g will show the current buffer size, and setting a new value helps preserve a longer history of events.
It is also possible to filter by the PID of a specific process. If you know the process ID of your application, the command adb logcat --pid=12345 will show only the logs of this process, ignoring the rest of the system. This significantly reduces the CPU load when reading logs and simplifies analysis.
How to filter logs only for a specific application package?
Use the command adb shell ps | grep com.example.appto find out the PID, and then pass it to logcat. Or use modern versions of Android Studio, which filter logs by the selected process automatically in the Logcat window.
Is it possible to view logs wirelessly?
Yes, if the device and computer are on the same Wi-Fi network. Run adb tcpip 5555 with the cable connected, disconnect the cable, find out the IP of the device and enter adb connect IP_ADDRESS:5555.
Why may logs be missing on some devices?
On some custom firmware or On cheap devices, access to logs can be limited by access rights or disabled by the manufacturer to save resources. In such cases, root access is required.
How to save logs to a file with timestamps?
Use the command adb logcat -v threadtime -d > my_logs.txt. The -d flag unloads the current buffer and exits, and -v threadtime adds detailed timing and information about threads.
What does the message "--------- beginning of crash" mean?
This is a separator in the log, indicating the beginning of a new report about a system or application crash. All lines after it relate to a specific crash incident.