Direct answer
Treat an incoming call as a system interruption that can affect multiple parts of a local-AI task, not as a simple audio-route change. A recording app may be capturing microphone input, a model may be processing buffered segments, and a spoken result may be playing; each has a different owner and interruption policy. Android’s audio-input sharing documentation describes priority behavior when multiple apps request capture and states that an active voice call receives the call audio input. That does not mean an ordinary app can record the call, and this guide makes no such claim. Test how the app’s own recording session behaves and what the user sees. Audio focus concerns output playback and is distinct from microphone-input sharing. Android’s audio-focus guidance notes that focus can be locked during a phone call and can be granted later with a notification to the app. A local transcription task may not request audio focus at all, while optional text-to-speech might. Record which feature requested focus and which callback or state transition the platform actually delivered. Do not assume focus change automatically stops capture, cancels inference, releases buffers, or restores playback. Model the full task as explicit states: recording, segment finalization, inference queued/running, partial result, playback, interrupted, cancelled, and resumable. At call start, follow the product’s user-facing policy: stop capture, preserve confirmed segments, mark the active segment uncertain if needed, and pause or abandon playback focus where appropriate. Do not continue microphone capture silently if the platform denies or suppresses input. On call end, do not restart microphone or speech automatically unless the user action and app design clearly permit it; show the current state and request an explicit resume when necessary. Test call interruption at several boundaries: during microphone capture, between recorded segments, during local inference, while streaming a response, during speech playback, and while the user has already pressed cancel. Record call state as observed by the app, capture permission/foreground state, audio-recording result, focus callback if used, segment IDs, partial output, resource cleanup, and next-task behavior. Use synthetic audio and fixed text fixtures. Android version, app role, source type, and foreground state can affect audio behavior, so reports must not generalize from one configuration. Recovery must preserve data and prevent session crossover. A segment completed before the call remains separate from the segment interrupted by it. Any inference result that arrives after cancellation must not overwrite a newer task. Release or retain buffers according to explicit ownership; a screen disappearing is not proof that native inference stopped. For optional TTS, reacquire focus only through the documented output path and honor the actual result. The project has no comprehensive call-interruption device dataset, so this is a test protocol, not a compatibility or reliability guarantee.
An incoming call interrupts an offline voice note
A user is recording a private voice note while the app processes completed segments locally. A phone call arrives during the next segment, and the app may also be speaking a prior translated result. The team needs to preserve the note without assuming microphone access continues.
Decision
Treat capture, inference, and playback as separate interruption states; preserve completed segments, mark uncertain work, and require a deliberate user decision before resuming capture.
Expected outcome
The user sees which content is saved and whether recording or speech stopped, while old callbacks cannot write into a resumed task.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Call-interruption state timeline
- Audio and inference fixtures
- Cancellation, resume, and next-task outcomes
A runtime comparison is publishable only when artifact identity, build configuration, selected backend, task fixture, and failures are recorded.
Implementation workflow
- Inventory active audio and task ownership. Document which component owns microphone capture, audio buffers, inference segments, playback, and UI state. Record whether optional playback requests audio focus; do not equate focus with input capture permission.
- Define call-start policy. Choose how to stop or suspend capture, finalize already complete segments, label an uncertain active segment, pause or stop speech output, and inform the user. Do not claim the app captures call audio.
- Inject interruption at task boundaries. Test during capture, between segments, during inference, during streaming output, while TTS plays, and during user cancellation. Record OS/app state, audio results, focus callbacks when applicable, and segment IDs.
- Verify call-end and resume behavior. After the call ends, inspect the actual recording and focus state. Do not silently restart microphone capture or replay speech; require explicit resume where product policy requires it and ensure old-session callbacks are rejected.
- Check cleanup, privacy, and data continuity. Assert completed text remains, uncertain audio is marked, temporary buffers are released by their owners, and no call audio is captured or logged. Test the next voice task after recovery and preserve failures.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Microphone capture, model inference, and speech playback have separate interruption states and cleanup owners.
- The app does not claim or attempt to capture phone-call audio; it records only observed behavior of its own task.
- Completed segments remain distinct from interrupted segments, and late callbacks cannot overwrite a resumed request.
- Resume behavior is visible and user-controlled where required; conclusions name the tested Android/app configuration.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Audio route change | External microphone/headset connection or disconnection | Changes capture route evidence; it is not the same event as a phone call taking audio-input priority. |
| Incoming call interruption | System call affects input sharing, focus, and lifecycle expectations | Test capture, in-flight work, and playback separately; do not assume the app receives call audio. |
| User cancellation | Explicit app action to stop its task | Should follow the app’s cancellation contract and cannot be inferred from a call or focus callback alone. |
Failure patterns to prevent
- Continuing microphone capture silently
- Restarting inference before cleanup
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
Can an ordinary app continue recording the microphone during a phone call?
Do not assume so. Android documents input-sharing priority and states the active call receives call audio; test the app’s own capture outcome for its source, role, OS, and foreground state.
Does audio-focus loss automatically cancel model inference?
No. Audio focus is an output-playback concept. Inference and capture need their own task-state and cancellation handling, with cleanup verified separately.
Should recording resume automatically when the call ends?
Use a clear product policy and user-visible state. Unless automatic continuation has been deliberately designed and tested, ask the user before reopening microphone capture or replaying speech.