31.1 Logcat

Understanding Logcat

Logcat is the main logging system in Android and one of your most important tools when debugging apps. It collects and displays system messages, stack traces, and log output from your own code in real time. In Android Studio, the Logcat window lets you watch what your app is doing behind the scenes while it runs on an emulator or a real device.

When you learn to use Logcat effectively, you can quickly find crashes, warnings, and custom messages that you have written in your code. This saves a lot of time compared to guessing what went wrong from what you see on the screen.

Opening and Viewing Logcat in Android Studio

In Android Studio, Logcat is available as a tool window. You can open it from the bottom of the IDE by clicking the "Logcat" tab. If you do not see it, you can usually open it from the "View" menu by choosing "Tool Windows" and then "Logcat".

At the top of the Logcat window you choose which device and which app you want to see logs for. When you connect an emulator or a physical device and run your app, you select that device in the device dropdown, then select your app’s package from the application dropdown.

Below the dropdowns there is a text area that shows the log messages. New messages appear continuously while the device is running. You can scroll back to see older messages, and you can pause the stream if you want to inspect something carefully.

Log Levels and Their Meaning

Logcat categorizes messages by severity. Each message has a tag, a text message, and a level. The level shows how important or serious the message is.

Common log levels include:

Verbose is the lowest level and is used for very detailed information that is normally only useful when deeply debugging. Debug is used for information that is useful during development, such as variable values or steps in a process. Info is used for general information about app state that is interesting but not a sign of a problem. Warn is used when something unexpected happened, but the app can still continue to run. Error is used when something has gone wrong that usually affects functionality, such as an exception. Assert is rarely used in typical app logging and is meant for conditions that should never happen.

In the Logcat window there is usually a filter to choose which minimum log level you want to see. For example, if you select "Warn", you will see only warnings, errors, and asserts, but not verbose, debug, or info messages.

Writing Logs in Your Code

You can create your own log messages in Kotlin using the android.util.Log class. These messages show up in Logcat while your app is running. The basic pattern uses a tag string to identify where the message comes from and a message string to describe what happened.

A simple example looks like this:

import android.util.Log
class MainActivity : AppCompatActivity() {
    private val TAG = "MainActivity"
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        Log.d(TAG, "onCreate called")
    }
}

Here Log.d writes a debug level message with the tag MainActivity. The tag helps you identify which part of your code produced the log line.

The most common methods are:

Log.v(TAG, "Verbose message")
Log.d(TAG, "Debug message")
Log.i(TAG, "Info message")
Log.w(TAG, "Warning message")
Log.e(TAG, "Error message")

You can use variables in your messages to track values:

val userId = 42
Log.d(TAG, "Loading data for userId = $userId")

If an exception occurs and you catch it, you can include it in the log so Logcat shows the stack trace together with your message:

try {
    val result = riskyOperation()
    Log.i(TAG, "Operation succeeded: $result")
} catch (e: Exception) {
    Log.e(TAG, "Operation failed", e)
}

Choosing and Organizing Log Tags

The tag is a short string, often the class name, that lets you group and filter related messages. Tags are especially important in large apps or when Logcat shows logs from many sources.

A simple and common approach is to use a constant per class:

class LoginViewModel : ViewModel() {
    companion object {
        private const val TAG = "LoginViewModel"
    }
    fun login(username: String) {
        Log.d(TAG, "login called with username=$username")
    }
}

You can also create tags for functional areas, such as "Network", "Database", or "UI". This makes it easier to filter logs for a specific feature.

There is a maximum length for a tag string. If you try to use a very long tag, the system might shorten it or reject it, which can cause confusing behavior. Keeping tags short and clear is usually best, and class names are a good default.

Using Logcat Filters and Search

Logcat can easily become overwhelming because it displays logs from the Android system, other apps, and your app together. To make Logcat useful you must filter it.

In the Logcat window you can:

Select your app from the app filter so the list shows only messages from your package. Choose a minimum log level so you see only messages that match the severity you care about. Use the search box to filter messages by text or tag.

For example, if you use the tag "LoginViewModel", you can type that tag into the search field to see only messages related to login logic. If you often debug the same part of your app, you can save a named filter in some versions of Android Studio, so you can quickly switch to that view.

You can also filter by process id or use regular expressions in the search field, depending on the Android Studio version, but when starting out you usually only need app selection, level selection, and text search.

Reading Crash Logs and Stack Traces

When your app crashes, Android creates an error log with an exception and a stack trace. This stack trace is printed to Logcat. Learning how to read it is essential for finding the source of a crash.

A typical crash log contains the exception type, a message, and a list of method calls that shows where the error happened. The most important part is usually the first few lines with your package name.

For example, you may see something like this in Logcat:

E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.example.myapp, PID: 12345
    java.lang.NullPointerException: Attempt to invoke virtual method ...
        at com.example.myapp.ui.MainActivity.onCreate(MainActivity.kt:25)
        at android.app.Activity.performCreate(Activity.java:...)
        ...

Here the key information is:

The exception type is java.lang.NullPointerException. The cause message describes what went wrong, such as trying to call a method on a null object. The stack frame that points to your code is MainActivity.kt:25, which tells you that line 25 in MainActivity.kt triggered the problem.

In Android Studio you can often click on the file and line number in Logcat to jump directly to that line in your code. This makes it very fast to move from the crash log to the source.

When you see longer stack traces, focus first on lines that include your app package. System lines are helpful but are usually less important for fixing your code.

Practical Logcat Usage During Development

During normal development you can use Logcat to follow the flow of your app. For example, you can log when an activity enters lifecycle methods, when network requests start and finish, or when user input triggers important actions.

You might log high level steps with Log.i, debug details with Log.d, and unexpected situations with Log.w. Errors that should not happen, such as failures when saving important data, should use Log.e.

In problem scenarios, you can temporarily add more detailed logs. For example, if a part of the UI behaves strangely, you can log the values of variables at different points and see how they change.

There is a performance cost to logging, especially with heavy string building or logs in very tight loops. During development this is usually acceptable, but you generally avoid very noisy logging in production. You can also use conditions around logs if they are especially expensive to compute.

Cleaning Up and Managing Logs

As your project grows, it is easy to accumulate many log statements. This can clutter Logcat and make it harder to see what matters. Before you release your app you should review your logging.

You can remove logs that are no longer useful, reduce message detail for production, or use build configuration to include certain logs only in debug builds. Using a consistent naming style for tags makes it easier to search and decide what to keep.

If you need to share logs to debug problems on user devices, Logcat can be saved to a file using Android Studio or command line tools. In such cases you must still remember that logs can contain sensitive information if you were not careful in what you logged earlier.

When used with discipline, Logcat becomes a powerful window into the behavior of your app and the Android system. It is often the first place you should look when anything unexpected happens during development.