Collect VrApi Logs with Logcat

The Logcat logging utility is a command-line tool included with the Android SDK that is used to display OS and application log messages. During development, Logcat is essential for determining what an app and the Android OS are doing while the app is running on a device.


Logcat can be used while an app is running on an Oculus mobile device to display logged messages from the app and the Android OS. Android-related messages include system messages, such as stack traces thrown on errors. Messages related to Oculus apps, which are tagged with VrApi, provide information on app performance every second. This information can be used to identify performance problem areas and to determine crash causes. Logcat can also be used to retrieve logs from apps that have recently crashed in order to potentially identify causes.

Advantages of Logcat include its familiarity to Android developers, low overhead, and engine agnosticism. While it provides only basic information, Logcat is useful as a tool for general triage on Oculus mobile apps.

Collect Oculus VrApi Logs with Logcat

The following sections describe how to set up Logcat, collect Oculus VrApi logs from an app running on a device, and possibly view logs from crashes that occurred while Logcat was not in use.

Basic Usage

To use Logcat, launch an OS shell, establish an ADB connection with the Oculus mobile device via USB or Wi-Fi, and enter the following command:

adb logcat

If the device is connected and detected, the output logs will immediately begin displaying to the shell. In most cases, this raw output is too verbose to be useful. Logcat solves this by supporting filtering by tags. To see only a specific tag, use:

adb logcat -s <tag>

This example will show only output with the Oculus VrApi tag:

adb logcat -s VrApi

In the native VrAppFramework code, messages can generally be printed using the LOG() macro. In most source files this is defined to pass a tag specific to that file. Log.h defines a few additional logging macros, but all resolve to calling __android_log_print().

See OVR Metrics Tool and VrApi Stats Guide for information on interpreting logcat VrApi logs.

Using Logcat to Determine the Cause of a Crash

Logcat will not necessarily be running when an application crashes. Fortunately, it keeps a buffer of recent output, and in many cases a command can be issued to Logcat immediately after a crash to capture the log that includes the backtrace for the crash:

adb logcat > crash.log

Simply issue the above command, give the shell a moment to copy the buffered output to the log file, and then end ADB (Ctrl+C in a Windows command prompt or macOS terminal prompt). Then search the log for “backtrace:” to locate the stack trace beginning with the crash.

If too much time has elapsed and the log does not show the backtrace, you can use the bugreport command to get a .zip file that contains logs, tombstones, and other data to help analyze crashes:

adb bugreport

The file will be placed in the user’s current directory. If no output file name is specified, the date is used for the file name.

Getting a Better Stack Trace

The backtrace in a Logcat capture generally shows the function where the crash occurred, but does not provide line numbering. To get more information about a crash, the Android Native Development Kit (NDK) must be installed. When the NDK is installed, the ndk-stack utility can be used to parse the Logcat log state for more detailed information about the state of the stack. To use ndk-stack, issue the following command:

ndk-stack -sym <path to symbol file> -dump <source log file> > stack.log

For example, this command uses the symbol information for Oculus 360 Photos to output a more detailed stack trace to a file named stack.log, using the backtrace found in crash.log.:

ndk-stack -sym VrNative\Oculus360Photos\obj\local\armeabi-v7a -dump crash.log > stack.log