Write and view logs with Logcat

Stay organized with collections Save and categorize content based on your preferences.

The Logcat window in Android Studio displays system messages, such as when a garbage collection occurs, and messages that you added to your app with the Log class. Logcat displays messages in real time and keeps a history, so you can view older messages.

To display only the information of interest, you can create filters, modify how much information is displayed in messages, set priority levels, display messages produced by app code only, and search the log. By default, Logcat shows the log output related to the most recently run app only.

When an app throws an exception, Logcat shows a message, followed by the associated stack trace containing links to the line of code.

The Run window displays log messages for the current running app. You can configure the Logcat output display but not the Run window.

View your app logs

To display the log messages for an app:

  1. Build and run your app on a device.
  2. Click View > Tool Windows > Logcat, or click Logcat in the tool window bar.

The Logcat window shows the log messages for the app selected from the menu at the top of the window, as shown in figure 1.

Figure 1. The Logcat window.

By default, Logcat displays just the log messages for the app running on the device. To change this default, see how to filter logcat messages.

The Logcat toolbar provides the following buttons:

  1. Clear logcat : Click to clear the visible log.
  2. Scroll to the end : Click to jump to the bottom of the log and see the latest log messages. If you then click a line in the log, the view pauses scrolling at that point.
  3. Up the stack trace and Down the stack trace : Click to navigate up and down the stack traces in the log, selecting the previous or next filename that appears in the printed exceptions. This is the same behavior as when you click a filename in the log.
  4. Use soft wraps : Click to enable line wrapping and prevent horizontal scrolling. However, any unbreakable strings might still require horizontal scrolling.
  5. Print : Click to print the Logcat messages. After selecting your print preferences in the dialog that appears, you can also choose to save the messages as a PDF.
  6. Restart : Click to clear the log and restart Logcat. Unlike the Clear Logcat button, this recovers and displays previous log messages, so is most useful if Logcat becomes unresponsive and you don't want to lose your log messages.
  7. Logcat header : Click to open the Configure Logcat Header dialog, where you can customize the appearance of each Logcat message, such as whether to show the date and time.
  8. Screen capture : Click to capture a screenshot.
  9. Screen record : Click to record a video of the device for a maximum of 3 minutes.

Write log messages

The Log class lets you create log messages that appear in Logcat. Every Android log message has a tag and a priority associated with it. The tag of a system log message is a short string indicating the system component from which the message originates.

Use the following log methods, listed in order from the highest to lowest priority:

A user-defined tag can be any string that you find helpful, such as the name of the current class. You define the tag in a Log method call, for example:

Kotlin

Log.d(tag, message)

Java

Log.d(tag, message);

See the Log class description for a more complete list of options.

Never compile verbose logs into your app, except during development. Debug logs are compiled but stripped at runtime. Error, warning, and info logs are always kept.

For each log method, the first parameter should be a unique tag and the second parameter is the message. The tag of a system log message is a short string indicating the system component from which the message originates. Your tag can be any string that you find helpful, such as the name of the current class.

A good convention is to declare a TAG constant in your class to use in the first parameter. For example, you might create an information log message as follows:

Kotlin

private const val TAG = "MyActivity"
...
Log.i(TAG, "MyClass.getView() — get item number $position")

Java

private static final String TAG = "MyActivity";
...
Log.i(TAG, "MyClass.getView() — get item number " + position);

Note: Tag names greater than 23 characters are truncated in the Logcat output.

Logcat message format

The log message format is:

date time PID-TID/package
priority/tag: message

PID stands for "process identifier" and TID for "thread identifier." They can be the same if there’s only one thread.

For example, the following log message has a priority of V and a tag of AuthZen:

12-10 13:02:50.071 1901-4229/com.google.android.gms V/AuthZen: Handling delegate intent.

Set the log level

You can set the log level to control whether Logcat displays all messages or just the messages indicating the most severe conditions.

Logcat continues to collect all messages, regardless of the log level setting. The setting only determines what Logcat displays.

In the Log level menu, select one of the following values:

  • Verbose: Show all log messages (the default).
  • Debug: Show debug log messages that are useful during development only, as well as the message levels lower in this list.
  • Info: Show expected log messages for regular usage, as well as the message levels lower in this list.
  • Warn: Show possible issues that are not yet errors, as well as the message levels lower in this list.
  • Error: Show issues that have caused errors, as well as the message level lower in this list.
  • Assert: Show issues that the developer expects should never happen.

Search Logcat messages

To search the messages currently displayed in Logcat:

  1. (Optional) Select Regex if you want to use a regular expression search pattern.
  2. Type a character sequence in the search field .

    The Logcat output display changes accordingly.

  3. Press Enter to store the search string in the menu during this session.
  4. To repeat a search, choose it from the search menu. Select or deselect Regex as needed.

Filter Logcat messages

One way to reduce the log output to a manageable level is to restrict it by using a filter.

Note: The filter applies to your full Logcat history, not just those messages currently displayed in Logcat. Make sure your other display options are set appropriately so you can see the filter output you want to examine.

To define and apply a filter:

  1. In the filter menu, select a filter option:
    • Show only selected application: Display the messages produced by the app code only (the default). Logcat filters the log messages using the PID of the active app.
    • No Filters: Apply no filters. Logcat displays all log messages from the device, regardless of which process you selected.
    • Edit Filter Configuration: Create or modify a custom filter. For example, you could create a filter to view log messages from two apps at the same time.

    After you define filters, you can also select them in the menu. To remove them from the menu, delete them.

  2. If you selected Edit Filter Configuration, create or modify a filter:
    1. Specify the filter parameters in the Create New Logcat Filter dialog:
      • Filter Name: Enter the name of a filter you want to define or select an existing filter in the left pane to modify it. The name can contain lowercase characters, underscores, and digits only.
      • Log Tag: Optionally specify a tag.
      • Log Message: Optionally specify log message text.
      • Package Name: Optionally specify a package name.
      • PID: Optionally specify a process ID.
      • Log Level: Optionally select a log level.
      • Regex: Select this option to use regular expression syntax for that parameter.
    2. Click + to add the filter definition to the left pane.

      To remove a filter, select it in the left pane and click -.

    3. When you're finished, click OK.

If you don't see the log messages you want, select No filters and search for particular log messages.

Read garbage collection messages

Sometimes when a garbage collection (GC) event occurs, information is printed to Logcat.

For more detail about your app's memory, use the Memory Profiler.

Dalvik log messages

In Dalvik, but not ART, every GC prints the following information to Logcat:

D/dalvikvm(PID): GC_Reason Amount_freed,
Heap_stats, External_memory_stats, Pause_time

Example:

D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms

While log messages accumulate, look out for increases in the heap stats. If this value continues to increase, you might have a memory leak.

The following terms are included in Dalvik log messages:

GC Reason
What triggered the GC and the kind of collection. Reasons that might appear include:
GC_CONCURRENT
A concurrent GC that frees up memory as your heap begins to fill up.
GC_FOR_MALLOC
A GC caused because your app attempted to allocate memory when your heap was already full, so the system had to stop your app and reclaim memory.
GC_HPROF_DUMP_HEAP
A GC that occurs when you request to create an HPROF file to analyze your heap.
GC_EXPLICIT
An explicit GC, such as when you call gc(). However, avoid calling this method; instead, trust the GC to run when needed.
GC_EXTERNAL_ALLOC
A GC for externally allocated memory, such as the pixel data stored in native memory or NIO byte buffers. This happens only on API level 10 and lower. Newer versions allocate everything in the Dalvik heap.
Amount freed
The amount of memory reclaimed from this GC.
Heap stats
Percentage free of the heap and (number of live objects)/(total heap size).
External memory stats
Externally allocated memory on API level 10 and lower: (amount of allocated memory)/(limit at which collection will occur).
Pause time
Larger heaps have larger pause times. Concurrent pause times show two pauses: one at the beginning of the collection and another near the end.

ART log messages

Unlike Dalvik, ART doesn't log messages for GCs that were not explicitly requested. GC information is only printed when the GC is explicit or the GC pause exceeds 5ms or the GC duration exceeds 100ms. If the app is not in a pause-perceptible state, such as when the app is in the background, where the user cannot perceive a GC pause, then no GC information is printed except for explicit GCs.

ART includes the following information in its garbage collection log messages:

I/art: GC_Reason GC_Name Objects_freed(Size_freed) AllocSpace Objects,
    Large_objects_freed(Large_object_size_freed) Heap_stats LOS objects, Pause_time(s)

Example:

I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects,
    21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms

The following terms are included in ART log messages:

GC Reason
What triggered the GC and the kind of collection. Reasons that might appear include:
Concurrent
A concurrent GC that does not suspend app threads. This GC runs in a background thread and does not prevent allocations.
Alloc
A GC initiated because the app attempted to allocate memory when the heap was already full. In this case, the garbage collection occurred in the allocating thread.
Explicit
The garbage collection was explicitly requested by an app, for example, by calling System.gc() or Runtime.gc(). However, as with Dalvik, in ART the best practice is to trust the GC and avoid requesting explicit GCs, if possible. Explicit GCs are discouraged because they block the allocating thread and unnecessarily waste CPU cycles. Explicit GCs could also cause jank (stuttering, juddering, or halting in the app) if they cause other threads to get preempted.
NativeAlloc
A GC caused by native memory pressure from native allocations, such as bitmaps or RenderScript allocation objects.
CollectorTransition
A GC caused by a heap transition. This is caused by changing the GC strategy at runtime, such as when the app changes between pause-perceptible states. Collector transitions consist of copying all the objects from a free-list-backed space to a bump pointer space or vice versa.

This occurs only on low RAM devices running a version of Android lower than 8.0 when an app changes process states from a pause-perceptible state, such as when the app is in the foreground, where the user can perceive a GC pause, to a non-pause-perceptible state, or vice versa.

HomogeneousSpaceCompact
Homogeneous space compaction is free-list space to free-list space compaction, which usually occurs when an app is moved to a pause-imperceptible process state. The main reasons for doing this are reducing RAM usage and defragmenting the heap.
DisableMovingGc
This is not a GC reason, but a note that collection was blocked due to use of GetPrimitiveArrayCritical while concurrent heap compaction is occurring. In general, the use of GetPrimitiveArrayCritical is strongly discouraged due to its restrictions on moving collectors.
HeapTrim
This is not a GC reason, but a note that collection was blocked until a heap trim finished.
GC Name
ART has various GCs that run:
Concurrent mark sweep (CMS)
A whole heap collector that collects all spaces other than the image space.
Concurrent partial mark sweep
A mostly whole heap collector that collects all spaces other than the image and zygote spaces.
Concurrent sticky mark sweep
A generational collector that can only free objects allocated since the last GC. This garbage collection is run more often than a full or partial mark sweep since it is faster and has lower pauses.
Marksweep + semispace
A non-concurrent, copying GC used for heap transitions, as well as homogeneous space compaction, to defragment the heap.
Objects freed
The number of objects that were reclaimed from this GC from the non-large-object space.
Size freed
The number of bytes that were reclaimed from this GC from the non-large-object space.
Large objects freed
The number of objects in the large object space that were reclaimed from this garbage collection.
Large object size freed
The number of bytes in the large object space that were reclaimed from this garbage collection.
Heap stats
Percentage free and (number of live objects)/(total heap size).
Pause times
In general, pause times are proportional to the number of object references that were modified while the GC was running. Currently, the ART CMS GC only has one pause, near the end of the GC. The moving GCs have a long pause, which lasts for the majority of the GC duration.

If you are seeing a large amount of GC messages in Logcat, look for increases in the heap stats. If this value continues to increase and doesn't ever seem to get smaller, you could have a memory leak.

Alternatively, if you are seeing GCs that specify the "Alloc" reason, then you are already operating near your heap capacity and can expect out-of-memory exceptions in the near future.