Background transcription drops audio for non-Omi/OpenGlass/FriendPendant devices when app is closed

[mdmohsin7]

Summary

The Android background BLE transcription feature added in #7483 only routes audio for DeviceType.omi, DeviceType.openglass, and DeviceType.friendPendant. For Limitless, Bee, Plaud, Frame, Fieldy, AppleWatch, and any other supported device, audio captured while the app is closed is silently dropped — no transcript, no conversation, and no error surfaced to the user.

Reproduction

1. Pair any device that is not Omi / OpenGlass / FriendPendant (e.g. Limitless)
2. Start recording from the app
3. Swipe the app away from recents
4. Speak for several minutes
5. Reopen the app

Expected: transcript and conversation populated with what was spoken while the app was closed (per #7483's intent).
Actual: no transcript, no conversation, no error message. Reproduced on a Limitless pendant.

Root cause (code references)

app/lib/providers/capture_provider.dart → _nativeBleAudioTarget returns null for everything except omi, openglass, and friendPendant:

case DeviceType.appleWatch:
case DeviceType.bee:
case DeviceType.fieldy:
case DeviceType.frame:
case DeviceType.limitless:
case DeviceType.plaud:
  return null;

When the target is null, _saveNativeBleStreamConfig writes nativeBleStreamingEnabled=false to SharedPreferences. The native streamer's loadConfig() in app/android/app/src/main/kotlin/com/friend/ios/OmiBackgroundAudioStreamer.kt returns null on that flag, so handleCharacteristic exits before opening any websocket. Every BLE byte from these device types during the app-close window is dropped on the floor.

PR author's own note

This is acknowledged in the PR description:

"Packet handling is currently enabled for Omi/OpenGlass-style audio and Friend Pendant audio. Other BLE device families keep the existing foreground app behavior until their packet parsing and start/stop control flows are mirrored natively."

User impact

Users on Limitless, Bee, Plaud, Frame, and Fieldy silently lose all audio captured during any app-close window. The failure mode is invisible — the user only discovers it on relaunch when they see no transcript or conversation for the period they spoke. No error notification, no log surfaced to the UI.

Possible follow-ups

• Short-term: add per-device packet parsing + UUID mapping for the remaining supported device types to the existing handover architecture (~1 day per device type, plus testing).
• Long-term: address as part of a larger move of socket lifecycle to native (separate internal discussion).

---

Posted by Charles (AI agent) acting on behalf of @mdmohsin7. Reproduction, root-cause analysis, and recommendations are the agent's independent work.

[rootslv]

Apple Watch Series 10 — confirmed reproduction + user impact

I can reproduce this issue with Apple Watch Series 10 as the paired device.

Observed behavior:

• Connection drops frequently during active use
• As soon as the app is backgrounded or the iPhone screen locks, all audio is silently dropped — no error, no notification
• After reconnecting, transcription does not resume automatically even though the device shows as connected in the UI
• The user has no way to know a recording was lost until they reopen the app

Why this matters for Apple Watch specifically:
Apple Watch is a natural fit for Omi — it's always on the wrist, has a microphone, and users expect it to work passively. The current silent-drop behavior is especially painful here because the use case is inherently hands-free and background. Users won't be staring at their phone while wearing a Watch.

Willingness to contribute:
I'm interested in helping implement native BLE background streaming support for DeviceType.appleWatch. Could someone from the team point me to:

1. The best reference implementation to follow (I see friendPendant is the simplest existing example)
2. The expected audio packet format / UUID characteristics for Apple Watch
3. Whether there's any watchOS-side native code that also needs updating

Happy to open a draft PR once I have a clearer picture of the expected architecture. This is a P1 for real-world Apple Watch users.