Vendors

Extentos is a smart-glasses development layer that abstracts vendor-specific SDKs behind one capability surface. Today, Meta is the only production vendor — every Meta smart-glasses model (each Ray-Ban Meta and Oakley Meta variant) is supported through the Meta Wearables Device Access Toolkit (DAT, a public developer preview). Android XR is the second vendor — its projected transport is built and proven end-to-end on Google's Android XR emulator, but the module is deliberately unpublished while the platform is in developer preview and no Android XR glasses are buyable yet. Brilliant Labs is the third — its BLE transport is built and published, but nothing has run it on a device and, unlike Android XR, no emulator stands in either. Future Apple smart glasses remain a tracked roadmap vendor — supported in the architecture (vendor-agnostic Kotlin/Swift SDK, swappable GlassesTransport interface) but not implemented as a transport. This page is the consolidated status, the vendor model, and what "Extentos supports vendor X" actually means at any given point.

Status — as of 2026-07

The status above is verifiable rather than asserted: glassesEnum in mcp-server/src/tools/definitions.ts is DERIVED from the device registry, and accepts "meta", its "meta_rayban" legacy alias, "android_xr" and "brilliant" — the last two marked preview because simulator sessions can be minted for them while their transports ship unpublished. Meta remains the only vendor you can ship against.

The vendor model

Extentos's vendor-portability is a structural property of the architecture, not a marketing promise. Three layers cooperate:

Result: a handler written today against meta_rayban runs unchanged on a future android_xr target by switching the transport. No code rewrite, no migration. The transport is the only piece that's vendor-aware.

This is verified in code:

• android-library/glasses-core/src/main/java/com/extentos/glasses/core/GlassesTransport.kt — the interface
• SystemAudioTransport.kt, RealMetaTransport.kt, BrowserSimTransport.kt, LocalSimTransport.kt — four implementations
• ios-library/Sources/GlassesCore/Transport/GlassesTransport.swift — iOS parity

A future Android XR vendor adds RealAndroidXrTransport.kt and RealAndroidXrTransport.swift that implement the same interface against that platform's SDK. Existing apps targeting meta_rayban are unaffected.

For the deep dive on the abstraction, see concepts/capabilities — the vocabulary itself — and concepts/architecture — how the layers fit together.

What "supports vendor X" means at any point

This is worth pinning down explicitly because the word "supports" is doing a lot of work:

Saying "Extentos supports Android XR" today means stages 1, 2 and 4 — built and simulatable, but not installable and not hardware-verified. It does not mean a developer can ship against it. The page for each non-Meta vendor opens with the same eleven-row status table so you can see exactly which stage applies, row by row.

Why vendor portability matters for developers

The strategic case for building on Extentos rather than directly on a vendor SDK:

1. One code base, future hardware coverage. When Android XR ships broadly, your existing Extentos handler code runs on it without a rewrite. Apps written directly against Meta DAT need a separate Android XR implementation.
2. One simulator, every vendor. The Extentos browser simulator (BrowserSimTransport) is vendor-agnostic at the protocol layer. Adding a vendor adds support to the same simulator the developer already uses. Apps written directly against vendor SDKs need a different test harness per vendor.
3. One agent integration. The MCP server's deterministic tool surface generalizes across vendors. The agent uses the same getPlatformInfo, getCapabilityGuide, validateIntegration, createSimulatorSession whether the target is meta_rayban or android_xr. No re-learning the tooling per vendor.
4. One SDK surface. The capability vocabulary is shared. A developer who has built one Extentos app for Meta knows the SDK for every future vendor. No starting over.
5. Bounded vendor lock-in. If Extentos ever doesn't fit, your handler classes are normal Kotlin/Swift code you own. Switching off Extentos is a manageable migration — rewrite the handler calls against the vendor SDK directly.

The cost: vendor-specific features that aren't in the shared vocabulary (e.g., Meta's reserved "Hey Meta" wake word, or custom tap/swipe gestures that aren't in DAT's public surface) aren't accessible through Extentos. Apps that need those features need to use vendor SDKs directly. Most apps don't — most apps use camera, microphone, voice triggers, audio output, and display rendering, all of which are in the shared vocabulary.

How a new vendor gets added

This is bounded engineering work, not a rewrite, because the architecture defines the seams:

1. Implement GlassesTransport for the new vendor against its SDK — RealXxxTransport.kt on Android, RealXxxTransport.swift on iOS. Estimated scope: similar to RealMetaTransport (~1500 lines per platform).
2. Declare the capability manifest — which abstract capabilities the vendor exposes, with tier markers (stable, preview, etc.).
3. Extend the glassesEnum in mcp-server/src/tools/definitions.ts.
4. Extend the simulator backend — add the vendor's hardware-event injection UI if it has novel capabilities.
5. Validate end-to-end on real hardware.

The SDK surface doesn't change. The MCP tools don't change. Existing developer handler code doesn't change. The new vendor is a drop-in addition.

The reason the roadmap exists rather than the implementations: each vendor's SDK has its own maturity, its own developer-program access requirements, and its own hardware availability. Extentos adds a vendor when adding it makes a real product (transport + simulator + tested hardware), not when the architecture could accept it.

Platforms with a build guide

Extentos ships a production transport for Meta, and a preview transport for Android XR:

• Meta smart glasses → — the Extentos build guide: capability matrix, hardware tiers, development setup, distribution state, the Meta DAT toolkit, and the launch-partner picture. (For Meta's neutral platform view alongside every other vendor, see Meta in the ecosystem.)

• Android XR → — the preview status page: what is built, what is deliberately withheld, what you can test today, and why vendor support is opt-in. (Neutral platform view: Android XR in the ecosystem.)

Apple remains on the roadmap and is not buildable with Extentos, so it has no build guide — its neutral coverage lives in the landscape: Apple. Every third-party smart-glasses platform (Snap, Rokid, RayNeo, Vuzix, and more) is mapped in the ecosystem section.

Cross-vendor capability matrix

Comparison across vendors will land here once a second vendor is transport-implemented. Today, with Meta as the only production vendor, the matrix would be one column — see vendors/meta for the full Meta capability table. The shape of the future matrix mirrors the abstract capability vocabulary: rows = capabilities (capture_photo, voice_command, etc.), columns = vendors, cells = tier (production / preview / not exposed).

Frequently asked questions

Which smart glasses can I build for with Extentos today?

Today, only Meta smart glasses — every Ray-Ban Meta variant (Gen 1, Gen 2, Optics, Display) plus Oakley Meta HSTN, Oakley Meta Vanguard, and the 2026 Meta Glasses line. On Meta Ray-Ban Display you can also render UI to the heads-up display via glasses.display.* (see the display capability) — the wearer drives it with captouch + the Neural Band, delivered to your app as abstracted tap events. Meta keeps its first-party system experiences (navigation, WhatsApp, captions) and raw Neural Band access to itself — not third-party rendering. See vendors/meta for the full picture.

Will my Extentos app run on Android XR when it ships?

Architecturally yes — your handler code is vendor-agnostic and the abstraction is built for portability. The Android XR transport now exists and is proven on Google's emulator, so the remaining gaps are publishing the module and Google shipping hardware. No code changes are required on your side; the transport is selected at app start based on which hardware is present. See Android XR for the exact status.

What about Vuzix, RealWear, Even Realities, or other vendors?

Not on the current Extentos support roadmap — but we map the whole third-party smart-glasses landscape (Snap Spectacles, Brilliant Labs, Rokid, RayNeo, Vuzix, Even Realities, INMO, Solos and more) in the ecosystem section, with each platform's SDK, app model, distribution, and AI story. Roadmap inclusion here (a shipped Extentos transport) requires the vendor to have a public SDK Extentos can target, sufficient developer-program access, and meaningful hardware availability. Suggest a vendor by emailing hello@extentos.com with the [vendor] prefix.

Can Extentos add display-rendering support for the Ray-Ban Meta Display variant?

Yes — it already exists. Meta's DAT opened a third-party display path, and Extentos exposes it as glasses.display.* (a declarative node tree on the Ray-Ban Display, shipped in both SDKs and fully sim-testable; on-glasses rendering is live on Android via DAT 0.8.0, with iOS on-glasses delivery in progress). See the display capability. What stays Meta-only is the first-party full-screen system experiences (navigation, WhatsApp, captions — Meta's own apps), not third-party rendering.

Is Extentos vendor-locked to Meta?

No, technically. The architecture is vendor-agnostic by design. In practice, Meta is the only currently-implemented vendor, so today an Extentos developer is targeting Meta. The lock-in is bounded: your handler classes are normal Kotlin/Swift you own. Switching off Extentos is a manageable migration — rewrite the SDK calls against the vendor SDK directly — if it ever becomes necessary.

When will Android XR / Apple be production-supported?

No committed timelines. Vendors are added when adding them makes a real product (transport implementation + simulator coverage + tested hardware), which depends on each vendor's SDK maturity and hardware availability. Android XR has cleared the transport and simulator steps but not the hardware one — nothing is hardware-verified because no Android XR glasses are buyable. See the changelog for actual release activity.

Does my Extentos app target the Meta companion app or run on the glasses?

Extentos apps are phone apps that talk to the glasses over Bluetooth. The phone runs your Android or iOS app; the glasses run Meta's firmware. This is the same model Meta DAT uses — see vendors/meta § Audio architecture for the audio-routing details and concepts/architecture for the system overview.

Related

• Capabilities — the vendor-agnostic vocabulary every vendor's transport implements
• Architecture — how the SDK, library, transports, and backend fit together
• Transport vs app simulation — what each transport actually does, why the layering enables vendor portability
• Quickstart with an AI agent — install Extentos and target Meta today

Related