The app quality guidelines for immersive experiences extend the foundational core app quality mobile standards.
These app quality guidelines and policies focus on spatial interactions and capabilities that are unique to the Android XR platform on XR headsets and wired XR glasses, as outlined in the compatibility tier definitions, the checklists, and the Android XR App Policies. Review these sections to verify that your app provides a great user experience on XR headsets and wired XR glasses.
Immersive experiences: compatibility tier definitions
Review the following compatibility tier definitions to understand the level of support that your app provides for immersive experiences on XR headsets and wired XR glasses.
Android XR compatible mobile app
An Android XR compatible mobile app represents an existing mobile app that has not been modified to adapt to a large screen or any other form factor. This type of app is automatically compatible with Android XR as long as it doesn't require any features that are unsupported, such as telephony. Users can complete critical task flows but with a less optimal user experience than an Android XR differentiated app.
This type of app runs full screen on a panel in the user's environment, but its layout might not be ideal at larger sizes. Apps that specify compact sizes in the manifest show up accordingly. The app doesn't run in compatibility mode and is therefore not letterboxed. The app has a functional experience of the core input modalities provided by Android XR (eye tracking + gesture or raycast hands) and basic support for external input devices, including keyboard, mouse, trackpad, and game controllers. It may or may not be capable of resizing.
Android XR compatible mobile apps are automatically opted in and available on the Google Play Store. An app that is not compatible because of unsupported feature requirements is not installable through the Play Store.
Android XR compatible adaptive app
An Android XR compatible adaptive app represents an app that has implemented layout optimizations for all screen sizes and device configurations (for example, large screens in addition to mobile), along with enhanced support for external input devices and multitasking. An app fulfills these requirements if it is either Tier 2 adaptive optimized or Tier 1 adaptive differentiated for desktop, tablets, or foldables.
Android XR compatible adaptive apps are automatically opted in and available on the Play Store.
Android XR differentiated app
An Android XR differentiated app has a user experience explicitly designed for XR and it implements features that are only offered on XR. You can take full advantage of Android XR capabilities and differentiate your app's experiences by adding XR features (such as spatial panels), adding XR content (such as 3D video) to your apps by developing with the Android Jetpack XR SDK, Unity, Godot, Unreal Engine, or OpenXR.
You can use the Jetpack XR SDK to provide XR-specific capabilities such as:
- Spatial panels
- Environments
- 3D models
- Spatial audio
- 3D or spatial video and photos
- Anchors
- Other spatial UI such as orbiters
To be considered an Android XR differentiated app, an app must implement at least one XR-specific feature or piece of XR-specific content. For certain use cases, more features and content requirements may exist. See details in the subsequent sections.
All apps built with Unity, Godot, Unreal Engine, or OpenXR are considered differentiated so long as they meet the quality metrics and minimum requirements to be considered an Android XR-differentiated app. For example, an app with low frame rate, crashes, or other negative user experiences would not qualify.
Help users discover your app in the Play Store with a badge
Android XR differentiated apps automatically get a "Made for XR" badge in the Play Store to help users discover high-quality XR experiences.
Immersive experiences: compatibility checklist
To verify that your app provides a great user experience on XR headsets and wired XR glasses, review the following compatibility checklists and tests.
These checklists and tests define a comprehensive set of quality requirements for most types of Android apps.
Android XR compatible mobile app
Your app must fulfill the core app quality requirements.
Your app should also adhere to all applicable accessibility guidelines for other form factors such as phones and tablets (for example, color contrast).
Android XR compatible adaptive app
Any app that is either Tier 2 adaptive optimized or Tier 1 adaptive differentiated for desktop, tablets, or foldables is also considered an Android XR compatible adaptive app. The adaptive app quality guidelines offer a structured approach to ensuring a great experience on Android XR, but device state considerations such as rotation or folding/unfolding are not required.
Android XR-differentiated app
Because Android XR-differentiated apps are highly differentiated, some of the listed capabilities are applicable only to specific types of apps. Choose the capabilities that are appropriate for your app. Android apps must also comply with adaptive app quality guidelines. See the requirements that are appropriate for your app.
You should also follow the guidance on designing XR-differentiated apps for the best possible user experience.
Type of app & use case |
Category |
Area |
Guidance |
|---|---|---|---|
General Baseline Requirement (Android & OpenXR) |
Privacy & Security |
Account sign-in (first time UX) |
If your app utilizes a login system, clearly present the user's login credentials (for example, their username credentials) after successful authentication. This fosters trust by confirming the active account. Furthermore, incorporate a readily accessible menu or settings page that allows users to view and manage their account information at any time. |
Safety and Comfort |
Strobing |
To ensure the safety and well-being of all users, it's crucial to minimize the risk of strobing effects within your app. Avoid intentionally incorporating any design elements that may induce strobing. 1. If a strobing effect is absolutely necessary, ensure the flashing rate is very low (below 3 flashes per second) and the flashing area is small and subtle. 2. Consider providing an ability to disable it through settings or preferences. 3. Display a clear warning message before any strobing occurs. |
|
Avoiding motion sickness |
Follow these guidelines to avoid causing motion sickness in users:
|
||
Dimmer |
Respect the user's established dimmer settings to prevent safety hazards. You may adjust the dimmer for an optimal experience for your app, but users can manually override at any time. |
||
Input |
Interaction targets size |
Interactable targets have a minimum size and a recommended size based on intended interaction distance:
When using the Jetpack XR SDK, we recommend a minimum size of 48 x 48dp, with a recommended 56 x 56dp or larger tap target size. |
|
XR Technical Functionality |
Hand input |
Your app supports natural hand input as a baseline interaction method for Android XR, including hand raycast requirements and gestural support for input primitives. Your app is playable or otherwise usable without the need for controllers, but can be augmented with the use of them if you choose to do so. |
|
Boundary |
If your app is primarily focused on the real-world ( If your app is primarily focused in a virtual world ( If your app uses XR Glasses: There is no boundary on XR glasses devices. |
||
Performance |
Rendering |
Your app renders each frame between <11.1ms (90Hz), and < 13.8ms (72 Hz). |
|
Resolution |
OpenXR & Engines: Query |
||
App startup time |
Users want to be able to interact with your app or game as quickly as possible. The definition of a good start-up or loading time varies by category, but as a general principle we recommend minimizing the time between launch and first interaction. See target durations below:
For more details, see App startup time. |
||
ANRs |
Your app does not crash or block the UI thread causing ANR ("Android Not Responding") errors. Your app has <1 ANR in 99.5% of daily sessions. Your app uses Google Play's pre-launch report to identify potential stability issues. After deployment, pay attention to the Android Vitals page in the Google Play console. |
||
Crash rate |
Do not consume excessive system resources impacting the rest of the system and other apps, keeping a ~1% crash rate. |
||
Android App Baseline (XR-differentiated) |
Visual & User Experience |
Basic XR |
Your app implements at least one XR-specific feature or piece of XR-specific content to enhance the user experience. This can include an orbiter, one or more spatial panels, environments, or 3D objects. |
Spatial panels |
|
||
Environments |
When showing a virtual environment, brightness can be distracting and fatiguing. Your app presents a safe tonal range with no spikes in brightness that conflict with UI or might cause user fatigue. UI is legible in all directions especially within the middle horizontal band of the user's gaze. (Detailed guidelines to be linked in the future) |
||
UI theme |
Default to or highly encourage using a dark theme; light theme apps will appear very bright, fail to integrate into the user's environment, and drain the battery faster. For XR glasses, always implement a dark theme as the system uses a dark theme by default. |
||
Transitioning between Home Space (HSM) and Full Space (FSM) |
When taking users to Full Space, your app has an entry point for users to quickly transition between Home Space and Full Space. Use an icon or label, and place the button in an easy-to-access location. |
||
Menu & list scrolling |
Your app updates scroll interactions (especially through carousels or vertical lists) to have physics or momentum. For example, scrolling incorporates momentum, causing content in carousels and lists to continue moving briefly after a user interaction before gradually coming to a stop (instead of stopping exactly when the user stops input). |
||
Video & Media Functionality |
Visual & User Experience |
Spatial player (Android only) |
Your app allows users to watch content in Full Space. Remove playback controls from an overlay on top of content and instead place it in a dedicated panel or orbiter. For panels with video playback, set the aspect ratio to remove letterboxing. |
Spatial audio |
Consider supporting spatial audio including panel-locked audio or surround sound. |
||
Simultaneous video viewing |
If your app supports multiple simultaneous video streams, the user interface makes the following information clear:
|
||
Environment |
When playing video content in Full Space, your app allows users to dim passthrough (or select virtual environments on supported devices). |
Android XR App Policies
All apps must comply with the requirements in the following policies to promote safe and respectful user experiences on immersive devices like XR headsets and wired XR glasses.
App safety
As a reminder, all apps distributed through Google Play must comply with all Google Play Developer Policies.
The following activities are strictly prohibited, and apps must not facilitate or promote these activities:
- Doxxing
- Facial recognition or biometric identification
- Surveillance
- Creation or dissemination of Non-Consensual Intimate Imagery (NCII)
The following bystander protections are required for all apps:
Camera safety
Apps that access the camera must respect bystander privacy and must comply with the following:
Prohibited interactions |
Description |
|---|---|
Real-time facial identification & doxxing |
Apps must not use camera sensors to run facial identification to surface bystander Personally Identifiable Information (PII). For example: names, home addresses, phone numbers, or their employer. |
Non-consensual intimate imagery (NCII) or illegal content generation |
Apps must not use camera sensors to facilitate the creation of non-consensual intimate imagery (NCII) or any illegal content generation (for example, CSAM). |
Audio safety
Apps utilizing the microphone array should respect bystander privacy and must comply with the following:
Prohibited interactions |
Description |
|---|---|
Persistent eavesdropping |
Apps must not maintain persistent, background audio recording or transcription when the wearer is not actively engaged with the app on a user-initiated task. |
Speech identification |
Apps must not use the microphone array to identify non-wearer voices or bystanders. |
LED behaviors
Apps must not do the following with respect to the device's user- and world-facing LEDs:
Prohibited interactions |
Description |
|---|---|
Programmatic suppression or modification |
Apps must not change, dim, or disable the system-enforced world-facing LED and user-facing LED behavior based on microphone and camera access. Apps must also not encourage or direct users to change, dim, or disable the LEDs' behavior. |
Bypassing thwart and tamper detection |
Apps must not bypass or interfere with, or encourage or direct users to do so, the device's thwart detection algorithms, which are designed to programmatically stop recording if the world-facing LED is physically covered or damaged. |
OpenXR™ and the OpenXR logo are trademarks owned by The Khronos Group Inc. and are registered as a trademark in China, the European Union, Japan and the United Kingdom.