This site has been archived and remains strictly as a historical reference for developers who actively maintain apps built using the legacy Google VR SDK, which was last updated in 2019 and is no longer receiving updates.
  • All developers actively developing experiences for Google Cardboard should use the new open source Cardboard SDKs for iOS, Android NDK, and Unity XR Plugin. These new SDKs offer streamlined APIs, improved device compatibility, and built-in viewer profile QR code scanning.
  • The Daydream View VR headset is no longer available for purchase as of October 15, 2019. Existing apps on supported devices are unaffected for users who previously installed those applications. It is no longer possible to opt-in to Daydream distribution via Google Play.

Daydream App Quality Requirements - Functionality

FN-S1: App uses a supported version of the Google VR SDK

You must use a supported version of the Google VR SDK for your application. Currently, this is version 1.10.0 or newer.

FN-S2: App uses Daydream API calls to transition between activities

For Daydream applications, transitions between activities are handled in a special way to ensure that head tracking is maintained throughout the transition. In general, VR activities are expected to avoid directly sending intents to begin subsequent activities, and instead should use the SDK methods provided in DaydreamApi to initiate transitions.

For example, to return to Daydream Home, call:

To launch another VR application, call:

or use one of the alternative methods for formatting and sending intents.

These methods display a smooth transition while maintaining head tracking and preserving head tracking state across activities, and should always be used for any activity transition from a VR activity. If you are launching a VR activity from a 2D UI, you must also use these methods.

FN-M1: App manifest does not request the NFC permission

NFC is used by the Daydream platform for viewer pairing, and cannot be used by applications.

FN-M2: App manifest sets correct VR activity styles

VR activities must:

  • Suppress Android’s default WindowManager transition animations.
  • Hide all system UI elements, including the action bar, navigation buttons, and keyboard.
  • Run in landscape orientation, and disallow orientation changes.
  • Disable multiwindow support.

The Google VR SDK includes the following theme, which disables WindowManager transition animations, the action bar, and title bar.


Additionally, activities that expect to be launched solely from the Daydream Home (most applications) or another VR activity should also include the following attribute to enable faster transitions:


Here is an example manifest for a VR activity that has been formatted to meet these requirements. See the Android manifest reference for additional reference.

    <activity android:name="<Your Activity Name Here>"

App manifest sets an intent type of ACTION_MAIN with category CATEGORY_DAYDREAM. For example:

    ... >
        <action android:name="android.intent.action.MAIN" />
        <category android:name=""/>

For Daydream activities that should not show up in VR Home (for instance because it is an internal activity and not a launch target), use android.intent.action.VIEW instead.

FN-M3: App manifest sets hardware features according to the platform(s) supported

Daydream apps use the following Android features:

  • android:glEsVersion="0x00020000"
  • android.hardware.sensor.gyroscope
  • android.hardware.sensor.accelerometer
  • android.hardware.vr.high_performance

Full Daydream apps must have all these features set to required. For apps that have a Cardboard mode or where VR use is optional, certain features can be set to not required.

Feature requirements

This table shows the appropriate value for the android:required attribute.

Feature Daydream Only Hybrid Daydream/Cardboard VR Optional
android:glEsVersion="0x00020000" true true false
android.hardware.sensor.gyroscope true true false
android.hardware.sensor.accelerometer true true false
android.hardware.vr.high_performance true false false true false false


Application only supports Daydream:

<uses-feature android:glEsVersion="0x00020000" android:required="true" />
<uses-feature android:name="android.hardware.sensor.accelerometer" android:required="true" />
<uses-feature android:name="android.hardware.sensor.gyroscope" android:required="true" />
<uses-feature android:name="android.hardware.vr.high_performance" android:required="true" />
<uses-feature android:name="" android:required="true" />

Application supports both Daydream and Cardboard devices:

<uses-feature android:glEsVersion="0x00020000" android:required="true" />
<uses-feature android:name="android.hardware.sensor.accelerometer" android:required="true" />
<uses-feature android:name="android.hardware.sensor.gyroscope" android:required="true" />
<uses-feature android:name="android.hardware.vr.high_performance" android:required="false" />
<uses-feature android:name="" android:required="false" />

Application's VR mode is optional:

<uses-feature android:glEsVersion="0x00020000" android:required="false" />
<uses-feature android:name="android.hardware.sensor.accelerometer" android:required="false" />
<uses-feature android:name="android.hardware.sensor.gyroscope" android:required="false" />
<uses-feature android:name="android.hardware.vr.high_performance" android:required="false" />
<uses-feature android:name="" android:required="false" />

FN-U1: App hides the status bar and navigation bar while in VR

Your app must not display Android’s system bars when the user is in VR.

For information about how to suppress the system status bar, see Hide the Status Bar on Android 4.1 and Higher.

For information about how to suppress the system navigation bar, see Hiding the Navigation Bar.

FN-A1: App pause behavior

When your app is paused, the user and app state should be handled in a reasonable way. The following Daydream events will cause Android to pause your application:

  • The Daydream Button on the controller is pressed, bringing up the Daydream Dashboard.
  • The user removes a standalone headset from their head, triggering the proximity sensor to inform that the headset is no longer in use.
  • The Home button on the phone's system bar is pressed (accessible if the user removes their phone from the viewer).
  • The user removes their phone from the viewer and taps the settings icon to access VR Settings.

When your app is paused:

  • The app must pause any audio and video playback.
  • The app should pause its render loop and stop submitting frames.
  • The app should preserve user or app state when leaving the foreground.
  • The app should prevent accidental data loss due to back-navigation or other state changes.

When returning to the foreground, the app should restore the preserved state and any significant stateful transaction that was pending, such as changes to editable fields, game progress, menus, videos, and other sections of the app or game. Apps may optionally choose to pause any live action, such as streaming media or game play, after the app resumes, to allow the user to get situated and ready before live action resumes. For example:

  • When the app is resumed from the Recents app switcher, the app returns the user to the exact state in which it was last used.
  • When the app is resumed after the device wakes from sleep (locked) state, the app returns the user to the exact state in which it was last used.
  • When the app is relaunched, the app restores the app state as closely as possible to the previous state.

FN-A2: App closes from VR correctly

Pressing the Close button or the Back button in the system bar (accessible if the user removes their phone from the viewer) should immediately pause the application, including any audio that was playing. User and app state should be handled in a reasonable way. The user should be taken to the 2D phone launcher.

If you are creating a hybrid application, and the user launched into VR from the hybrid application, then (and only then) the Close button or back button can optionally return the user to the 2D version of your application where they launched into VR.

FN-W1: WorldSense app declaration

6DoF-capable WorldSense head tracking apps must declare “Head tracking version 1” in their feature flags list at the top level of the app manifest.

Unity apps

  • Unity developers can configure whether their app supports positional headtracking using Player Settings > Android > XR Settings > Virtual Reality SDKs > Daydream > Positional headtracking.

    • Disabled means the app only supports 3DoF
    • Supported means the app supports both 3DoF and 6DoF
    • Required means the app only supports 6DoF

Java apps

Applications which work in both 3DoF mode and 6DoF mode must declare:

  android:required="false" />

Applications which rely on 6DoF tracking for core functionality and cannot not be used without 6DoF tracking must declare:

   android:required="true" />

If the application works only in 3DoF, the uses-feature tag must be omitted.