Logcat — What It Is, Logging Levels, and Working with Logs

What is Logcat in Android

Logcat is an Android system buffer where all processes (including the Linux kernel, system_server, and apps) write messages in a specific format. The logcat tool, included in the Android SDK, reads this buffer and displays messages in real time. Starting with Android 4.1 (API 16), Logcat access is restricted: apps can only read their own logs, and system logs are accessible via ADB with debug access.

Each Logcat message contains five fields: date and time, PID (process identifier), TID (thread identifier), log level, and tag. The format is fixed and identical across all Android versions. This allows using grep, awk, and sed utilities for log filtering in CI/CD pipelines without IDE dependency.

Logs are stored in a fixed-size ring buffer: 256 KB for main, 256 KB for system, and 256 KB for events (Android 5+). When the buffer overflows, old messages are deleted. Developers can change the buffer size via the PROP logcat.size property or in the device’s developer options.

Log Levels and Tags: Logcat Message Structure

Six levels of logging determine message importance. Android uses standard levels similar to other platforms but with its own constant names in the Log class. Choosing the right level helps efficiently filter logs and avoid drowning out critical messages with secondary ones.

Tags: Organizing Messages by Module

Tag — a string of up to 23 characters that identifies the message source. It is recommended to use the class or module name as the tag: MainActivity, AuthManager, NetworkModule. This allows filtering logs by a specific application component. For consistency within a team, you can create tag constants in a separate file or use the Timber library, which automatically inserts the tag based on the class name.

Crash Logs and Exception Stack Traces

When an unhandled exception occurs, Android automatically writes the full stack trace to Logcat, indicating the class, method, code line, and call chain. A crash log contains the exception type (NullPointerException, RuntimeException), message, and call sequence from the crash point to the app’s entry point. For analyzing crash logs from user devices, Firebase Crashlytics is used, which synchronizes the stack trace with the obfuscation map (mapping.txt for Android).

Logcat in Android Studio: Interface, Filters, and Search

Android Studio provides a graphical Logcat interface accessible via View → Tool Windows → Logcat (Alt + 6). The Logcat window updates in real time, shows all messages from the connected device, and allows configuring flexible filters to isolate the desired information from the general stream.

Filtering by Level and Tag

The Log Level dropdown filters messages by minimum level: select WARN to see only warnings and errors, hiding VERBOSE, DEBUG, and INFO. The Search field allows searching by message text or tag — regex is supported, which is convenient for finding messages by pattern.

Saved Filters

Saved Filters — a powerful Logcat feature in Android Studio. You can create a filter that shows only messages with your app’s tag (tag:MyApp) and level WARN+. Filters persist between sessions and are available from the dropdown list. For projects with multiple modules, create a separate filter for each module.

# Example of an expression for filtering application logs
tag:"MyApp" level:WARN # Only WARN+ for MyApp
package:"com.mycompany" # All package logs
-tag:"okhttp" # Exclude OkHttp logs

Export and Analysis

Logcat logs can be exported to a text file via the Save to File icon. This is useful for attaching to Jira tickets or analyzing long sessions. The exported log can be opened in any text editor and grep can be applied to search for patterns. For formatted viewing, use the logcat-color utility.

ADB logcat: Terminal Commands for Advanced Usage

ADB logcat is the console version of Logcat, accessible via Android Debug Bridge. Its main advantage is the ability to run on CI servers, in automation scripts, and on devices without Android Studio. ADB logcat supports all the same filters as the GUI, but with command-line flexibility.

Basic Commands

The adb logcat command without arguments outputs the entire buffer in real time. Use Ctrl+C to stop. The -c flag clears the buffer before starting recording — convenient when you need to isolate the current test’s logs from previous messages. The -b flag selects the buffer type: main, system, events, crash (Android 12+).

# Clear the buffer and start logging with the MyApp tag
adb logcat -c
adb logcat MyApp:D *:S

# Save logs to file
adb logcat -d > logcat_dump.txt

# Filter by process PID
adb logcat --pid=12345

Filtering with grep and awk

Combining ADB with Unix utilities provides maximum flexibility. For example, the filter "*:S TAG:D" shows only messages with the TAG tag at DEBUG level and above, hiding everything else. To view only exceptions, use grep -i exception. To analyze error frequency, apply sort | uniq -c on the tag column.

Logcat in CI/CD

On CI servers, Logcat is used to collect diagnostics during UI test runs. A typical pipeline: clear the buffer before running tests, save the log dump as a build artifact after test execution. If a test fails, the logs can determine whether the failure was caused by ANR, unhandled exception, or network timeout.

Logging in Code: Log.d, Log.e, and Timber

The android.util.Log class is the built-in API for writing messages to Logcat. Log.v, Log.d, Log.i, Log.w, Log.e, and Log.wtf accept a tag (string) and a message (string) or a message + Throwable. For formatting messages, use String.format or Kotlin String templates — avoid string concatenation, which creates unnecessary objects in the heap.

Timber Library

Timber is a popular library by Jake Wharton that addresses the shortcomings of the built-in Log API. Timber automatically inserts the tag based on the class name that called logging and does not require passing a tag in every call. Timber also supports conditional logging: in Release builds, Timber.v and Timber.d calls can be disabled with a single line in Application.onCreate.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Built-in Log API
        Log.d("MainActivity", "onCreate called")

        // Timber — automatic tag by class name
        Timber.d("onCreate called")
    }

    private fun loadData() {
        try {
            val result = fetchFromNetwork()
            Timber.i("Data loaded: $result")
        } catch (e: IOException) {
            Timber.e(e, "Failed to load data")
        }
    }
}

Conditional Logging for Release

In Release builds, it is recommended to disable VERBOSE and DEBUG logs to reduce Logcat buffer load and prevent sensitive information leaks. Timber solves this with PlantingTree: in the Debug flavor, DebugTree is planted (logs everything), in Release — CrashReportingTree (logs only ERROR via Crashlytics). The built-in Log API does not support conditional logging — developers need to wrap each call with if (BuildConfig.DEBUG).