Compatibility tier definitions
To ensure your app provides a great user experience on Android XR devices, please review the following compatibility checklists and tests.
The checklists and tests define a comprehensive set of quality requirements for most types of Android apps.
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 large screen app
An Android XR compatible large screen app represents a large screen Tier 1 or Tier 2 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. Android XR compatible large screen apps are automatically opted in and available on the Play Store.
An Android XR compatible large screen app runs full screen on a spatial panel in the user's environment at 1024dp × 720dp. Users will be able to interact with the app naturally using their eyes and hands, but will otherwise be very similar to the large screen app.
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 (e.g. spatial panels), adding XR content (e.g. 3D video) to your applications by developing with Android Jetpack XR SDK, Unity, or OpenXR.
You can use the Jetpack XR SDK to provide XR-specific capabilities including spatial panels, environments, 3D models, spatial audio, 3D / spatial video / photos, anchors, and 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 below.
All apps built with Unity or OpenXR are considered differentiated. Apps built with Unity or OpenXR must meet 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.
Android XR compatibility checklist
These compatibility checklists define criteria to help you assess the level of support your app provides for XR. Levels of support include the following:
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 large screen app
Any large screen Tier 1 or Tier 2 app is considered an Android XR compatible large screen app. The large screen 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. Similarly, Android XR does not include stylus support.
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 application. Android apps must also comply with Large screen / mobile Android guidelines. See the requirements that are appropriate for your application (some of these might turn into potential policy updates as well).
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 application. Avoid intentionally incorporating any design elements that may induce strobing. 1. If 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:
|
||
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 (formerly Guardian) |
If your app expects users to move from their starting point (at app launch) around their physical space, it either requests passthrough or declares If your app uses |
||
Performance |
Rendering |
Your app renders each frame between <11.1ms (90Hz), and < 13.8ms (72 Hz). |
|
Resolution |
Your app has a resolution of at least 2364 x 2880 per eye. |
||
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 developer 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 |
When multitasking (that is, completing two or more tasks at once) with panels, create separate spatial panels. For example, you would create separate spatial panels for chat windows and lists. |
||
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) |
||
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. |
||
Spatial Panels |
Place menus, assets, and controls in a dedicated panel or orbiter. Do not include these components in the main editing panel. |
||
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 letter boxing. |
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 back content in Full Space, your app allows users to either dim passthrough or select virtual environments. |