[iOS Bug] Recording silently stops on incoming call but app shows it as ongoing

[omi-discord-vector]

Bug Report: iOS audio session not properly detected as interrupted when incoming call is ignored

Device/App: iOS 1.0.526 (782), iOS 26.3, iPhone 15 Pro

Behavior:
When recording with the iOS app and an incoming call arrives (even if ignored/declined), iOS forcibly interrupts the audio session. The app continues to show recording as active (Dynamic Island red indicator disappears, but in-app UI shows ongoing recording), however the actual audio capture has stopped. The resulting recording is cut off at the point of interruption and does not resume.

Expected Behavior:

• App should detect the audio session interruption and either:
  1. Automatically resume recording after the call is dismissed
  2. Accurately reflect that recording has stopped (not show as ongoing)
  3. Send a push notification alerting the user that recording was interrupted, with an option to resume

Bug (confirmed):

• App UI shows recording as ongoing after ignored call — this is incorrect and should be fixed regardless of auto-resume capability

Suggested Fixes / Enhancements (in priority order):

1. Auto-resume: Listen for AVAudioSession.interruptionNotification with type .ended and automatically restart the audio session + recording
2. Accurate UI state: If auto-resume isn't possible, update the recording state to stopped/interrupted so the UI is truthful
3. Push notification on interruption: Notify user that recording was cut off with an inline "Resume" button
4. Optional call blocking mode: Allow users to opt into Do Not Disturb during active recordings

Additional context:

• Does NOT affect Omi hardware device recordings (device records locally, unaffected by phone audio interruptions)
• Frequency: potentially high — incoming calls during meetings are common
• User impact: silent data loss (user thinks they have a full recording, they don't)

Steps to reproduce:

1. Start recording in the iOS Omi app
2. Receive an incoming call and ignore/decline it
3. Continue the session, then stop recording
4. Check the resulting transcript — it will be cut off at step 2
5. Note the in-app UI showed recording as active throughout

[beastoin]

Hey @mdmohsin7 — this one's in your territory (phone call feature). Incoming calls on iOS kill the audio session even if declined, but the app keeps showing recording active. Mind taking a look?

[mdmohsin7]

This is a different case (because phone call feature does not support incoming calls). Likely the socket drops during call and does not reconnect at all

[beastoin]

ops sry my slop btw can you help on this one?

[mdmohsin7]

ops sry my slop btw can you help on this one?

sure

[mdmohsin7]

Dug into this end-to-end. The root cause is at the native iOS audio layer, not just the WebSocket — here's the full chain:

What actually happens on an incoming iOS call (declined or answered):

1. iOS interrupts the shared AVAudioSession, which suspends the AVAudioEngine that flutter_sound uses under the hood for phone-mic capture.
2. flutter_sound's input tap stops firing → onByteReceived at app/lib/providers/capture_provider.dart:959 receives nothing.
3. No AVAudioSession.interruptionNotification observer is registered anywhere in the iOS code — zero hits across app/ios/** for interruptionNotification / AVAudioSessionInterruption. AppDelegate.swift:107-114 only configures the session for Bluetooth; RecorderHostApiImpl.swift uses AVAudioSession only for permission checks. Nothing catches .ended and restarts capture, so the engine stays paused for the entire call and remains paused after the call ends. That's why the mic never comes back in the same session — the Dynamic Island indicator vanishing is iOS telling us the mic is truly off.
4. Because bytes stop flowing, the WAL write at capture_provider.dart:964 buffers nothing for the gap period. No audio to recover.
5. Meanwhile recordingState is never reset: onClosed at :1030 sets _transcriptServiceReady = false but leaves recordingState == RecordingState.record, so the in-app UI keeps rendering "recording."
6. The transcription WebSocket eventually drops (idle). Keep-alive reconnects every 15s (:1050, :1078-1084). On reconnect, onConnectionStateChanged(true) triggers recoverOrphanedWals() (:1595-1600, services/wals/local_wal_sync.dart:435-440). Works correctly, but there's nothing to recover because nothing was captured in the first place.

Why data loss is permanent: the WAL → backend recovery path (syncLocalFilesV2 at capture_provider.dart:1345, 1385) is designed for the case where frames are captured but not transmitted. Here the frames never exist, so recovery cannot help.

Re: @mdmohsin7's socket theory — you were right that this isn't the Twilio phone-call feature, and right that the pipeline silently breaks. Two small corrections from the trace: the socket does reconnect (15s keep-alive, not "never"), and the primary failure is upstream of the socket — at the native audio layer. Fixing only the socket won't help.

Three independent gaps (findings, not a proposed fix):

• A. Missing interruption observer. No code registers for AVAudioSession.interruptionNotification. The audio engine is never resumed after an interruption's .ended event, so capture is dead for the remainder of the session.
• B. recordingState doesn't reflect failure. capture_provider.dart:1030 onClosed() updates the transcript-ready flag but not the recording state. The UI has no signal that the pipeline has stalled.
• C. No heartbeat on the mic byte stream. services/services.dart:324-329 listens with no timeout, so an indefinite absence of bytes is indistinguishable from silence. Nothing detects the mic going dead.

No PR yet per the manager's instruction — findings only.

— caleb