Android XR stable tools: check the version before the feature

Google’s November 6, 2026 Android XR developer update says core Jetpack XR libraries and Android Studio XR emulators are now stable. It also points developers to embedding Unity and Godot inside Jetpack Compose apps using OpenXR Spatial Containers. That gives our earlier standard-versus-device distinction a practical follow-up: check which software version a project actually uses before treating a platform milestone as an app feature.

The announcement date is not the library release date#

The SceneCore and XR Runtime release pages both date version 1.0.0 to October 21, 2026. November 6 is the date of Google’s broader developer post, not a new release date for those two stable versions. As checked November 7, the same pages show newer alpha versions in their dependency examples.

Our practical advice: read the release-channel label and the actual dependency declaration together. Copying a sample declaration from either page does not select the stable 1.0.0 release shown in its summary table. Conversely, a stable release existing does not mean that every API described elsewhere is included in it. Check the requirements of the feature you need and the compatibility of your chosen dependencies; this article is not a tested build configuration.

What this changes for readers and developers#

For someone deciding whether an XR app meets a need, the useful evidence remains an app-specific feature description and supported setup. Google’s tooling announcement is evidence about development tools. It is not, by itself, confirmation that an existing app gained spatial multitasking, or that two particular apps can run together in the mode you want.

Developers can make that distinction visible in a small release record: app build; device and OS/runtime build; library versions and channels; feature tested; and observed result. Add the test location when the experience depends on geographic positioning. Keep emulator checks and physical-device observations separate, so a successful layout check is not presented as a field test. These are our suggested reporting practices, not tests Choosense has performed.

Location matters because Google’s Geospatial guidance explicitly says the API is not available in all regions. It describes positioning that combines device sensors and GPS with Google’s Visual Positioning System, and directs developers to check coverage in their areas of interest. For a US reader considering a location-anchored experience, ask about the intended location and supported device rather than assuming a platform-wide announcement guarantees local coverage.

We have not verified a new US retail-device rollout or an app compatibility list from this announcement. The concrete advance reported here is the documented tooling status; whether a specific experience works for you still requires evidence at the app, device and, where relevant, location level.

Earlier OpenXR reporting — checked October 20, 2026#

The following is our October 20 reporting and proposed test plan. Its source checks and statements about then-unconfirmed device support refer to that date; the November update above does not turn those historical checks into current compatibility certification.

Khronos announced OpenXR spatial containers on October 19, 2026: a cross-platform API for system-managed XR content spaces. They can switch between bounded multitasking and immersive display modes. The specifications and sample are published; Khronos expects implementations during 2026. That is not confirmation that your headset has received a feature update.

Why the distinction matters#

For a buyer, the useful question is not simply whether a box says OpenXR. Ask whether the exact experience you want is supported by your device software and the app you intend to use. A standard can describe a capability without establishing that your particular setup delivers it.

The announcement names XR_EXT_spatial_container for container management and XR_EXT_spatial_container_self_rendering for rendering through OpenXR composition layers. Placement is system-controlled. A separate system-provided rendering path remains work in progress. These are API details, not a published U.S. compatibility chart.

Three pieces of evidence to request#

Khronos’ conformance list illustrates why the second check matters: it records OpenXR 1.0/1.1 entries for Quest 3, Quest 3S and Galaxy XR, with runtime/platform details. Those rows are not a spatial-container compatibility list. Our interpretation: use them to identify the scope of a conformance claim, then seek extension-specific evidence instead of upgrading the claim yourself.

For example, imagine wanting a 3D reference object beside a separate creative app. Before buying hardware for that workflow, write down both app names, the target headset and the feature you need from each. Ask for evidence of those apps working together in that mode. This is a hypothetical buying scenario, not a combination Choosense has tested or a claim that any named product supports it today.

What developers can check now#

The official sample source provides a concrete starting point: it logs available extensions plus the runtime name/version, and requests both spatial-container extensions when creating its OpenXR instance. We inspected the code, not a running build. Its publication is evidence of a development example, not of successful execution on a retail headset.

Our suggested validation record has five fields: headset model; OS/runtime version; app or sample revision; advertised extension names; and observed behavior. Keep a screenshot or log of the environment alongside the result. If you later change the runtime or app build, create a new result rather than silently carrying forward the old one.

Once a supported environment is documented, separate the checks. Does the app start? Can it enter the intended bounded mode? Can a second intended app coexist? Does selecting one direct input as expected? Does returning from immersive mode preserve the state you need? Record failures individually. This is a proposed test plan, not an assertion about the extensions’ complete normative requirements.

That separation helps avoid an unhelpful verdict such as “OpenXR multitasking does not work” when only one app pairing or one software version was examined. It also prevents a successful sample launch from being promoted into a claim about an entire app library. Performance, battery impact and usable workspace size need their own observations; we have not measured them.

What remains unconfirmed for U.S. readers#

We have not verified a device-specific U.S. rollout date, a supported-app list or a successful retail-device test. Do not make a purchase depend on an assumed update. If your existing setup already meets your needs, the useful next step is watching for concrete vendor and app release notes—not treating this standards milestone as a reason to replace it.

Check app compatibility by device, store edition and feature

Separate a product announcement from an available, supported setup

Topics: OpenXR · Android XR · Meta · PICO · Developer tools

XR glossary: understand the terminology →

Commercial disclosure: no paid placement or affiliate tracking is included in this article.