Where are logs stored on Android and how to extract them

When your mobile device begins to behave unpredictably, freezes or suddenly reboots, the first step to solving the problem is to analyze the system logs. In the operating system Android all information about the operation of processes, application errors and kernel failures is recorded in special text files, which are collectively called logs. Understanding where this data is stored is critical for advanced users and developers.

However, access to these files is not always obvious. Unlike desktop operating systems, the file structure Android has strict access rights restrictions, especially in system partitions. A regular file manager without superuser rights will show you only a small part of the information, hiding the most important diagnostic data in protected directories.

In this article we will look in detail at the physical paths to event logs, methods for retrieving them through a computer, and the features of reading various types of logs. You will learn how it differs logcat from dmesg, and how to find the cause of a “bootloop” or unexpected power outage.

File system structure and access to logs

The Android file system is based on the kernel Linuxthat defines the logical structure of data storage. The root partition, denoted by /, contains all system files, but read and write access to it is denied by default to normal applications for security reasons. This means that you won’t be able to just go to the folder with logs through Explorer.

System logs are usually located in a virtual file system or special memory buffers, which do not always have a permanent physical representation on disk until they are saved. Key directories where log traces or saved copies may be found include /data/log, /data/tombstones and /data/anr. To access them, you need root access.

⚠️ Attention: An attempt to gain root access by unlocking the bootloader on many modern smartphones leads to irreversible activation of security flags (for example, Samsung Knox or Google SafetyNet), which can block the operation of banking applications and contactless payment services forever.

If you do not have superuser rights, the main way to interact with logs is to use the debugging interface ADB (Android Debug Bridge). This tool allows you to read the log buffer in real time and save it to your computer, bypassing the limitations of the file manager on the device itself.

Main types of system logs and their purpose

Not all The logs in Android are the same. The system separates event streams by type to make it easier to analyze specific problems. Understanding the difference between them will help you quickly find the information you need in a huge array of text data.

The main stream that developers work with is called logcat. It contains messages from all running applications, system services and drivers. Warnings, errors and debugging information are recorded here in real time. For analyzing failures of a specific application, this type of log is the most informative.

Another important type is dmesg (kernel diagnostic messages). This log stores information about hardware loading, driver operation, and low-level failures. If the phone does not turn on or reboots when the logo appears, the problem most often lies here.

• 📱 Main —the main buffer containing logs of applications and system processes.
• ⚙️ System —messages from system daemons and Android services.
• 💥 Crash —a specialized buffer for reporting application crashes.
• 📡 Radio —logs related to the operation of the radio module, calls and mobile data.

There are also radio module logs that are useful in diagnosing communication problems, signal loss or broken connections. They are recorded separately from the main stream and require specific commands for extraction via the terminal or ADB.

Extracting logs via ADB without root access

The most universal and safe method of obtaining diagnostic information is to use the utility ADB on a computer. This method does not require intervention in the smartphone system and works on the vast majority of devices with USB debugging enabled.

To get started, you need to install the package Android SDK Platform-Tools on your PC. After connecting the smartphone with a cable and confirming debugging on the device screen, you can run a command to output the contents of the main buffer to the console or save it to a file.

adb logcat -v time > android_log.txt

This command redirects the log stream with timestamps to a text file android_log.txt in the current directory on the computer. The process will continue until you interrupt it with the key combination Ctrl+C. This allows you to record the moment the error occurred by reproducing the problematic action on your phone.

If you are only interested in kernel logs, a similar operation is performed with the flag -d to dump the current state or by reading a special device. The command adb shell dmesg will output kernel messages directly to the terminal, which is convenient for quickly checking driver errors.

Direct access to log files with root access

Having superuser rights opens direct access to the file system, allowing copying system logs as regular files. This is especially useful when the device is in a state where ADB is not running, but a rooted file manager (for example Root Explorer or Mixplorer) is functioning.

Critical application crash reporting files (tombstones) are stored in the /data/tombstones/directory. Each file in this folder corresponds to a specific process that crashed. The contents of these files include a memory dump and a stack trace at the time of the crash.

Also worth paying attention to is the folder /data/anr/. The abbreviation ANR means Application Not Responding. If the application is frozen and the system prompts you to close it or wait, the corresponding report about the reason for the freeze will be saved here in the form of a text file.

File path	Data type	Root required	Purpose
/data/log/main.log	Text log	Yes	Main system event log
/data/tombstones/tombstone_0X	Memory dump	Yes	Native processes crash report
/data/anr/traces.txt	Trace	Yes	Causes of interface freezing (ANR)
/sys/fs/pstore/console-ramoops	Kernel log	Yes	Kernel messages after a hard reboot

For users looking for the reason for a sudden reboot (bootloop), the mechanism pstoreis especially interesting. If the system kernel is configured appropriately, it may save the last console messages to non-volatile memory before crashing. This data is available along the way /sys/fs/pstore/ and is the only chance to understand what happened in the last seconds before the system crashed.

What is kernel panic?

Kernel panic is an analogue of the “blue screen of death” in Windows, but for the Linux kernel. At this point, the system stops completely because a critical error has been detected that cannot be safely handled. Logs of this event are often lost if saving to pstore is not configured.

Analysis of the core dump and reasons for reboot

The most difficult category of problems is spontaneous device reboots. Unlike an application freezing, here the system loses control completely. Standard logcat in this case is often useless, since the buffer is cleared upon reboot.

To diagnose such cases, you need to look for files last_kmsg or console-ramoops. They contain kernel output (dmesg) from the run cycle preceding the crash. The presence of "Panic" or "Fatal Exception" entries in these files directly indicates a failure at the driver or hardware level.

A common cause of such failures is defective memory modules, processor overheating, or driver conflicts after a firmware update. Analyzing .hex dumps or text dumps from pstore requires deep knowledge of the architecture Linux, but even searching for keywords like "Unable to handle kernel" can provide direction for finding a solution.

⚠️ Attention: The files in the section /sys/ are virtual kernel interfaces. They can't just be copied like regular files on some versions of Android; often requires the use of the command cat in a terminal with output redirection.

If you find mentions of a watchdog timer in the logs, this means that some process blocked the system so much that the watchdog timer was forced to force a reboot of the device to restore functionality.

Tools for analysis and reading logs

Viewing raw text files of hundreds of megabytes can be difficult. For effective analysis, there are specialized utilities that can filter, highlight errors and visualize data.

One ​​of the standard tools is Android Studio with built-in Logcat. It allows you to connect to the device, select a specific process and apply complex filters by tags and message severity levels (Verbose, Debug, Info, Warn, Error). This is the best choice for developers.

For ordinary users who do not want to install gigabytes of software, lightweight applications from the Google Play store, such as MatLog or LogViewer, are suitable. They require root access, but provide a convenient interface for reading files tombstone and system logs directly on the smartphone screen.

• 🔍 Android Studio - a professional tool with powerful filters and a graphical interface.
• 📱 MatLog - an open application for viewing logs directly on the device (Root required).
• 💻 Grep —a console utility for searching for specific error lines in large log files.

When analyzing, pay attention to timestamps. Synchronizing the time between an event (for example, you pressed a button and the phone froze) and a log entry is the key to understanding cause and effect. Look for entries that precede the crash by 1-2 seconds.

Frequent mistakes when interpreting data

Beginners often make the mistake of trying to find one single line that will explain all the problems. In reality, a failure is (often) the result of a chain of events that began long before the system crash itself.

Another common problem is ignoring level warnings Warning. Many critical failures are preceded by a series of warnings about low memory, I/O failures, or service timeouts, which seem unimportant at first glance.

It is also worth considering that some manufacturers (for example, Xiaomi, Samsung, Huaweimodify standard log storage paths or encrypt them. In such cases, standard instructions may not work, and you will need to search for vendor-specific diagnostic tools.

Where can I find logs if the phone does not turn on?

If the device does not boot to the desktop, it is impossible to obtain logs via ADB. In this case, the only option is to try to boot into Recovery mode (if there is a console there) or use specialized repair boxes (for example, Octoplus or Chimera), which can read a memory dump directly through test points or boot modes (Download Mode/EDL).

Is it possible to send logs to the application developer?

Yes, this is the best way to help fix the error. Usually in the settings of the application itself there is an item “Submit a crash report”. If it is not there, you can save the output adb logcat to a file while reproducing the error and attach this file to a support email.

Are the logs deleted after a reboot?

Yes, the buffer logcat is cleared every time the device is rebooted. However, files tombstone, anr and kernel logs pstore are saved on disk and are available after turning on the phone, if the /data partition was not damaged.

Is it safe to publish logs on the Internet?

No, not completely. Logs may contain sensitive information: account names, MAC addresses, device IDs, and sometimes fragments of entered text. Before publishing, be sure to edit the file, removing personal data, or use anonymization tools.