Is your feature request related to a problem? Please describe.
The Bluetooth SDK exposes continuous microphone PCM, which is excellent for live processing. But applications that need to save a recording must build and maintain their own recorder pipeline: file writing, finalization, interruptions, Android background execution, and recovery after the app UI is restarted.
This is difficult for React Native and other cross-platform apps, especially when recording should continue while the phone is locked or the app is backgrounded.
Describe the solution you'd like
Provide a native, durable microphone-recording capability in @mentra/bluetooth-sdk.
The SDK should own the platform-specific work of receiving glasses microphone audio, writing a valid audio file, and keeping an active recording reliable in the background. Apps should retain control of when recording starts and stops and where the final file is stored.
An Android-first API could include:
- Start recording to an app-provided destination URI.
- Stop and finalize the recording.
- Read active-recording status.
- Recover or report an interrupted recording after the app restarts.
- Clear lifecycle events for started, finalized, interrupted, disconnected, and failed recordings.
- Background/locked-device support through the SDK’s native foreground-service contract.
- Support for app-owned Android SAF
content:// destinations.
WAV would be a useful first format because it can preserve the incoming PCM with minimal processing. AAC/M4A or other efficient formats could follow or be supported as options.
This should not change the existing PCM event API; apps that need live processing or their own encoder should continue to receive raw audio as they do today. It also should not imply any glasses-button binding—the host app decides how recording is triggered.
Describe alternatives you've considered
An app can write WAV from the PCM events itself. That is workable for foreground-only use cases, but it does not provide a reliable background lifecycle in a normal React Native app.
MentraOS’s Recorder miniapp demonstrates durable recording inside the MentraOS runtime, but third-party SDK apps do not have its persistent miniapp runtime or host-managed blob store.
Additional context
A built-in primitive would let mobile apps save recordings directly into their own storage, sync/transcribe them with their own services, and apply their own privacy, retention, and sharing policies. Happy to share a proposed patch if you think this makes sense.
Is your feature request related to a problem? Please describe.
The Bluetooth SDK exposes continuous microphone PCM, which is excellent for live processing. But applications that need to save a recording must build and maintain their own recorder pipeline: file writing, finalization, interruptions, Android background execution, and recovery after the app UI is restarted.
This is difficult for React Native and other cross-platform apps, especially when recording should continue while the phone is locked or the app is backgrounded.
Describe the solution you'd like
Provide a native, durable microphone-recording capability in
@mentra/bluetooth-sdk.The SDK should own the platform-specific work of receiving glasses microphone audio, writing a valid audio file, and keeping an active recording reliable in the background. Apps should retain control of when recording starts and stops and where the final file is stored.
An Android-first API could include:
content://destinations.WAV would be a useful first format because it can preserve the incoming PCM with minimal processing. AAC/M4A or other efficient formats could follow or be supported as options.
This should not change the existing PCM event API; apps that need live processing or their own encoder should continue to receive raw audio as they do today. It also should not imply any glasses-button binding—the host app decides how recording is triggered.
Describe alternatives you've considered
An app can write WAV from the PCM events itself. That is workable for foreground-only use cases, but it does not provide a reliable background lifecycle in a normal React Native app.
MentraOS’s Recorder miniapp demonstrates durable recording inside the MentraOS runtime, but third-party SDK apps do not have its persistent miniapp runtime or host-managed blob store.
Additional context
A built-in primitive would let mobile apps save recordings directly into their own storage, sync/transcribe them with their own services, and apply their own privacy, retention, and sharing policies. Happy to share a proposed patch if you think this makes sense.