Developer preview
Audio & wake events
Understand the separate control and audio paths before building voice notes or an assistant workflow.
Two channels, two readiness states
| Path | How it is intended to work |
|---|---|
| Control/events | Glasses → Bluetooth control connection → SDK callback → mobile app state transition. |
| Audio | Glasses microphone → Bluetooth headset/HFP route → mobile OS audio input → app/SDK capture → your service. Playback returns through the phone’s audio route. |
Bluetooth control readiness does not establish microphone routing or audio readiness. Your app still handles permission, audio session/route changes, interruptions and lifecycle. The mobile operating system manages the headset audio route separately from device control.
Wake word to app handoff
Wake-word recognition and device commands run in device firmware. A supported wake event may notify your app so it can begin its own assistant session. Your app and backend own the AI service and its business logic.
Do not assume a wake event can launch an arbitrary terminated app or start microphone capture without OS constraints. Validate foreground, background, locked-screen and interruption behavior on each supported phone/OS combination. Treat unknown trigger IDs as unknown events rather than assigning guessed actions.
Voice-note target workflow
- The app obtains microphone permission, prepares file writing and registers the planned PCM callback.
- Call
startVoiceNote(); retain the task’s note ID. - Persist incoming audio after the actual HFP route and device indicator are ready.
- Request stop, then wait for
FinalizationRequired. - Drain the writer queue and finalize the app’s file.
- Call
finishVoiceNote()with the real save result; inspect the task’s terminal outcome.
These notes are saved through the phone app. Use the SDK release documentation to understand where voice-note data is stored.
EQ in the preview
EQ operations are shown as an illustrative integration pattern. Read the actual preset list, select an advertised preset, then read or write the selected custom curve. Follow the returned events; hardware behavior and the second custom slot still require firmware integration.
// After Connection("ready"):
sdk.readEqPresets()
// In EqPresets: show the actual preset IDs to the user.
// After explicit selection:
sdk.selectEqPreset(presetID = selectedPresetID)
// Wait for EqState confirming that selection, then:
sdk.readEqCurve()
// Render EqCurveRead. Do not invent frequency/gain limits.