Building on Android XR with an exit clause

Picture a company that inspects fire-safety equipment in office buildings. It commissions a small app for display glasses on Android XR: the inspector looks at an extinguisher, the app reads the label, Gemini fills in the checklist from what the inspector says, and the report goes out before he reaches the next floor. It works well in the pilot. A year later the company wants a second type of glasses for the technicians who cannot wear the first ones, the contractor who wrote the app has moved on, and nobody can say which parts of the checklist live in the app, which in the assistant’s instructions and which only in a cloud account opened during the pilot.

The company is hypothetical. The pattern is the one every platform produces when nobody plans the way out on the first day.

What a company builds on

Android XR is Google’s platform for headsets, display glasses and audio glasses, developed with Samsung and Qualcomm, with Gemini as the assistant layer. The devices are arriving: XREAL Aura is the first priced pair of display glasses on it, though its first wave ships to the United States, Canada, Japan and South Korea and not to the EU; Samsung has announced Gemini glasses for November 2026. The developer side is described in the Android XR SDK updates: Jetpack XR and SceneCore for spatial apps, Jetpack Projected for glasses, where the app runs on a host device such as a phone and projects the experience to the glasses, Jetpack Compose Glimmer for interfaces on see-through displays, and an emulator for glasses.

That is a real, well-documented platform. It is also one company’s platform, at an early stage, and Google does not publish how much of the assistant’s work runs on the device and how much in its cloud.

The real cause: the exit is cheapest on the day you sign

Leaving a platform costs whatever the company allowed to grow into it: data in its cloud, logic in its assistant, code nobody else can read. All of that is decided early, by defaults, during the pilot. The exit clause matters most makes the general case; on a young device platform it applies twice, once to the vendor and once to whoever builds the app.

Where an Android XR project locks itself in

The process lives in the assistant’s instructions. If the checklist logic is a set of prompts to the platform’s assistant, it moves when the assistant changes, and it cannot be taken anywhere else.

The data lives only in the platform’s cloud. Reports, photos and history stored under an account created for the pilot, with no tested export.

The app is all glasses. Business rules mixed with display code, so a second device means a rewrite rather than a new screen.

The contractor owns the code. Without a clause saying otherwise, the source, the build and the signing keys stay with the person who wrote them.

One device line. A process designed around one pair of glasses has no answer for the people who cannot wear them, or for the day that model is discontinued.

Background steps nobody records. A multi-step task run by the assistant leaves the platform’s record, not the company’s. Agents on Android XR looks at what a record of every step should look like.

How we approach it

KYBERTIS does not integrate Kyber with Android XR and does not resell Google or XREAL products. When a company we work with builds on a platform like this, this is how we approach the work and the contract:

Keep the system of record in the company. Reports, checklists and history live in a system the company runs and can export from. The glasses read and write; they never become the only copy.

Keep the logic on the host, away from the display. Jetpack Projected already runs the app on the host and projects it to the glasses, which is a good start. Keep the business rules in a layer that does not know which glasses it is talking to, and the glasses part thin.

Keep the assistant out of the decision. Let it fill fields and read labels. Approvals and the rules that decide them belong in the company’s own system, written down where a person can read them.

Test the export, not just the feature. Before the pilot ends, take the data out and open it somewhere else. An export nobody has tried is a hope.

Try a second device early. The emulator for glasses makes it cheap to see what breaks when the screen changes.

Write the exit into the contract. Source code, build instructions, keys, documentation and the data handed over in a format named in advance, with time to do it. Support comes with an SLA and an exit clause; the details are agreed in the contract, as what an SLA on open source means describes.

Why a platform built on an open kernel is still not an open system is the subject of Android XR is Linux underneath, and the small-company side is in Android XR in a small company. For the rollout itself, see rolling out display glasses to a team. Nothing is for sale yet; the KYBERTIS homepage has the honest state.

A test you can run today

Run an exit drill on paper. Assume that next Monday the platform your field work depends on disappears, or changes its terms so that you will not stay. Write down three lists: what stops working, what data you could take with you by Friday, and who holds the code and the keys.

If any list is longer than you expected, that is your exit clause, written while you still have the leverage to get it.