Hardware events

What Meta Ray-Ban surfaces today via glasses.runtime.events, connection.state, and toggles — and which hardware-alert streams aren't exposed yet. No IMU API.

There is no IMU, head-pose, accelerometer, gyroscope, or gaze stream on Meta Ray-Ban. The Meta Device Access Toolkit does not expose raw motion sensors to third-party apps, and there is no phone-side workaround. If you've seen those promised elsewhere, it was aspirational — they are not part of the SDK. This page documents what the glasses do surface today and what's on the roadmap.

What you get today is a runtime event stream plus a set of hardware conditions that surface through connection state and toggles. This page covers both, honestly scoped to what ships.

Kotlin leads the snippets and is the source of truth; the iOS surface mirrors it via glasses.runtime.events.

The runtime event stream

glasses.runtime.events is a Flow<RuntimeEvent> — the on-device event log surfaced to your app. RuntimeEvent is a sealed interface; subscribe and filterIsInstance for the variant you care about:

import com.extentos.glasses.core.RuntimeEvent

scope.launch {
    glasses.runtime.events.collect { event ->
        when (event) {
            is RuntimeEvent.ToggleChanged ->
                // a runtime toggle changed (key, oldValue, newValue, source)
                onToggle(event.key, event.newValue)
            is RuntimeEvent.CoexistenceWarning ->
                // an audio/video coexistence conflict (blocked, reason)
                warnUser(event.reason)
            is RuntimeEvent.UnrecognizedUtterance ->
                // STT produced text that matched no registered phrase (rawTranscript)
                maybeSuggestHelp(event.rawTranscript)
            is RuntimeEvent.Log ->
                // a diagnostic log line (level, message, payload?)
                Unit
            is RuntimeEvent.Assistant ->
                // a Phase-4 assistant lifecycle event — see the assistant runtime
                Unit
        }
    }
}

The variants that ship today:

Variant	Payload	Fires when
`ToggleChanged`	`key, oldValue, newValue, source`	A runtime toggle is mutated (by UI, voice command, or automation).
`CoexistenceWarning`	`blocked, reason`	Declared, not yet emitted — routing conflicts currently surface as `CoexistenceBlocked` errors on the affected call.
`UnrecognizedUtterance`	`rawTranscript`	Declared, not yet emitted — post-pivot the library does no phrase dispatch; match transcripts in your own handler.
`Log`	`level, message, payload?`	The library emits a diagnostic line.
`Assistant`	`event: AssistantEvent`	A Phase-4 assistant runtime lifecycle event (session start/end, user/assistant spoke, tool called, reconnected, error).

snapshotEvents() returns the current buffer as a List<RuntimeEvent> if you'd rather poll than collect. In the browser simulator the same events flow to the structured event log (chips: errors / voice / camera / display / lifecycle / custom), queryable with getEventLog.

Hardware conditions you can observe today

Two physical conditions of the glasses are surfaced — not as a sensor stream, but through the surfaces that already exist:

Thermal and hinge state → `connection.state`

A fold — and, on the phone side, thermal pressure — ends the session. Today the drop arrives as Disconnected(DisconnectCause.DeviceDroppedConnection); the dedicated typed causes below are declared but not yet produced by the core:

Thermal critical (a phone-side PowerManager signal, not a glasses sensor) → reserved cause DisconnectCause.ThermalCritical. Flipping battery_save_mode on before reconnecting is still a good response to heat.
Hinges folded → reserved cause DisconnectCause.HingesClosed (DAT doesn't expose hinge position; the fold shows up as the session ending).

Observe these the same way you handle any disconnect — branch on Disconnected.cause. See Handle disconnects for the full pattern. (A continuous, non-disconnecting thermal/hinge event stream with severity and temperature is planned — see below — but today these conditions are observable only at the point they drop the connection.)

Battery-save and stream clamping → toggles + events

When battery_save_mode is on (set by the user, or by your app in response to thermal pressure), the library clamps any videoFrames stream to LOW resolution + 2 fps regardless of the config you requested, and emits a camera_stream_clamped event carrying the requested-vs-effective resolution/fps so the downgrade is observable. Observe battery_save_mode via glasses.toggles.state, and watch for the clamp in the event log. This is the signal to pair high-fps video streams with a downgrade path.

Planned, not yet exposed

The Meta DAT SDK and the Extentos transport carry several hardware/lifecycle alerts internally, but the last hop to customer code is not connected yet — there is no consumer API for these as of the current release. Don't build against them; they are listed here so you know they're coming and don't mistake their absence for a bug:

Planned event	Intended payload	Status
`thermal_warning`	`{ severity, temperatureCelsius }`	Future — today only via `Disconnected(ThermalCritical)` + `battery_save_mode`.
`hinges_closed`	hinge fold/unfold	Future — today only via `Disconnected(HingesClosed)`.
`audio_route_changed`	`{ from, to }`	Future — no consumer API yet.
`incoming_call_detected`	`{ callerNumber, callerName }`	Future — no consumer API yet.
`app_lifecycle_changed`	`{ state }`	Future — no consumer API yet.
`location_updated`	`{ latitude, longitude, accuracyMeters }`	Future — no consumer API yet.
`phone_notification_forwarded`	forwarded phone notification	Future — the `NotificationListenerService` emits it into the transport, but it isn't relayed to customer code yet.

Two other sensor surfaces are earlier-stage research, not committed: ambient_light_updated and a tap_gesture (custom tap/swipe gestures are not in the public DAT toolkit — only phone-side buttons and voice are developer-accessible). Check getPlatformInfo for the live status of each, and the Meta vendor page for the GA capability matrix.

Handle disconnects — branch on Disconnected.cause to react to thermal/hinge conditions.
Capabilities — the full capability catalog and what's GA vs future.
Vendors: Meta Ray-Ban — the GA capability matrix and DAT constraints.
Assistant runtime — RuntimeEvent.Assistant lifecycle events.

Handle disconnects

Observe glasses.connection.state, branch on the typed Disconnected.cause to tell a user-pulled-the-glasses-off from a Bluetooth drop, and reconnect cleanly. The connection-state spine for any Meta Ray-Ban app.

Capabilities

The Extentos capability vocabulary — the vendor-agnostic SDK primitives (audio, camera, voice, assistant, display, hardware events) your handler subscribes to.

Meta smart glasses (Meta DAT)

Meta smart glasses developer guide: Wearables Device Access Toolkit (DAT 0.8.0) capabilities, supported models (Ray-Ban Meta, Oakley Meta, Ray-Ban Display), 2026 distribution state, and how Extentos abstracts the toolkit.

Error reference

Every typed error the Extentos SDK can return — ConnectError, CaptureError, AudioError, TransportError, the ExtentosError umbrella, and the Meta-DAT DeviceSessionError — with their payload fields and meaning. Lifecycle operations return ExtentosResult<T, E> with these concrete failure variants rather than throwing; pattern-match them. Generated from the Rust core.