The site has a new content architecture. We've added the ability to select your development device to show device-specific content. Please read our blog post Oculus Developer Center Update: Device-centric Documentation Architecture for more information.
All Oculus Quest developers MUST PASS the concept review prior to gaining publishing access to the Quest Store and additional resources. Submit a concept document for review as early in your Quest application development cycle as possible. For additional information and context, please see Submitting Your App to the Oculus Quest Store.
The Android SDK includes the logcat logging utility, which is essential for determining what an application and the Android OS are doing.
See Basic Performance Stats through Logcat for information on interpreting VrApi logs.
To use logcat, connect the Android device via USB or Wi-Fi, launch an OS shell, and type:
If the device is connected and detected, the log will immediately begin outputting 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 “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
For information on interpreting VrApi performance statistics returned by logcat, see Logcat for Basic Performance Stats.
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 as elapsed and the log does not show the backtrace, a full dump state of the crash should still exist. Use the following command to redirect the entire dump state to a file:
adb shell dumpstate > dumpstate.log
Copying the full dump state to a log file usually takes significantly longer than simply capturing the currently buffered logcat log, but it can provide additional information about the crash.
The backtrace in a logcat capture or dump state 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 or dump state for more detailed information about the state of the stack. To use
ndk-stack, issue the following:
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