Android XR SDK 1.0 Went GA. Here Is What Indie Developers Actually Got.

Evan wrote up the consumer side of I/O yesterday and called the Warby Parker ship date the headline. He is right. But the headline for anyone with a Unity project, a Godot prototype, or a half-built Jetpack Compose app sitting in a side branch was at the 1pm developer keynote, not the 10am show. The thing Google did at 1pm was harder than putting a date on a pair of glasses. They froze the API surface, consolidated four overlapping toolchains into one, broke from every other XR platform on the gesture grammar question, and put real money behind the developers who commit before the hardware ships. I want to walk through what each of those means for a small team, because the framing matters more than the bullet list.

What GA Actually Means Here

Android XR SDK 1.0 is no longer a developer preview. That sentence is doing more work than it looks like. Developer preview is the label Google has put on every XR-adjacent SDK since the Daydream days, and it is the label that lets Google ship breaking changes between releases, drop APIs without deprecation cycles, and treat the entire surface as moving ground. General availability means the surface is frozen. Breaking changes will go through a one-major-version deprecation window, the same way every other Jetpack library is treated, and apps you ship today against the GA build will run on the Warby Parker frames in October without a rewrite.

I want to be clear about why this is the actual headline. A studio of three people cannot ship a launch-window app on a moving SDK. They can prototype on it. They can demo on it. They cannot commit ten weeks of work to a code path that might rename half its symbols before the hardware ships. GA is what makes the October 14 launch window a real launch window for anyone outside Google's first-party partner list. I have been hearing the same complaint from indie teams since the Daydream SDK churned for two straight years, and Google clearly heard it too.

The version number matters less than the contract. Android XR SDK 1.0.0 ships today with full Maven and Jetpack distribution, source-available samples in a real GitHub org, and a published lifecycle policy that promises 18 months of source compatibility before any deprecation. That is the longest lifecycle commitment Google has ever made on an XR SDK at launch, and it is the one that gets a small team to clear room on the roadmap.

The Toolchain Consolidation Is Real

I covered this ahead of I/O in my developer preview piece and I was nervous it would land as an abstraction layer over four other abstraction layers. It did not. The consolidation is real and it cuts what used to be four overlapping surfaces into one coherent stack.

The stack as of yesterday is: Jetpack SceneCore for 3D scene graph and rendering, ARCore for Jetpack XR for environmental understanding and anchors, Jetpack Compose XR for spatial UI, and the new Jetpack Projected APIs for phone-to-glasses content handoff. Those four libraries share one runtime, one lifecycle, and one set of permission primitives. You import them the same way you import any other AndroidX library. You target them at one of three device profiles, glasses, headset, or phone with spatial extensions, and the runtime handles the rest.

The thing that used to be painful, which was figuring out whether a feature lived in ARCore proper or in the XR-specific extensions, is gone. ARCore for Jetpack XR is the only spatial-understanding API surface on Android XR now. The legacy ARCore SDK for phone-only AR is still there for backwards compatibility, but new development on Android XR targets the XR variant exclusively. One environmental understanding API, one anchor type, one plane detection model. Anyone who fought through the 2024 split between ARCore Geospatial and ARCore Cloud Anchors will recognize what a relief this is.

The Projected APIs Are the New Pattern

Now the part that is new and the part nobody is going to fully appreciate until they have built against it. Jetpack Projected APIs let a phone app push lightweight XR content to paired glasses without the phone app itself becoming a full XR app. The pattern is closer to Wear OS than to a porting effort. You declare a projected surface in your phone app, you bind it to a Compose composable, and when the user's paired Android XR glasses are active, the surface renders into the in-lens display as a peripheral chip.

That is a very different mental model from the one Meta or Apple is asking for. On Horizon OS or visionOS, the developer ships a full spatial app and the user opens it on the device. On Android XR with the Projected APIs, the developer ships a phone app and the spatial surface is a secondary render target, the way a notification is. Calendar notifications, navigation arrows, message previews, music controls, translation captions. Any of these can be a projected surface today with maybe 80 lines of Compose. I am not exaggerating that line count. The sample app Google open-sourced after the keynote has a working translation overlay in 73 lines.

The implication for app strategy is significant. A team that already ships a strong phone app does not need to build a separate XR product to have a glasses presence on day one. They need to identify the three or four moments in their existing app where a glanceable in-lens chip would matter, declare them as projected surfaces, and ship. That is a one-sprint commitment, not a one-quarter commitment.

The honest caveat is that the Projected API surface is intentionally narrow. You get a Compose canvas, you get hardware gesture input events, and you get the system camera permission if you ask for it. You do not get the full spatial scene graph, you do not get plane detection, and you do not get hand tracking. Those live in the headset and full-glasses profiles. If your app needs them, you are writing a full XR app, not a projected surface. Most apps do not need them. Some do.

The Gesture Grammar Broke from Everyone

This is the part where Google made a real bet that I am not sure everyone has registered yet. The input grammar on Android XR glasses is not air-tap, not pinch, not eye-and-pinch. It is hardware gestures on the frame itself. Tap the right temple to dismiss. Double-tap to confirm. Hold to invoke Gemini. Swipe forward on the temple to advance. Swipe back to retreat. That is the entire input vocabulary at launch, plus voice.

Apple anchored on eye-and-pinch for visionOS because they had the eye tracking to make it work on a headset. Meta has spent two years iterating on hand tracking and surface-tap gestures for both Quest and the Ray-Ban Display. Google looked at both, looked at what fits an everyday-wear pair of glasses with no controllers and no front-facing hand cameras, and committed to a closed grammar tied to the frame hardware. That is a stronger statement than it sounds like, because it means every Android XR glasses app at launch will share the same input vocabulary, and a user who learns the gestures on Warby frames will know them on Gentle Monster frames in February and on the Samsung-built model when it eventually ships.

The design implication is also significant. You are not designing a gestural UI on Android XR. You are designing a glanceable card with at most four interaction states, mapped to four hardware gestures. That is a much more constrained design space than visionOS or Horizon OS, and the constraint is the point. The category Google is targeting with these frames is everyday wear, not 30-minute productivity sessions, and the input grammar reflects that.

If you are coming from a Quest or Vision Pro background, you will need to unlearn some habits. I would not bring a hand-tracking UI mental model into an Android XR glasses app. The gesture vocabulary is closer to a smartwatch than to a headset.

The $30 Million Fund and Who It Is Actually For

Google announced a $30 million developer fund yesterday with grants up to $250,000 for studios building Android XR glasses apps in the first six months after launch. The headline number is small next to Meta's Reality Labs spend, but the structure is interesting. The grants are non-dilutive, they are paid in two tranches with a shipping milestone between them, and the application window opens on June 1 with a three-week review cycle.

The targeting criteria, which I dug through last night, are narrower than the press release implies. Google is funding original spatial experiences designed for the in-lens display form factor. They are not funding ports of existing Quest or Vision Pro apps. They are not funding phone-app projected surfaces. They are funding new things built for the glasses-first interaction model that they just committed to with the gesture grammar decision.

That is the right targeting, in my view. The Projected APIs do not need a fund to incentivize adoption. They are cheap enough that any team with a strong phone product will ship one for free. The thing that needs incentive is the original glasses-first app category, because that is the category that has no proven monetization model yet and that requires committing real engineering time before the install base exists. $250,000 covers about nine months of a two-person team in most markets. That is enough to ship a real product against the October window.

Where the SDK Still Trails

I do not want to write the version of this piece that ignores the gaps, because there are real ones.

The asset pipeline for 3D content on Android XR is still less mature than on visionOS or Horizon OS. There is no equivalent yet to Reality Composer Pro or the Quest-specific glTF optimization pipeline. The recommended path is glTF 2.0 via Jetpack SceneCore, which works, but the tooling around it is thinner than the Apple or Meta side of the comparison.

Third-party engine support for the new Projected APIs is also unsettled. Unity has a working Android XR package today, but the Projected API surface specifically is not yet exposed in the public Unity XR plugin and will not be until the Unity 6.1 release scheduled for July. Unreal's Android XR plugin is further behind that. Godot 4.6's OpenXR 1.1 path is the most surprising story here, because the Godot maintainers told me last night they expect Projected API support to land in 4.7 within six weeks. For a free open-source engine to beat Unity to a new platform surface is not nothing.

Spatial audio on Android XR remains the area I am least confident about. The keynote demos used Pixel Buds Pro as the audio path, which works fine, but the on-glasses speaker array on the Warby frames is a different acoustic story, and I have not heard a sample app that actually exercises it well. That is a wait-and-see for the October hardware.

What I Would Actually Do This Week

If you are a solo developer or a small team and you want to ship something for October 14, the path I would recommend is the boring one. Pick one moment in an app you already ship. One. A notification, a translation, a transit prompt, a music control. Wrap it in a Jetpack Projected API surface using the Compose sample Google published yesterday. Get it running on the Android XR emulator profile this weekend. Polish it for two weeks. Submit to the developer program by mid-June and aim for the launch window.

If you have a more ambitious idea, an original glasses-first app, the math changes. The June 1 grant application window is the thing that matters. The $250,000 ceiling on the grants is enough to fund a real attempt, the targeting criteria favor the kind of small team that would not get a Meta or Apple deal, and the August 4 phase-one disbursement is timed so that funded projects can hit the October launch window.

The Honest Read

I have been on the Android XR beat for about a year, and yesterday was the first time the developer story felt internally consistent. The SDK is GA. The toolchain is consolidated. The new pattern, projected surfaces from phone apps, is a genuine simplification of what a glasses app has to be on day one. The gesture grammar is opinionated in a way that is going to age well. And the funding is targeted at the right category.

The gaps are real, but they are the gaps you would expect for a v1 platform. Asset tooling will catch up. Engine plugin parity will catch up. Spatial audio will get better samples once people start shipping. None of those are the kind of structural problem that delays a launch window. They are the kind of problem that gets patched on a normal release cadence.

Evan wrote yesterday that the verb got said and the clock started. From the developer side of the table, the clock is real and the runway is long enough. I am going to spend the rest of this week building a Projected API sample for a phone app I already ship, just to feel out the cycle time. If it lands the way the keynote samples did, the October launch window is the most credible day-one developer story Google has put together on XR hardware since they started trying. Sam will write the Meta-response piece when Meta responds. Evan will write the Apple-response piece when Apple responds. I will keep writing the indie-developer piece, because in five months that is the audience that decides whether the platform has anything to do on day one.

See you in the SDK changelogs.