If you want to build for Android XR, the practical answer is this: you have one native toolkit (the Jetpack XR SDK) and several full game engines (Unity 6, Godot, Unreal), all sitting on the OpenXR 1.1 standard — and the right pick depends on whether you are extending an existing Android app or shipping a full immersive experience. Google shipped the Android XR SDK Developer Preview in December 2024 and Developer Preview 2 in May 2025, so the tooling is new but real and already in active use.
This guide walks the SDKs and engines, shows how to start, and explains the one decision that shapes everything else: porting an existing Android app versus building native made-for-XR.
What SDKs and Engines Build Android XR Apps?
You are not locked into one stack. Android XR supports the OpenXR 1.1 standard, and the Jetpack XR SDK adds Jetpack Compose for XR, Material Design for XR, Jetpack SceneCore, and ARCore for Jetpack XR on top of it. So the native, Kotlin-first path and the game-engine path coexist, and both reach the same headset.
For the engine route, you can build Android XR apps with the Jetpack XR SDK, Unity 6 (XR Interaction Toolkit, AR Foundation, OpenXR Plugin), Godot, Unreal Engine, OpenXR, or WebXR. That is a deliberately wide door. Web teams can reach the device with WebXR, Android teams can stay in Jetpack, and 3D teams can stay in Unity — without leaving the tools they already know.
| Path | Best for | Core tools |
|---|---|---|
| Jetpack XR SDK | Android teams adding spatial UI | Compose for XR, Material Design for XR, SceneCore, ARCore for Jetpack XR |
| Unity 6 | Rich 3D, physics, custom shaders | XR Interaction Toolkit, AR Foundation, OpenXR Plugin |
| Godot / Unreal | Existing engine teams | OpenXR support |
| WebXR | Reach-first, no install | Browser-delivered XR |
The takeaway is that there is no single "correct" Android XR stack. The correct stack is the one closest to your existing codebase and the experience you are shipping.
How Do You Build a Native Android XR App?
The native path runs through the Jetpack XR SDK, which extends the Android tools your team likely already uses. It is built on the OpenXR 1.1 standard and adds Jetpack Compose for XR, Material Design for XR, Jetpack SceneCore, and ARCore for Jetpack XR. If you write Kotlin and Compose today, the conceptual leap is smaller than you might expect.
Spatial UI with Jetpack Compose for XR
Jetpack Compose for XR brings declarative UI into three dimensions. Instead of laying out flat screens, you arrange panels, volumes, and components in space, with Material Design for XR providing the building blocks. The mental model is familiar Compose, extended outward — which is exactly why an Android team can get a spatial UI on screen quickly.
3D content with Jetpack SceneCore
For 3D, SceneCore handles scene composition and asset loading. Jetpack SceneCore loads 3D models in glTF 2.0 format with animation and spatial audio support. Because glTF 2.0 is an engine-neutral, widely adopted format, existing assets from web, AR, or Unity pipelines usually transfer in without a separate conversion step. That keeps the content side of the project lighter than teams expect.
World tracking with ARCore for Jetpack XR
ARCore for Jetpack XR brings the tracking layer: understanding the room, anchoring content to the real world, and handling the spatial awareness that makes XR feel grounded. For teams who have shipped ARCore on phones, this is familiar territory mapped onto the headset.
Should You Port an Existing Android App or Build Native XR?
Start with the platform's most useful property: devices powered by Android XR run standard Android mobile apps alongside made-for-XR native apps. So an existing Android app can appear on the headset as a flat window with zero spatial engineering. That changes the build decision from "rewrite or skip" to "port now, go native later."
Porting is the low-risk first move. If you already have an Android app, getting it onto the device as a 2D window gives you presence on the platform before you commit a single hour to spatial design. It is a reach play, the same way WebAR is a reach play for the browser.
Building native made-for-XR is the depth move. You invest here when the value is genuinely spatial: 3D objects placed in the room, hand and gaze interaction, world anchoring, or a fully immersive environment. That work is where Compose for XR, SceneCore, and ARCore for Jetpack XR earn their keep — and where Unity 6 becomes compelling for heavier 3D.
In practice most teams sequence the two. Ship the ported app for immediate presence, learn what users actually do on the device, then invest in a made-for-XR experience where spatial computing measurably changes the product. The shared stack means the second step builds on the first rather than replacing it. For the platform background behind this app model, our explainer on what Android XR is covers the device and ecosystem in full.
How We Approach Android XR Development
Honest framing first: Android XR is new, and we have not shipped a named Android XR client project yet. What we have is the exact stack the platform is built on. We have delivered 50+ immersive projects since 2021 across Unity 6, ARCore, OpenXR, native Android, and Meta Quest — and Android XR sits directly on top of every one of those tools.
That overlap is the point. Android XR's engine options are Unity 6 with the XR Interaction Toolkit, AR Foundation, and the OpenXR Plugin — the same toolkit we use daily. Its native path leans on ARCore and Android engineering we have shipped for years. Its 3D format is glTF 2.0, which our content pipeline already produces. So when we say we are ready to build for Android XR, that is transferable capability, not a fresh learning curve.
Our approach mirrors the porting-versus-native decision above. We help teams get an existing Android app onto the device fast for presence, then scope the made-for-XR experience where spatial interaction actually adds value. If you want the device-specific picture, our guide to Samsung Galaxy XR development goes deeper on the first hardware, and our Android XR development service is where a tailored build conversation starts.
How Do You Start Building for Android XR Today?
Pick your lane before you pick your tools. The Android XR SDK reached Developer Preview in December 2024 and Developer Preview 2 in May 2025, so the tooling is current and worth setting up now rather than waiting.
A pragmatic sequence looks like this:
- Confirm the experience. Flat Android app for reach, or made-for-XR for spatial depth? This decides everything downstream.
- Match the engine to your team. Android and Compose skills point to the Jetpack XR SDK. Heavy 3D and existing Unity work point to Unity 6. Web reach points to WebXR.
- Reuse what you have. glTF 2.0 assets, ARCore tracking logic, and existing Android code transfer in, so audit your current pipeline before building anything new.
- Ship the ported app first. Get presence on the device, then layer in spatial UI, 3D, and immersive modes as a roadmap.
Android XR is unusually approachable for one reason: it is built on standards and engines that immersive teams already use. OpenXR, Unity 6, ARCore, glTF, and Jetpack are not new skills to acquire — they are the skills the platform was designed around. Choose the path that matches your codebase, port for reach, build native where spatial value is real, and the platform becomes an extension of work you may already be doing rather than a separate bet.