Vendors

Extentos is a smart-glasses development layer that abstracts vendor-specific SDKs behind one capability surface. As of 2026-04, Meta Ray-Ban is the only GA vendor — every Ray-Ban Meta and Oakley Meta variant is supported through the Meta Device Access Toolkit (DAT). Mentra G1, Android XR, and future Apple smart glasses are tracked roadmap vendors — supported in the architecture (vendor-agnostic AppSpec, swappable GlassesTransport interface) but not yet implemented as transports. 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-04

The single GA vendor is verifiable: glassesEnum in mcp-server/src/tools/definitions.ts accepts only "meta_rayban", and AppSpecV2.deviceModel only accepts "META_RAYBAN". Adding another vendor means extending those enums alongside the transport implementation.

The vendor model

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

Result: an app written today against meta_rayban runs unchanged on a future mentra_g1 target by switching the transport. No code rewrite, no AppSpec 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
• RealMetaTransport.kt, BrowserSimTransport.kt, LocalSimTransport.kt — three implementations, all targeting Meta DAT today
• ios-library/Sources/GlassesCore/Transport/GlassesTransport.swift — iOS parity

A future Mentra vendor adds RealMentraTransport.kt and RealMentraTransport.swift that implement the same interface against Mentra'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 Mentra G1" today means stage 1 — architecture-ready. It does not mean a developer can import com.mentra.* and ship. The roadmap pages for each non-Meta vendor are honest about which stage applies.

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 Mentra G1 ships in volume, your existing Extentos AppSpec runs on it without a rewrite. Apps written directly against Meta DAT need a separate Mentra 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 18 tools generalize across vendors. The agent uses the same getPlatformInfo, validateIntegration, createSimulatorSession whether the target is meta_rayban or mentra_g1. No re-learning the tooling per vendor.
4. One AppSpec language. The capability vocabulary is shared. A developer who has built one Extentos app for Meta knows the language for every future vendor. No starting over.
5. Bounded vendor lock-in. If Extentos ever doesn't fit, the AppSpec is a JSON document the developer owns; the generated code is the developer's app code. The exit cost is bounded.

The cost: vendor-specific features that aren't in the shared vocabulary (e.g., Meta Ray-Ban Display rendering, neural-band gestures) 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, and audio output, 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 and deviceModel in the AppSpec types.
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 AppSpec format doesn't change. The MCP tools don't change. Existing developer apps don'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.

Per-vendor pages

Deep reference for each vendor lives on its dedicated page:

• Meta Ray-Ban → — full GA capability matrix, hardware tiers, development setup, distribution state, the Meta DAT toolkit, partner-curated integrations like Google Maps on Display
• Mentra G1 → — roadmap status, open-ecosystem framing
• Android XR → — roadmap status, tracking Google's GA timeline
• Apple smart glasses → — roadmap status, pending Apple platform availability

Cross-vendor capability matrix

Comparison across vendors will land here once a second vendor is transport-implemented. Today, with Meta as the only GA 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 (GA / preview / not exposed).

Frequently asked questions

Which smart glasses can I build for with Extentos today?

As of 2026-04, only Meta Ray-Ban — every Ray-Ban Meta variant (Gen 1, Gen 2, Display) and Oakley Meta HSTN. The Display variant has additional capabilities (heads-up display, neural-band gestures) that Meta doesn't expose to third-party DAT apps; Extentos works on Display hardware but doesn't surface those capabilities. See vendors/meta for the full picture.

Will my Extentos app run on Mentra G1 when it ships?

Architecturally yes — your AppSpec is vendor-agnostic and the abstraction is built for portability. Practically: it runs on Mentra G1 once Extentos ships a MentraTransport implementation. No code or spec changes are required on your side; the transport is selected at app start based on which hardware is present.

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

Not on the current roadmap. Roadmap inclusion requires the vendor to have a public SDK Extentos can target, sufficient developer-program access, and meaningful hardware availability. Suggest a vendor by filing an issue in the Extentos repository.

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

Display rendering on Meta hardware is a Meta-controlled surface — third-party DAT apps can't draw to it. This isn't an Extentos limitation; it's a Meta API boundary. If Meta exposes display rendering in a future DAT release, Extentos will add it to the capability vocabulary.

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: the AppSpec is a JSON document you own, and your app_callback handlers are your own code. Switching off Extentos is a manageable migration if it ever becomes necessary.

When will Mentra G1 / Android XR / Apple be GA?

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. The current focus is finishing the Meta hardware test loop — 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 concepts

• Capabilities — the vendor-agnostic vocabulary every vendor's transport implements
• Architecture — how the AppSpec, 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 the GA vendor (Meta) today