--- title: Android XR (preview) seoTitle: Android XR smart glasses SDK — Extentos support status description: "Android XR support in Extentos: the projected transport is built and proven on the Android XR emulator, the module is deliberately unpublished while the platform is in developer preview, and no Android XR glasses are buyable yet. What you can test today, and what you can't." type: reference platform: android vendor: android-xr related: - /docs/vendors - /docs/vendors/meta - /docs/ecosystem/platforms/android-xr - /docs/concepts/transport-vs-app - /docs/concepts/capabilities - /docs/concepts/architecture --- Android XR is the second vendor Extentos targets. The distinction that matters: **the transport is built, and the hardware does not exist yet.** Google ships the Android XR SDK and emulator in developer preview, no Android XR glasses are on sale, and Extentos deliberately does not publish its Android XR module while that remains true. This page is the honest status — what runs today, what is deliberately withheld, and what you can actually test right now. ## TL;DR - **Built and proven**: the projected transport (`:glasses-xr`), the vendor registry seam, and end-to-end connection on the Android XR emulator. - **Deliberately unpublished**: the `:glasses-xr` module is not on Maven Central. You cannot add it to an app today. - **No hardware**: no Android XR glasses are buyable. Audio-first devices are the expected first wave. - **Testable today**: you can mint a simulator session with an Android XR device identity and check how your app behaves under it — without any Android XR dependency. - **Meta is unaffected**: Android XR support costs Meta-only apps nothing, by design. See [dependency isolation](#vendor-support-is-opt-in) below. ## Extentos support The same eleven rows appear on every vendor page, in the same order, so vendors can be compared directly rather than by reading three differently-shaped tables. Depth specific to this vendor follows below. | | State | Detail | |---|---|---| | **Hardware you can buy** | ⛔ None | No Android XR glasses are purchasable. Google committed on the record to audio glasses "this fall" (2026), display glasses later. | | **Distribution** | ⛔ No channel | There is **no public distribution channel for this device class at all**. Play distribution today covers XR headsets and wired XR glasses, explicitly not audio or display glasses. Extentos's `:glasses-xr` is unpublished too, so there would be nothing to depend on even if a channel opened tomorrow. | | **Transport** | ✅ Built, Android only | `:glasses-xr` over Google's projected-activity model. Android-only **structurally** — a projected activity *is* an Android activity — so the missing iOS half is not drift. | | **Published** | ⛔ Withheld | Deliberately not on Maven Central: it carries alpha `androidx.xr` dependencies that Meta-only consumers must never inherit. | | **Verified on hardware** | ⛔ None | Proven end to end on Google's emulator instead, which is the strongest claim available while no device exists. | | **Camera** | ⛔ Refused | The device reports a camera and the simulator surfaces it, but the projected transport returns a typed refusal for capture. | | **Display** | ✅ Built | Renders through Google's Glimmer toolkit on Display Glasses — a 450x394 panel driven by the temple touchpad. Emulator-rendered, not hardware-verified. | | **Microphone** | ✅ Emulator-proven | Works end to end, including real per-virtual-device consent. | | **Speaker** | ✅ Emulator-proven | Raw PCM reaches the glasses over A2DP from the projected context. | | **Simulator** | ✅ Both devices | Audio and Display identities are both mintable. | | **Integration** | 🟡 One dependency | `generateConnectionModule` **refuses** a non-Meta vendor rather than emitting something wrong. Scaffold with `glasses: "meta"` for the shared bootstrap, then add `:glasses-xr` — it self-registers through `androidx.startup`, so no code line is needed. (`ExtentosXr.register()` remains public and idempotent for manual control.) Handler code is unaffected. | ## What you can do today You can test how your app behaves when the connected device reports as Android XR, without adding any Android XR dependency, because the simulator carries the device identity independently of the transport. Ask your agent to mint a simulator session targeting Android XR, then run your app against it as usual. Your handler code does not change — that is the point of the capability model. What changes is the device identity your app sees, and therefore which capabilities report as available. Two Android XR devices exist in the device registry: - **Android XR Audio Glasses** — supported. Camera, microphone and speaker. - **Android XR Display Glasses** — supported. Everything above plus the display. Your `glasses.display.show { … }` tree renders through Google's Glimmer toolkit, and the simulator draws the real panel: 450x394, not Meta Ray-Ban Display's square. The wearer drives it with the temple touchpad rather than a wristband, which is a different gesture for the same three actions. ## What you cannot do today - **Ship an Android XR app.** The module is unpublished; there is no version to depend on. - **Run on real hardware.** None exists to run on. - **Rely on any of this being final.** Preview platform, alpha dependencies, no hardware verification. ## Vendor support is opt-in A second vendor should cost nothing to developers who do not use it. In Extentos that is enforced structurally rather than promised. `:glasses-xr` is **not a dependency of `:glasses-core`**. It carries alpha `androidx.xr.projected` libraries, and a Meta-only app never inherits them. A vendor module plugs itself in with a single line in the host app, before the SDK is created: ```kotlin // Adding the :glasses-xr dependency is the whole integration — it self-registers. // ExtentosXr.register() is still available if you removed the startup entry. val glasses = ExtentosGlasses.create( ExtentosConfig(applicationContext = applicationContext) ) ``` With no registration the vendor registry is empty and transport resolution behaves exactly as it did before the registry existed — a release build that never calls `register()` cannot resolve an Android XR transport at all. Opting in is a deliberate act; opting out is the default and costs nothing. This is also why adding vendors does not gradually degrade the SDK for everyone: each vendor's dependencies stay inside that vendor's module. ## Building for the Android XR display The display surface is real code on this vendor: your `glasses.display.show { … }` tree is translated to **Glimmer**, Google's display toolkit, and rendered by a projected activity the SDK ships. You write the same tree you write for Meta. Five things are worth knowing before you build against it. **One manifest entry, and the SDK owns the activity.** A projected app *is* an Android activity, so something has to be running on the glasses before anything can appear. Rather than making you write it, the SDK ships that activity — you declare it once: ```xml ``` Without that entry a display show is a logged no-op. Nothing crashes, and nothing appears. **Design for the smaller panel.** Android XR display glasses are 450x394; Meta Ray-Ban Display is 600x600. Neither scrolls an over-tall tree — it clips. A layout that fits 450x394 fits both. The simulator draws each device's real panel, so you can see it rather than guess. **Stay inside the shared icon set.** `icon(name)` resolves against Meta's 116-glyph enum on one vendor and a set of shared concepts on the other (`check`, `close`, `place`, `search`, `settings`, `person`, `phone`, `star`, `play`, `arrow_back`, and about twenty more). A name a vendor doesn't know renders nothing rather than a wrong glyph — the same degradation on both, so an unmapped name is a silent gap, not a crash. **Images need a reachable URL, and the phone fetches them.** That is already true on Meta, where the glasses fetch; here the phone does, because the phone is what renders. Locally-captured photos and clips are handled for you — the SDK uploads them and rewrites the node to the hosted copy. Your app needs the `INTERNET` permission it almost certainly already has. **Read `isAvailable` when you need it.** On Android XR the SDK asks the connected device whether it has a screen and reports `false` until the answer arrives, because claiming an unconfirmed screen would make an app draw into nothing. Check it at the point of use rather than caching it at startup. ### Input: the same actions, a different gesture Your `onClick` and `onBack` handlers are unchanged across vendors, and that is not a coincidence. Google's gesture API for the temple touchpad is exactly three callbacks: ```kotlin Modifier.onIndirectPointerGesture( onSwipeForward = { … }, onSwipeBackward = { … }, onClick = { … }, ) ``` Focus next, focus previous, select. Those are the same three actions Meta's Neural Band delivers as a thumb-slide either way and an index-pinch. Two head-worn devices with no cursor and a small panel converged on one interaction model, which is why a single display API serves both. **Back is the one difference, and it is a real one.** Meta's mid-pinch is a back gesture that reaches your `onBack`. Google's touchpad API has no back callback — it is absent from the modifier, not merely undocumented. On Android XR, back can only arrive through the system back path. So build screens the wearer can leave by selecting something, and treat back as a bonus rather than the exit. One implementation difference that does not reach your code: on Meta the platform reads the band and tells the SDK which node was selected, while on Android XR the SDK tracks focus itself and draws the focus ring. Same behaviour, different side of the boundary. ## How this fits the capability model Extentos does not model "an Android XR app" or "a Meta app" — it models capabilities. Your code asks whether a capability is available and responds accordingly, and the same handler runs on any vendor that provides it. That is why the transport can land before the hardware does: when Android XR glasses ship, apps written against the capability surface do not need rewriting. See [capabilities](/docs/concepts/capabilities) and [transport vs app](/docs/concepts/transport-vs-app). ## Frequently asked questions ### Can I build an Android XR app with Extentos today? No. The transport exists and works on the emulator, but the module is unpublished, so there is nothing to depend on — and there is no hardware to run it on. ### Why build a transport for hardware nobody can buy? Because the architecture claim needed proving. "Vendor-agnostic" is easy to assert and hard to verify with one vendor. Building a second, genuinely different transport — Android XR uses a projected-activity model, not Bluetooth — is what tests whether the seam actually holds. ### Does supporting Android XR slow down or complicate my Meta app? No. The Android XR module is not a dependency of the core, so a Meta-only app never pulls its libraries, and transport resolution is unchanged unless you explicitly register it. ### When will Android XR be production-supported? No committed timeline. It depends on Google shipping hardware and moving the platform out of developer preview. See the [neutral platform view](/docs/ecosystem/platforms/android-xr) for the wider Android XR picture. ### What about the display variant? Supported, as of 2026-07-27. The display path is real code: your display tree is translated to Glimmer, Google's display toolkit, and rendered by a projected activity the SDK owns. The simulator offers the device with its own panel geometry and its own input hardware, so a layout you build there is a layout the glasses can hold. Two honest limits. Nothing is hardware-verified, because no Android XR glasses of either class are on sale, and the display class is expected later than the audio one. And `video` inside a display tree has no Glimmer equivalent; the SDK plays it through the Android framework instead, which is built but not yet proven on a device.