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. Meta's Mock Device Kit is Meta's own transport-layer tool — Extentos doesn't use it internally (the local sim is Extentos's own in-memory transport). Extentos's 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 can benefit from both — Meta's kit used directly for wire-level checks, Extentos's simulators for everything app-level.

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 wake-phrase matching, 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
• Voice transcripts can be injected from the browser UI and via MCP tools (hardware-alert injection buttons are roadmap — the SDK has no consumer API for those alerts yet)
• Every event flows through Extentos's structured 7-chip event log (errors / voice / camera / display / ai / lifecycle / custom) 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 handler code defines what your glasses app does — wake-phrase matching, photo capture, AI calls, TTS response. The simulator runs that code exactly as production would, against a hardware surrogate the developer drives through a familiar browser UI.

Where Meta's Mock Device Kit fits next to Extentos's transports

Extentos has four transport implementations behind its GlassesTransport interface. None of them wraps Meta's Mock Device Kit — the local sim is Extentos's own in-memory transport:

So the precise answer: Extentos uses Mock Device Kit nowhere — LocalSimTransport is Extentos's own in-memory fast path for inner-loop testing without a network round-trip, and BrowserSimTransport is the higher-level simulator where the developer spends the bulk of their time. Meta's kit remains available to you directly when you want wire-level simulation.

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 says "summarize this", the handler matches the wake phrase, the camera captures a frame, the handler 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 wake phrase match against real STT output with reasonable variance tolerance? (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. Higher-level SDK on top of the SDK. Your handler code subscribes to capability primitives (glasses.audio.transcriptions(), glasses.camera.capturePhoto(), glasses.audio.speak(), …) instead of the raw DAT call surface. Same primitives across simulator and production — you write the handler once, it runs on the laptop simulator and on real Ray-Ban Meta glasses without changes. Mock Device Kit gives you a mocked DAT SDK; you write the rest of the abstraction layer yourself.
4. Reattach without remint. Rebuild + reinstall your app and it auto-reattaches to the same persistent simulator session — the URL is stable, no fresh-mint required. Mock Device Kit re-runs the mock pairing from scratch on every app launch.
5. No browser/mobile context switch for the inner loop. Browser simulation runs without an Android emulator or iOS Simulator window even open (your device or emulator runs your real app code, the simulated hardware is in the browser). Mock Device Kit needs the emulator/device app actually running.

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. Input injection (transcripts today). The browser UI and injectTranscript fire voice input; hardware-event buttons (thermal_warning, hinges_closed, audio_route_changed, incoming_call_detected, app_lifecycle_changed) are roadmap — the SDK exposes no consumer API for those alerts yet. 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. Routing conflicts surface as CoexistenceBlocked errors on the affected call (the coexistence.warning runtime event is declared but not yet emitted). Mock Device Kit doesn't simulate this Bluetooth audio-profile interaction either.

Debugging the AI agent can use

11. 7-chip structured event log. Every event is tagged with one of errors, voice, camera, display, ai, lifecycle, or custom — one label per event, with errors absorbing severity≥warn regardless of modality so failures find a single home. Mock Device Kit logs are raw DAT-level Logcat / os_log output — unstructured, unfiltered, untagged.
12. Capability-call correlation. Each capability invocation (record_discrete, capture_photo, speak, …) emits a request + result/completed event with a stable id, plus any failures (which route to the errors chip). The agent calls getEventLog(filter="voice") and gets every audio call's lifecycle — request, result, completed — in order. Mock Device Kit has no per-call event model.
13. Voice transcripts as first-class events. The library emits audio.transcriptions events with the transcript text + confidence score + final/partial flag. Your handler matches them; the agent debugs them via getEventLog. Mock Device Kit doesn't simulate voice transcription at all, so there's nothing to log.
14. Backend-side log retention. Logs persist for 48 hours after each event, 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: "voice", filter: "camera", plus an opaque cursor for incremental reads — and ingest the structured response. Mock Device Kit has no agent-facing query API.

Things Mock Device Kit literally cannot do

17. Voice-recognition 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 wake → record → LLM → speak rehearsal. Browser sim runs the entire handler code path. Mock Device Kit only mocks the SDK; the rest of your flow is your own code without an environment to exercise it in.

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 missing dependencies, bootstrap wiring gaps, permission/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, demonstrated. A second and third vendor mean second and third transport implementations inside Extentos, not a rewrite of your app: Android XR landed in 2026-07 without changing a single app-facing API, and the same handler code runs under an Android XR device identity in the simulator today (status). Mock Device Kit is Meta-only by definition — every additional vendor is a fresh integration project.
24. Designed for AI agents to operate. A tight, deterministic MCP tool surface (capability discovery, code-example reference, scaffolding, validation, simulator orchestration, debug log query) 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 looks like this:

Morning — design and validate
  Agent: getPlatformInfo → getCodeExample(pattern) → getCapabilityGuide(...)
  Agent: generateConnectionModule
  Agent: <writes handler classes against the SDK primitives>
  Agent: validateIntegration  ✓ wired correctly

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 handler — changes wake-phrase string from "summarize" to "describe"
  Dev: rebuild + reinstall  ✓ app auto-attaches to same session
       → BrowserSimTransport (no Mock Device Kit involved)

Headless CI — fast smoke check
  Test runner spins up LocalSimTransport (Extentos's in-memory local sim)
  Verifies the bootstrap connects and the handler subscribes cleanly
       → LocalSimTransport (in-memory, no DAT SDK)

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

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

Mock Device Kit's role: Meta's own wire-level building block, available to you directly when you want BLE/SDK-layer simulation. Extentos's network-free fast path for CI and headless tests is LocalSimTransport — its own in-memory transport.

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 four transport implementations: one is the vendorless system-audio baseline (SystemAudioTransport), one wraps Meta's real SDK (RealMetaTransport), one is Extentos's own in-memory local sim (LocalSimTransport — no DAT SDK, no network), and one is an Extentos-original architecture using a WebSocket protocol and a browser-side hardware surrogate (BrowserSimTransport). Meta's Mock Device Kit remains Meta's own separate tool for transport-layer testing.

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 + mwdat-display v0.8.0 on Android (group com.meta.wearable, singular), MWDATCore + MWDATCamera v0.8.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 smart glasses (vendor token meta) are the GA target. Android XR is in preview: the projected transport is built and proven on Google's emulator, and the simulator carries an Android XR device identity, but the module is unpublished and no hardware is buyable. Brilliant Labs (brilliant) is preview the other way round: the BLE transport, on-device Lua bundle and display translation are built and published, and Halo is on sale — but no device has run any of it, and there is no emulator standing in either. Apple smart glasses await a third-party SDK. The SDK surface and your handler 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 on the phone — on-device Vosk on Android hardware (the platform recognizer on the dev path), 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 free for the whole dev loop — the discovery, validation, guidance, and search MCP tools work without an account, and so do LocalSimTransport and real-hardware testing via your own Meta DAT credentials. A free email-only account (Google sign-in, or email + password — no payment, no card) covers browser-simulator session minting at extentos.com/s, the generateConnectionModule scaffold step, and the account-scoped project tools. Once linked, sessions and the events they emit are unlimited. The one metered surface is the managed AI gateway — prepaid credits, with $2 free to start. 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
• From simulator to real glasses — when you're ready for hardware: the transport switch, Meta credentials, and the verification pass
• Quickstart with an AI agent — install the MCP server and see the simulator in action

Related