[fix] the recording survives leaving the foreground, and one tap means one recording

[YJack0000]

What this changes

The phone stops losing the microphone when the meeting is not on screen, one tap stops being able to start two recordings, and recording begins when the button is pressed instead of one network round trip later. Android gets the two robustness gaps it shared with iOS, plus the same latency fix.

Why

Three reports from dogfooding, which turned out to be three faces of one thing: nothing owned the recording. LiveView kept the capture, the relay and the uploader in @State and only set isRecording once all of them were up.

1. The meeting died after switching apps

UIBackgroundModes: audio keeps the process alive, but it says nothing about iOS taking the microphone back — and there are four ways it does, every one of them routine while the user is in another app. AudioCapture listened for none.

What happens	Notification	Result before
Call, Siri, alarm, another app opening a recording session	interruptionNotification	engine stops; nothing restarts it
Headphones/Bluetooth in or out, speaker override	routeChangeNotification	a tap built for the old format keeps feeding a dead node
The engine's IO format changes underneath it	.AVAudioEngineConfigurationChange	AVAudioEngine tears the tap down itself
mediaserverd restarts	mediaServicesWereResetNotification	every audio object in the process is dead

All four look identical from outside: the app is still up, isRecording is still true, the level meter sits at zero for the rest of the meeting, and about a minute later the relay idle-closes for want of audio and the screen says "Relay closed". It reads as a dropped connection. The network was never the problem — the microphone died first.

AudioCapture now treats capture as something to hold: all four notifications observed, engine + tap + converter rebuilt on each, backoff retry, and a two-second watchdog for what iOS announces to nobody (a route that never came back, an interruption that never posted .ended). Transitions surface through onStatus, so the screen says the microphone is paused rather than going quietly silent; a microphone that is genuinely gone ends the meeting properly instead of recording nothing.

2. Two sockets transcribing one room

Not a subtle race — a window you can hit on purpose:

sequenceDiagram
    participant U as User
    participant V as LiveView
    participant R as Relay
    U->>V: tap → consent → start()
    Note over V: isRecording is still false
    V->>R: await client.start() — TLS + HTTP upgrade
    U->>V: button still says "Start recording" → tap again
    Note over V: second start()
    V->>R: a second socket, a second AVAudioEngine, a second uploader
    R-->>V: both legs write segments into one transcript
    Note over V: self.relay holds only the last one;<br/>the first keeps streaming, unreferenced

Loading

MeetingRecorder makes the state machine the type. phase moves to .starting synchronously on the tap, start()/stop() are guarded by it, and the button reads it rather than a success flag. No amount of care inside start() fixes this while "am I recording?" is a flag set at the end.

3. Seconds before recording began

The relay handshake blocked the microphone, and setActive(true) — which negotiates the route, and takes its time when a Bluetooth device is around — ran on the main actor.

	before	after
tap → visible feedback	after everything succeeds	same tick
tap → microphone open	after the handshake, on the main thread	immediately, off the main actor
handshake	blocking	alongside; the client buffers what the mic gives it until the socket is up

Two more the same code hid

• Chunk order was not guaranteed. Every chunk was its own Task { await client.send(pcm:) } — one unstructured task per 85 ms of audio, with no ordering between them. The provider could be handed speech with two chunks swapped and would faithfully transcribe the garble. A single writer now drains an AsyncStream, which also bounds the queue and is what makes the connect window safe to record through.
• A closed socket ended live transcription for good. It now reconnects with backoff while the microphone keeps running. Each leg needs its own segment-id prefix and time offset: the provider restarts its numbering and its clock at zero, so the second leg's mix-0 would otherwise overwrite the opening of the meeting. Covered by a new test on both platforms.

Nothing about the audio file depends on the socket, so a dropped relay costs live transcript, not the recording — and the cloud transcribes the uploaded audio anyway. That is why this reconnects quietly instead of failing the meeting.

Dictation shares AudioCapture and the relay client, so it picks up the interruption recovery, the off-main-actor start and the ordered writer for free.

Android

Already the healthier pipeline — foreground service, explicit state machine, ordered chunks, double-start guarded — so this is the gaps it shared, plus the latency win:

• A silenced microphone was invisible. MicCapture documents the case and leaves it: from Android 10, when another app takes the microphone the framework does not fail, it feeds silence, and AudioRecord.read keeps returning success. A meeting could record forty minutes of nothing and report no problem. MeetingSession now registers an AudioRecordingCallback and publishes micSilenced; the screen shows it in error colour. The recording deliberately keeps running — the takeover usually ends by itself and what follows is still worth having.
• A dropped relay never came back — same reconnect, same per-leg id prefix and time offset.
• The microphone waited on the handshake. connect() splits into open() + awaitOpen(). The config frame is queued as soon as the socket is created; OkHttp buffers frames until the upgrade lands and writes them in order, so it is guaranteed to reach the relay ahead of any audio.

Related: #109 is the same class of bug (never more than one active listener) on desktop voice typing. This PR does not touch that path, so it does not close it.

How it was verified

• bunx tsc --noEmit passes
• bunx vitest run passes (231 tests) — no TypeScript changed, run to confirm the base is clean
• Added or updated tests — reconnected-leg ids and rebased timestamps, SegmentBuilderTests.swift and SegmentBuilderTest.kt
• Added new user-facing strings to both zh-Hant and en — 10 in ios/App/Parley/Localizable.xcstrings, 1 in android/.../res/values*/strings.xml (this PR adds no src/i18n/messages.ts strings)
• swift test — 20 tests
• xcodebuild Debug and Release
• ./gradlew :app:compileDebugKotlin :app:testDebugUnitTest :parleykit:test
• Ran the app — the interruption and route paths cannot be exercised in the simulator. Device checks below.

Device checks before this goes in a build

Do this mid-recording	Expect
Switch to another app playing audio / open Voice Memos	"Microphone paused by the system", then "Microphone is back" on release; transcript resumes
Take a call and hang up	same; recovers within ~0.25 s of the call ending
Plug and unplug AirPods	brief gap, then the level meter moves again
Airplane mode for 30 s, then off	"Transcription dropped — reconnecting…" → "Transcribing live", and the opening of the meeting is not overwritten
Press record five times fast	exactly one meeting; from the second press the button already reads "End meeting"

Known limitation, deliberately not addressed

The record button is inert while a finished meeting uploads ("Wrapping up…"). A long meeting on cellular can hold that for minutes. Fixing it means splitting MeetingUploader.finishAndUpload into "persist to the pending queue" and "upload", and releasing the button after the first. Left out on purpose: closing the two-meetings-at-once hole first is the safer order.

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud