The system Android continuously records a huge amount of information about its work in the background. These records, known as logs or logs, contain detailed data about running processes, application errors, network connections and system events. For the average user, these files often remain invisible, but for a developer or diagnostic specialist they are a critical tool to identify the causes of failures.

Understanding where this data is physically stored is necessary not only when debugging your own applications, but also when analyzing the causes of sudden reboots or freezes interface. The Android file system is based on Linux, which defines a strict hierarchy for storing service data. Access to them is limited by security rights by default, but there are proven methods for retrieving them.

In this article we will take a detailed look at the logging structure in the mobile operating system, consider the main types of logs and provide specific paths to the files. You will learn how to access logcat, radio and other important sections using both standard debugging tools and advanced methods with superuser rights.

Logging structure in the Android operating system

The logging architecture in Android is based on a daemon logdthat manages log buffers. Unlike desktop operating systems, where logs are often text files growing on disk, in Android they are stored in ring buffers in RAM. This is done to increase the performance and durability of the device’s flash memory.

There are several main buffers, each of which is responsible for its own segment of system operation. The main one is the buffer main, where most events of user applications and system services are recorded. There are separate buffers for the radio module (radio), kernel events (kernel) and Bluetooth events (bluetooth).

It is important to understand that these buffers have a limited size. When the amount of new data exceeds the allocated space, the oldest entries are automatically overwritten. That is why, to save history, it is necessary to periodically export the contents of the buffers to an external storage.

⚠️ Attention: Log buffers are cleared every time the device is completely rebooted (hard reboot). If your phone goes into a bootloop, collecting logs is only possible through Recovery mode or using tools like adb bugreport until the system completely shuts down.

It is critical for developers to distinguish between log priority levels: Verbose, Debug, Info, Warn, Error and Assert. Filtering by these levels allows you to cut out information noise and focus on real errors that cause application crashes.

Main types of system logs and their purpose

When diagnosing problems, it is important to know what type of log contains the information you need. The Android system generates different types of logs, and searching for "where are the logs" often depends on what specific problem you are trying to solve.

The most commonly used tool is logcat. It provides a real-time stream of system messages. It is in it that developers look for stack traces of fallen applications (Force Close) and framework errors. However, for analyzing problems with mobile communications, SMS or calls, logcat may not be informative enough.

In such cases, a buffer is used radio. It contains low-level data exchanged between the modem and the base station. Here you can find information about lost packets, signal levels and reasons for connection loss. The kernel log (dmesg or buffer kernel), which records the interaction of drivers with hardware, deserves special attention.

Below is a table systematizing the main types of logs and their purpose:

Buffer type Command access Main purpose
main adb logcat -b main Applications, UI, system services
radio adb logcat -b radio Telephony, SMS, mobile data
events adb logcat -b events System events (charging, buttons)
kernel adb logcat -b kernel Drivers, hardware
crash adb logcat -b crash Reports on crashes of native processes

Using the correct buffer saves analysis time. For example, searching for the reason why Wi-Fi does not work in the buffer may be ineffective if the Wi-Fi driver writes its errors directly to a special buffer. What type of logs do you look for most often? main may be ineffective if the Wi-Fi driver writes its errors directly to kernel or special buffer wifi.

📊 What type of logs do you look for most often?
main (Applications)
radio (Communication)
kernel (Hardware)
crash (Errors)
I don’t know

Location of log files in the file system

Question “where are Android logs" has two answers: in RAM (buffers) and on disk (saved reports). Standard paths to files on disk depend on the device manufacturer and Android version, but the general structure remains unchanged.

The main storage for error reports is the directory /data/log/. However, access to the section /data is closed to regular applications and users without superuser rights (Root). If you have root access, you can use a file manager like Root Explorer or MT Manager to directly view the content.

For devices without Root access, the system provides alternative paths. Often crash logs (tombstones) and reports bugreport are saved to internal memory accessible to the user. You should look for them along the following paths:

  • 📁 /sdcard/Android/data/ — logs of specific applications.
  • 📁 /sdcard/bugreports/ — complete system reports created via ADB.
  • 📁 /sdcard/Android/log/ —sometimes used by vendors for storing logs.
  • 📁 /data/tombstones/ —memory dumps of fallen processes (requires Root).

Some manufacturers, such as Samsung or Xiaomimay use proprietary logging mechanisms. For example, on Samsung devices with the One UI shell, logs can be collected through the built-in application Logger or hidden menu *#9900#, and then saved to a folder /sdcard/log.

⚠️ Attention: Interfaces and file paths may vary depending on the version of Android and the manufacturer's skin. If you do not find the file in the specified path, use the search by extension .log or .txt in the root of the internal memory.

Even after gaining access to the file system, you can only see encrypted data without the corresponding decryption keys, which are stored in a protected area processor.

Access to logs via Android Debug Bridge (ADB)

The most professional and universal way to obtain logs is to use the toolkit ADB (Android Debug Bridge). This method does not require root access and works on most devices if USB debugging is enabled.

To get started, you need to install the package Platform Tools to your computer and connect your smartphone with a cable. After confirming the connection on the phone screen (the “Always allow from this computer” flag), you can interact with the device via the command line.

The basic command for outputting logs in real time looks like this:

adb logcat

However, the output of “raw” logcat is often too voluminous. Keys are used to filter and save logs. For example, to save 1000 lines of logs to a file on your computer, use:

adb logcat -d -t 1000 > my_logs.txt

Here the flag -d means “dump” (unload and complete), and -t limit the number of lines. To obtain a complete system report, including logs, a list of processes, settings and information about the hardware, use the command:

adb bugreport C:\path\to\save\report.zip

This command will create an archive containing text files with all aspects of the system's operation. This is the “gold standard” for reporting an error to developers.

☑️ Preparing to collect logs via ADB

Done: 0 / 4

Using root access for deep analysis

Having superuser rights (Root) radically expands logging capabilities. With Root access, you get full control over the partition /data and can read files that are normally hidden from the user's eyes and even from most applications.

One ​​of the main advantages of Root is the ability to read kernel logs in real time through a pseudo file /proc/last_kmsg or /sys/fs/pstore/console-ramoops. These files contain information about the last seconds before a “dead” freeze or reboot, when the usual logging system no longer worked.

To work with logs on Root devices, terminal emulators are often used, such as Termux or Terminal Emulator. By running a shell with root access (command su), you can use standard Linux utilities: grep to search, tail to view the end of the file and cat to display the contents.

An example command for monitoring kernel errors in real time:

su

dmesg | grep -i error

Root also allows you to use specialized modules Xposed or LSPosedthat can intercept and log system calls, method parameters and return values, which is not available by standard means.

What is Tombstone?

Tombstone is a file created by Android when a native process crashes. It contains a memory dump, processor registers and call stack at the time of the crash. Analysis of tombstone is the only way to understand the reason for the decline of C++ libraries.

Specifics of logging on devices from different manufacturers

Although Android is an open system, each major vendor makes its own changes to the logging mechanisms. This is due to the desire to improve diagnostics or, conversely, hide certain information.

On devices Samsung the use of the hidden menu *#9900# (SysDump) is popular. There you can select the “Copy to sdcard” option to save logs. Samsung also uses its own report format, which sometimes requires special utilities for unpacking.

Smartphones Xiaomi (MIUI/HyperOS) have a built-in “Services & feedback” application. It is through it that it is most convenient to collect logs by selecting a specific category of the problem. The system itself will generate a report and offer to save it or send it to developers.

Devices OnePlus and Oppo often use the command *#800# to enter the engineering menu, where there is also a “Log & Report” section. There you can enable logging, reproduce the error, and disable logging. The files will be saved in the internal memory.

It is worth considering that on some devices with highly customized shells, standard ADB paths may not work correctly without additional authorization flags. In such cases, reconnecting the cable or restarting the ADB daemon with the command adb kill-server and adb start-server.

💡

uses the adb logcat -s TAG command to filter logs by a specific tag. This drastically reduces the amount of data and allows you to focus only on the desired application.

Analysis and cleaning of logs: practical tips

After you have found the logs, they need to be analyzed correctly. Reading thousands of lines of text by hand is inefficient. Use text editors with regular expression support (Notepad++, VS Code) or specialized analyzers, such as MatLog (for Android) or Pidcat (for command line).

When analyzing, look for keywords: FATAL, Exception, Crash, ANR (Application Not Responding). The time the error occurred (timestamp) is your main guideline. Compare the time of the crash on the screen with the time it was written in the log.

Cleaning up logs is also important for performance. Although the buffers are ring buffers, filling the partition /data with stored error reports can result in running out of space. To clean, use the command:

adb logcat -c

Or through the developer menu on the device itself, find the “Clear logs” item. Regular cleaning is not required for the system to operate, but is useful before starting a new debugging session so that old data does not interfere with the analysis.

⚠️ Attention: Logs may contain confidential information: passwords, authorization tokens, geolocation, activity history. Never publish full log files to open sources without first sanitizing (removing sensitive data).

Remember that constantly writing logs (especially in Verbose mode) can consume processor resources and increase battery drain. During normal use, keep the logging level to a minimum or use the default system settings.

💡

The main source of logs for the user is ADB and the /sdcard/bugreports folder, and for deep diagnostics with Root - the /data/log/ section and dmesg commands.

Frequently asked questions (FAQ)

Where to find logs for a specific application without root access?

Without root access, you will not be able to see logs of other applications in system buffers for security reasons. However, many applications have a built-in log export function in the settings (“About” or “Diagnostics”). You can also use adb logcat --pid=$(adb shell pidof -s com.package.name)if the application is running, but this will require connecting to a PC.

Can I delete log files to free up space?

Yes, log files saved in the internal memory (for example, in folders log, bugreports, tombstones) can be safely deleted. They take up space and are not needed by the system for current operation. However, there is no need to manually delete system buffers in RAM - they are cleared automatically.

Why does the adb logcat command return an empty result?

This can happen for several reasons: 1) Logging is disabled on the device in the developer settings (the “Logging” item); 2) The buffer was full and old records were erased before you connected; 3) You are filtering by a tag that is not in the current stream. Try running the command adb logcat -c (clean) and reproduce the error again.

How to read the logs if the phone does not turn on (Bootloop)?

If the phone does not boot into the system, standard ADB may not work. In this case, try entering Recovery mode (button combination when turned on). Some custom recovery (TWRP) allows you to connect via ADB. You can also extract the file /data/system/dropbox or /data/log via the recovery file manager, copy it to a PC and analyze it.

Is it safe to send logs to the developer?

It is safe to send logs if you trust the recipient (official support, well-known developer). However, personal data (names of Wi-Fi networks, file names, sometimes tokens) may accidentally remain in the logs. Before sending, it is advisable to review the file and remove obvious personal data, or use the “Anonymize” function in some reporting tools.