Direct answer
An audio route change is an input-pipeline event, not merely a headset icon update. The application should observe audio-device connection changes, inspect the current recording state, and then follow a documented policy: continue only if the active capture path is still valid and the format contract is unchanged; otherwise stop or invalidate the affected segment, preserve already completed segments, expose the interruption, and let the user resume deliberately. Android provides audio-device callbacks for connection and disconnection events, but an event is not proof that an active AudioRecord instance has transparently switched to a suitable source or that the samples retain the expected properties. The app must verify the behavior it relies on. This matters for speech pipelines because recorded PCM is often segmented and fed into inference sequentially. In the current Cove Voice implementation, TranscriptionPipeline processes PCM segments sequentially through the shared inference engine, merges non-empty results, and preserves a visible placeholder for a segment that fails. That is a useful explicit failure behavior, but it does not establish every Bluetooth route, format, or device combination. Route changes should therefore become part of the pipeline’s recorded state, so the interface does not merge unrelated or malformed input as if it were one uninterrupted recording. Use a state machine that names route identity, capture status, format, segment index, partial transcript, and interruption reason. When a route changes, do not silently relabel the source or assume a sample rate conversion occurred. Decide whether the recording API reports a routing change for the actual session, whether the recorder remains active, and how you can observe the selected device. If the platform or chosen API does not expose enough evidence, state that limitation and fail safely rather than asserting continuity. Keep microphone permission, foreground capture disclosure where applicable, and user stop controls intact across every transition. The test set should include device add and removal, a route change during a quiet interval, a route change while audio is being written, a route change between segments, and a user cancel at the same time. For each, record the route event, recorder result, sample format, completed segment IDs, failed segment IDs, visible transcript state, cleanup, and whether the next recording can begin. Use consented, non-sensitive audio fixtures. Do not publish latency, transcription accuracy, or supported-headset lists unless raw records support those claims. The goal is reliable state and understandable recovery, not a universal accessory guarantee.
A Bluetooth headset disconnects halfway through an offline note
A user is dictating a private note with offline transcription. Several audio segments have completed, the current segment is still recording, and Android reports that an external audio device was removed. The app must avoid losing finished text while not pretending the current segment remained continuous.
Decision
Treat the route event as a state transition, stop or invalidate the uncertain active segment according to tested API behavior, preserve completed segments, and ask the user before resuming on another input.
Expected outcome
The note clearly marks the interruption, retains known-complete transcript text, and offers a controlled resume or finish action without claiming all routes are interchangeable.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Audio-device and route timeline
- Known audio and transcript fixtures
- Partial result, cleanup, and retry outcomes
A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.
Implementation workflow
- Define the capture contract. Document the recorder API, expected sample format, channel count, segment duration policy, and which route details are observable. A requested format is not the same as the format actually delivered; capture the API result and the relevant device identity when available.
- Register for device changes and reconcile state. Observe device add/remove callbacks while capture is active, and reconcile the event against the current recorder/session rather than inferring a route solely from UI state. Ensure callbacks are unregistered with the owner lifecycle and do not retain an Activity after it is gone.
- Choose segment-level interruption semantics. Before testing, decide whether the active segment is discarded, marked incomplete, or finalized only when the API guarantees valid data. Preserve prior completed segments. Store a visible gap or placeholder for uncertain material rather than silently joining audio before and after the event.
- Exercise route events at boundaries. Run controlled cases for connect and disconnect during active capture, between segments, during inference, and during cancellation. Record event order, segment IDs, route evidence, recorder status, partial output, and cleanup. Repeat with built-in capture as a control, without generalizing results beyond observed equipment.
- Verify resume and privacy controls. After the interruption, make the active microphone source and recording state visible, require a deliberate resume where appropriate, and provide a clear stop action. Confirm temporary audio and transcript handling follows the product’s stated retention behavior, and keep raw content out of diagnostic logs.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- A connect/disconnect event is represented as an explicit capture state transition and not silently treated as proof of uninterrupted audio.
- Completed segment results remain distinguishable from the segment active during a route change; uncertain audio is not silently merged.
- The user can see whether capture stopped, what action is available, and how to stop or resume recording.
- Tests record observed route and format behavior for each tested setup without creating a broad headset compatibility claim.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Continue capture | Only when active session behavior and format remain verified | Preserves flow when evidence supports it; otherwise risks hiding an input discontinuity. |
| Stop current segment | Mark interruption and preserve completed segments | Makes uncertainty visible and gives the user a controlled recovery point. |
| Automatically restart on new route | Avoid unless route selection and restart are tested and disclosed | May capture from an unexpected microphone or duplicate audio if transitions race. |
Failure patterns to prevent
- Silently changing microphone sources
- Dropping partial results without state
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does Android automatically move an active recording to a new headset?
Do not assume so. Device callbacks report connection changes, but the application must test what its selected capture API and active session do. Record the observed route and fail safely if continuity cannot be confirmed.
Should all transcript text be discarded after a route change?
Not necessarily. Keep segments whose completion is already known, mark the uncertain active segment separately, and follow a tested rule for whether to retry or resume. Do not silently concatenate across a gap.
Can a test on one Bluetooth headset establish general compatibility?
No. It establishes only the behavior observed for that accessory, device, OS, recorder configuration, and test path. Broader support statements require evidence for the configurations named.