Transport vs app simulation

Building a smart-glasses app for Meta Ray-Ban means working across two simulation layers, not one. Meta's Mock Device Kit (mwdat-mockdevice on Android, MWDATMockDevice on iOS) simulates the transport layer — the Bluetooth Low Energy link, the protocol framing, the video/audio codec, the SDK call surface — so your mobile app thinks it's talking to glasses. Extentos simulates the app layer — voice triggers being recognized, photos being captured, the wearer's audio output, hardware alerts (thermal, hinges, audio-route changes), permission flows, and the moment-to-moment user experience as it would feel on real Ray-Ban Meta glasses.

These two layers are complementary, not competing. Extentos uses Meta's Mock Device Kit inside one of its three transports (LocalSimTransport). Its headline browser-based simulator (BrowserSimTransport at extentos.com/s) is a separate architecture — a WebSocket protocol with a browser-side hardware surrogate that drives real webcam and microphone input through the same glasses.* API your production code uses. This page explains the distinction, the implications for development speed, and why an AI coding agent building a Meta Ray-Ban app should reach for Extentos rather than wiring Mock Device Kit by hand.

TL;DR

You can think of Mock Device Kit as testing the wire between your app and the glasses. Extentos's browser simulator tests the experience of using your app while wearing glasses. A Meta Ray-Ban app benefits from both, and Extentos ships both behind one API.

The two layers, separately

What Meta's Mock Device Kit does

Meta's Device Access Toolkit (DAT) ships a mock layer alongside the real SDK:

• Android: the mwdat-mockdevice Maven artifact, with MockDeviceKit and MockCameraKit classes
• iOS: the MWDATMockDevice Swift Package Manager module, with MockDeviceKit.pairRaybanMeta() and MockCameraKit.setCameraFeed(...) APIs

When you wire it up, your app's Wearables.configure() succeeds without scanning Bluetooth, your createSession(...) returns a MockDeviceSession whose publishers emit events as if a paired Ray-Ban Meta were responding, and your camera-stream subscription returns frames from a bundled video file or the phone's own camera. The DAT API surface — Wearables, DeviceSession, StreamSession, videoFramePublisher, photoDataPublisher — behaves as it would in production.

This is the transport layer. The mock answers the SDK; the SDK shape is what's being exercised. You write the rest of your app — the trigger logic, the user flow, the UI, the AI calls, the audio routing decisions — yourself, in code, against that mocked SDK.

What Mock Device Kit is excellent at:

• Verifying your DAT integration compiles, links, and calls the SDK correctly
• Local testing on the developer's phone or emulator with no network
• Pulling synthetic camera frames from a controlled source (bundled file or phone camera)
• Exercising connection / session / stream lifecycle without bonding real glasses

What Mock Device Kit doesn't do:

• Recognize voice triggers — there's no speech-recognition simulation
• Play TTS audio out so you can hear what your wearer hears
• Inject hardware alerts (thermal warning, hinges closed, incoming call) through a UI — you'd write code to fire them programmatically
• Show you what the wearer would see and hear as a holistic experience
• Surface a structured, queryable event log for an AI agent to debug
• Persist logs after the app process dies
• Hot-reload your app's behavior without rebuilding

What Extentos's browser simulator does

BrowserSimTransport is the simulator developers spend most of their time in. It's not a fork of Mock Device Kit — it's a different architecture entirely:

• The Extentos library opens a WebSocket to wss://api.extentos.com/ws/{sessionId}
• A browser tab at extentos.com/s/{sessionId} joins the same session as the hardware surrogate
• The browser drives real webcam frames, real microphone audio, and real speech-to-text recognition through the developer's machine
• TTS plays back through the developer's speakers so they can hear what the wearer would hear
• Hardware alerts are injected through clickable buttons in the browser UI
• Every event flows through Extentos's structured 7-layer event bus and is queryable via the getEventLog MCP tool

The same glasses.camera.capturePhoto() call that runs against BrowserSimTransport in dev runs against RealMetaTransport (Meta DAT) in production. Identical API, different wire underneath.

This is the app layer. Your spec defines what your glasses app does — what triggers, what blocks, what handlers. The simulator runs the spec exactly as production would, against a hardware surrogate the developer drives through a familiar browser UI.

What Extentos uses from Meta's Mock Device Kit

Extentos has three transport implementations behind its GlassesTransport interface. Only one of them wraps Meta's Mock Device Kit:

So the precise answer: Extentos uses Mock Device Kit for LocalSimTransport — fast inner-loop testing on the phone or emulator without a network round-trip — and replaces it with a higher-level simulator for BrowserSimTransport, which is where the developer spends the bulk of their time.

This is intentional. Mock Device Kit is the right tool for "does my SDK integration compile and run" — Extentos defers to it. It's the wrong tool for "does my voice-trigger app actually feel right when worn" — Extentos builds a separate simulator for that.

Why testing requires both layers

Consider a typical Meta Ray-Ban app: the user double-taps the glasses, says "summarize this", the camera captures a frame, the app calls a vision model, and the glasses speak the answer.

To validate that flow, you need to test:

1. Does my app speak the DAT SDK correctly? (transport layer — Mock Device Kit's job)
2. Does my voice trigger fire on the right phrase with the right confidence? (app layer — needs real STT)
3. Does the captured frame look right and route to my handler? (app layer — needs real frames)
4. Does the spoken response sound right at the right moment? (app layer — needs TTS playback the developer can hear)
5. What happens when the user removes the glasses mid-flow? (app layer — needs hardware-alert injection)
6. What happens when the BLE link drops? (transport layer — Mock Device Kit-style mocking)
7. Does my AI handler return cleanly under timeout? (app layer — needs the full execution to play out)

Mock Device Kit answers (1) and (6). Extentos's browser simulator answers (2) through (7). Doing all seven with raw Mock Device Kit means writing your own speech-recognition simulator, your own TTS playback harness, your own hardware-alert injection UI, your own event correlator, and your own replay tool.

That's a lot of infrastructure. Extentos is that infrastructure — built once, shared across every Meta Ray-Ban app developer.

The complete advantage list

The case for BrowserSimTransport over a hand-rolled Mock Device Kit setup, grouped by what an AI agent and a human developer each gain:

Setup and iteration speed

1. Zero-config simulation. Extentos resolves the right transport at ExtentosGlasses.create() based on BuildConfig.EXTENTOS_SESSION_URL (Android) or extentos.session.plist (iOS). With raw Mock Device Kit you write the mock initialization, device pairing, state-machine walks, and camera-feed wiring by hand for every app.
2. Auto-bind dev loop. Once the Extentos library is in your app, the MCP server and the library coordinate via a 127.0.0.1:31337/whoami localhost bridge. Every new createSimulatorSession call auto-attaches the running app to the new session — no rebuild, no URL paste, no typed code in the happy path. Mock Device Kit has no MCP integration at all.
3. Spec-driven, not code-driven. Your app behavior lives in an Extentos AppSpec the agent maintains. Mock Device Kit gives you a mocked SDK; you still hand-write all the trigger and flow code yourself.
4. Spec hot-reload. Edit the spec, the simulator picks up the new spec without restarting the app or rebuilding the project. Mock Device Kit needs a full Android Studio (or Xcode) rebuild on every change.
5. No mobile build cycle for the inner loop. Browser simulation runs without an Android emulator or iOS Simulator booted up. With Mock Device Kit, every iteration is a build-and-deploy cycle.

What you can actually see and do

6. Phone, glasses, and agent in one view. The browser shows the wearer-perspective alongside your phone-app UI alongside the live event stream. Mock Device Kit shows you camera frames inside your app — that's it.
7. Real webcam and microphone in the loop. Browser simulation uses the developer's actual webcam and microphone for input. Mock Device Kit can play back a bundled video file or the phone camera, but no real microphone-driven speech recognition.
8. Hardware-event injection UI. Buttons in the browser to fire thermal_warning, hinges_closed, audio_route_changed, incoming_call_detected, app_lifecycle_changed. With Mock Device Kit you'd write code to programmatically trigger these — and you'd write that code separately for each scenario.
9. Permission flow modeled. Browser sim respects user-denied webcam or mic permission and surfaces TransportError.HardwareUnavailable exactly as production would. Mock Device Kit assumes permissions granted.
10. A2DP/HFP coexistence warnings. The simulator surfaces audio-routing conflicts (e.g., a video stream on A2DP racing a mic capture on HFP/SCO) as coexistence.warning events. Mock Device Kit doesn't simulate this Bluetooth audio-profile interaction.

Debugging the AI agent can use

11. 7-layer structured event log. Every event is tagged with one of transport, trigger, block, callback, toggle, stream, or system. Mock Device Kit logs are raw DAT-level Logcat / os_log output — unstructured, unfiltered, untagged.
12. flowId correlation. Every event from trigger.fired through flow.completed shares a flowId. The agent calls getEventLog(flowId="flow_007") and gets the complete execution trace of one trigger — block timings, callback inputs and outputs, error stacks, all of it. Mock Device Kit has no notion of a flow.
13. Voice transcripts as first-class events. trigger.fired carries the recognized transcript and confidence score. trigger.unrecognized carries up to three near-miss triggers ranked by confidence. Mock Device Kit doesn't simulate voice triggers at all, so there's nothing to log.
14. Backend-side log retention. Logs persist for session lifetime + 1 hour, queryable by the agent from anywhere. Mock Device Kit logs die when the app process dies — gone forever after a crash.
15. Replay. Scroll back through everything that happened in the session, including streams, hardware events, and the full event log. Mock Device Kit has no replay.
16. getEventLog MCP tool. The agent can query the event log directly — filter: "errors", filter: "callbacks", flowId: "flow_007", since: <timestamp> — and ingest the structured response. Mock Device Kit has no agent-facing query API.

Things Mock Device Kit literally cannot do

17. Voice-trigger simulation. Real speech recognition through the dev's microphone, with confidence scores and partial-match diagnostics. Mock Device Kit gives you camera and sensor mocks; voice is your problem.
18. TTS playback simulation. Browser sim plays the synthesized speech out loud through the dev's speakers so they can hear what the wearer would hear. Mock Device Kit gives you no audio output simulation.
19. End-to-end trigger → block → callback → speak rehearsal. Browser sim runs the entire AppSpec flow. Mock Device Kit only mocks the SDK; the rest of your flow is your own code.

Architecture and ship-readiness

20. Same API, simulator and production. glasses.camera.capturePhoto() works identically against LocalSimTransport, BrowserSimTransport, and RealMetaTransport. With Mock Device Kit alone, you're writing against the DAT API directly — Extentos gives you a higher-level surface that's stable across simulator and hardware.
21. Pre-test correctness gate. validateIntegration catches spec errors, missing handlers, and capability mismatches before you run anything. Mock Device Kit fails at runtime.
22. Ship-readiness checklist. getProductionChecklist is a tool the agent invokes to verify the app is ready to ship — credential setup, permissions, capability declarations, edge-case coverage. No equivalent for Mock Device Kit.
23. Multi-vendor future. Adding support for Mentra G1, Android XR, Apple smart glasses, etc. means adding a transport implementation to Extentos. The AppSpec, the developer's code, and the agent tooling don't change. Mock Device Kit is Meta-only by definition — every additional vendor is a fresh integration project.
24. Designed for AI agents to operate. 18 deterministic MCP tools the agent calls. Mock Device Kit was designed for human developers writing Android or iOS code by hand against the DAT SDK.

How they stack — example

A developer's day on Meta Ray-Ban with Extentos + Mock Device Kit looks like this:

Morning — design and validate
  Agent: planIntegration → generateConnectionModule → initSpec
  Agent: validateIntegration  ✓ spec is correct

Inner loop — most of the day, browser-driven
  Agent: createSimulatorSession   →  extentos.com/s/<sessionId> opens
  Dev: speaks "summarize this" into laptop mic
       sees photo capture in browser, hears TTS response
       clicks "thermal warning" button to test edge case
  Agent: getEventLog(filter: "errors")  →  zero results, all good
  Dev: edits spec phrase from "summarize" to "describe"
  Agent: updateSpec → validateIntegration  ✓ live in 2 seconds
       → BrowserSimTransport (no Mock Device Kit involved)

Headless CI — fast smoke check
  Test runner spins up LocalSimTransport (uses Mock Device Kit)
  Verifies the spec at least loads and connects
       → LocalSimTransport (Mock Device Kit under the hood)

Real-hardware verification — late afternoon, periodically
  Dev pairs Ray-Ban Meta over Bluetooth, runs app
  Same code, real glasses
       → RealMetaTransport (Meta DAT real SDK)

Evening — ship
  Agent: getProductionChecklist  ✓ ready
  Dev: builds release, submits.

Mock Device Kit's role: under the hood of LocalSimTransport, used in CI and headless tests where a network-free fast path matters. It's not the developer's primary surface; it's a building block.

The browser simulator is the primary surface, because the things developers actually need to validate (does my voice trigger feel right, is the photo timing correct, does the TTS land at the right moment, what does the wearer experience) all live at the app layer.

When to reach for which

Frequently asked questions

Is Extentos a wrapper around Meta's Mock Device Kit?

No. Extentos has three transport implementations: one wraps Meta's real SDK (RealMetaTransport), one wraps Meta's Mock Device Kit (LocalSimTransport), and one is an Extentos-original architecture using a WebSocket protocol and a browser-side hardware surrogate (BrowserSimTransport). Only the second wraps Mock Device Kit.

Can I use Extentos without using Meta's Mock Device Kit at all?

Yes. The BrowserSimTransport does not import or depend on mwdat-mockdevice — it talks to the Extentos backend over WebSocket and uses the developer's webcam/mic via the browser. If you only ever use the browser simulator, Mock Device Kit is never loaded.

Can I use Meta's Mock Device Kit without Extentos?

Yes — Mock Device Kit is shipped by Meta as part of the Device Access Toolkit. You can integrate it directly. You'll write the simulation harness, the trigger logic, the audio routing, the event correlation, the agent integration, and the multi-vendor abstraction yourself.

Does Extentos work with real Ray-Ban Meta glasses?

Yes. RealMetaTransport wraps Meta DAT — mwdat-core + mwdat-camera v0.5.0 on Android (group com.meta.wearable, singular), MWDATCore + MWDATCamera v0.6.0 on iOS via SPM. The same code that runs against the simulator runs against real hardware — only the transport changes.

Does Extentos support other smart-glasses vendors?

Meta Ray-Ban (meta_rayban) is the GA target. Mentra G1, Android XR, and Apple smart glasses are on the roadmap as additional transport implementations. The AppSpec format and developer code are vendor-independent — adding a vendor doesn't break existing code.

Why doesn't Mock Device Kit simulate voice triggers?

Meta's Device Access Toolkit operates at the BLE/SDK layer. Voice triggers in production are recognized by the phone's speech recognizer (SpeechRecognizer on Android, SFSpeechRecognizer on iOS) running on audio streamed from the glasses microphone over Bluetooth HFP/SCO. Mock Device Kit replaces the BLE side of that path; it doesn't try to replace the phone's speech recognizer because the phone is real. Extentos's browser simulator replaces the whole path — using the developer's laptop microphone and a browser-side recognizer — so voice triggers can be exercised end-to-end without glasses or a phone.

What's the cost difference?

Meta's Mock Device Kit is included with Meta DAT and free. Extentos is also free — all 18 MCP tools and LocalSimTransport are free forever, and the browser simulator is free for the first 1000 runtime events on your MCP install. After that, you create a free email-only account to keep going (no payment, no card). There is no paid tier at launch. See pricing for details.

Related concepts

• Architecture — how the MCP server, the SDK, the simulator backend, and your app fit together
• Capabilities — the abstract capabilities (camera, mic, voice, sensors, alerts) that Extentos exposes across vendors
• Vendors: Meta Ray-Ban — the GA capability matrix, what Meta DAT supports today, and what's preview-only
• Quickstart with an AI agent — install the MCP server and see the simulator in action