Status: preview (Phase 1). The Mentra OEM Integration Engine covers the full Phase-1 surface
documented below. Firmware OTA and the media gallery are intentionally
deferred to a later phase. The runtime is not yet packaged for external install —
reach out to help@mentra.glass to integrate today.
What it is
The Mentra OEM Integration Engine is the API an OEM host app (the phone-side app that talks to your glasses) calls to run MentraOS. It ships as the@mentra/engine module and
exposes a single namespaced object, engine:
- The host owns UI, navigation, and login. Your screens, your router, your auth.
- The engine owns the runtime and the device. Connection, device state, wifi, on-device speech models, the display pipeline, the miniapp runtime.
engine.<domain>.<method>() for everything
device- and runtime-related. The engine is device-agnostic: the same calls work
across glasses models.
Lifecycle
The host hands the engine its auth + config once, then starts it.auth.getSubjectToken() is the only must-have seam — the host owns login and returns
a fresh token on demand; the engine owns everything downstream.
engine.glasses
Connection actions, a curated status/info read-model, capabilities, version, and the
discrete input events.
Connection
Status & info (read-models)
status() returns a snapshot projected from the runtime’s glasses store, in a stable
shape that doesn’t leak the internal store layout:
Input events
on*() returns an unsubscribe function.
engine.glasses.wifi
connect() propagates the bluetooth layer’s coded errors (bluetooth_powered_off,
request_timeout, …) unchanged, so your UI keeps its own error mapping.
engine.glasses.settings
Keyed device settings (brightness, head-up angle, dashboard, camera/button,
sensing, …). set() persists and auto-syncs to the connected glasses.
available() is the authoritative list at runtime (it varies by model/capabilities).
The current keys, their types, and defaults:
Device identity (paired-device id/name/address, controller address) and internal
runtime flags (e.g. STT-fallback state) are intentionally not in this surface —
read the connected device via
engine.glasses.info().engine.pairing
First-time glasses discovery + pairing. (Reconnecting the already-paired default is
engine.glasses.connectDefault().)
engine.speech
On-device STT/TTS model management.
engine.display.mirror
A typed read facade for a phone-side preview of the glasses screen.
engine.session
The cloud (cloud-v2) live-session surface. engine owns the cloud client — it
constructs it from engine-owned transports + the auth you passed to
configure() — so this reads the session it manages.
status is one of connected | connecting | reconnecting | disconnected;
audioTransport is udp | ws | offline | none.
engine.settings
Typed keyed user settings over the engine-owned settings store.
engine.reports
Bug report and feedback submission. The OEM writes its own report screen,
trigger labels, rating controls, and screenshot picker UX; engine owns runtime
context collection, recent phone logs, Cloud V2 submission, artifact upload,
dedupe, and glasses notification.
engine.dev
Developer/debug surface — backend + cloud-v2 URL overrides, reconnect, version gate.
engine.permissions
OS permissions — the raw check/request ops (your UI adds the rationale dialogs).
microphone · camera · calendar · location · background_location · bluetooth · phone_state · post_notifications.
engine.phoneNotifications
Forward phone notifications to the glasses, with a per-app blocklist. Android-only
(getters return safe defaults on iOS).
engine.notifications
Inbound alerts engine→host — conditions engine detects, your UI renders.
engine.miniapps
Miniapp lifecycle. The miniapp WebView is a host component — engine ships the
bridge primitives (buildMiniappGlobalsScript, buildMentraUiShim, the MentraJS
router), exported from @mentra/engine directly; your app mounts the <WebView> and
wires it to those. This facade is the lifecycle half.
engine.stores.* — escape hatch (not the OEM contract)
The raw device-state stores are also exposed under engine.stores
(glasses, display, core, connection, gallerySync, cloudClientStatus,
settings) so the first-party Mentra App can keep using them directly during migration.
What the host provides
The boundary is small and explicit: the host provides its UI, its login, and optional config — engine owns the entire runtime. The only required seam isauth.getSubjectToken (passed to configure()); engine owns token exchange, refresh,
storage, the cloud client, glasses/BLE, settings, speech, display, and the miniapp
runtime from there.
You may see internal
configureRuntime(...) wiring in the first-party Mentra App —
that’s transitional scaffolding for migrating Mentra’s own screens, not part of
the OEM contract. It deletes itself as each domain lands in engine. An OEM only ever
calls configure({auth, config?}) + start().
