Diagnose Android AudioRecord Client Silencing

Direct answer

A live recorder state is not proof that the framework is passing microphone audio to that client. Android can arbitrate concurrent capture and silence a lower-priority client while another permitted capture is active. On API 29 and higher, AudioRecordingConfiguration.isClientSilenced() reports whether audio returned to the client is currently being silenced by that concurrent-capture policy. This is a narrow system-state signal; it is not a speech detector, route identifier, permission result, or explanation of which other capture won priority. AudioRecord.registerAudioRecordingCallback(executor, callback) is also available from API 29 and reports capture-configuration changes, including system silence/unsilence. Android's audio-input-sharing guidance says to register before starting capture; callbacks are delivered when the app is receiving audio and a change occurs. Therefore, no callback does not prove the client is currently unsilenced. When the exact API exposes the active configuration for the recorder, sample that state after startup as well as observing transitions, and correlate it to the AudioRecord session rather than choosing an arbitrary entry from a list of recordings. Do not conflate callback class availability with per-recorder capability. AudioManager.AudioRecordingCallback and the manager-level active-recording configuration observer date from API 24, while the AudioRecord registration overload and isClientSilenced are API 29. On older devices, do not synthesize the newer flag from a successful permission check, RECORDSTATE_RECORDING, positive read count, or low waveform amplitude. Those facts can be useful capture evidence, but they do not establish the framework's concurrent-capture silence state. If API 29 signals are unavailable, record that cause as unknown. A true isClientSilenced value identifies framework muting due to capture policy, not a quiet room, a person who did not speak, a disconnected headset, malformed data, or an invalid recorder. A false value does not prove the input contains speech or that the microphone is useful. Keep quiet and consented speech fixtures separate from the flag; sample values alone prove neither framework silence nor intelligible speech. Match every configuration update to the current app-owned recorder session. Store a session ID, the recorder's public client audio session ID when available, callback time, configuration snapshot, route and format fields that the API actually exposes, and the app's own capture state. Ignore late events from an old recorder after release or recreation. A configuration callback may report route, preprocessing, or format changes as well as silencing, so classify the fields instead of turning every callback into a muted state. Do not log other applications' identities or infer which one caused the policy decision. Keep nearby signals distinct. ERROR_DEAD_OBJECT invalidates the recorder; a route event changes the input path; permission denial blocks access; a short read is a read outcome; and no transcript occurs later. If isClientSilenced is true, mark framework silence rather than claiming the speaker was quiet. If false or unknown, investigate signal, route, format, segmentation, and recognition separately. Test only through visible, consented capture using ordinary platform APIs. Register before capture, snapshot a matching configuration when available, and run quiet and consented speech fixtures. For authorized concurrency tests, use a second controlled app that follows platform rules; do not bypass privacy controls or capture priority. Record transitions and uncertainty instead of assuming every device sends the same callback at startup. This is a platform diagnosis method, not a claim that Cove currently checks isClientSilenced or that a user can identify the higher-priority capture from this flag. The API reports only the client-side policy state. Permission granted, a recording indicator, or AudioRecord's recording state does not equal audible or intelligible input. Keep capture evidence, system policy, route state, and recognizer output as separate fields; do not claim audio accuracy, device support, or a system-mute rate without measured records.

AudioRecord is active but a new voice note has no usable speech

A user-visible voice task starts and reads continue, but the app receives no intelligible transcript. Permission is granted and the recorder reports an active state. The team has not established whether the room was quiet, the route changed, or Android's concurrent-capture policy silenced this client.

Decision

On API 29 or later, observe the recorder's AudioRecordingConfiguration and callback state, match it to the active recorder session, and keep acoustic, route, recorder, and recognition evidence separate.

Expected outcome

Support can say whether Android reports framework silencing or whether that status is unavailable, without blaming the speaker, identifying another app, or treating the result as a model failure.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Active recorder configuration and client-silenced state
• Session-matched silence and route transitions
• Consent-safe quiet and speech fixtures

A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.

Implementation workflow

1. Record the authorized capture state. Capture the user's start action, RECORD_AUDIO grant, recorder ID/session, recording state, route and declared format where available. Keep the known quiet fixture and consented speech fixture separate; do not store private audio by default.
2. Pin API-level signal availability. Use AudioRecordingConfiguration.isClientSilenced only on API 29 or later. Register AudioRecord.registerAudioRecordingCallback before capture starts. Do not substitute the API 24 manager callback type or a permission/read-state check for this per-client status.
3. Snapshot and correlate configuration. After start, inspect the active recording configuration for the same recorder when the exact API exposes it, then process silenced/unsilenced and route/format callbacks. Associate each update with the active AudioRecord session; absent configuration or callback evidence is unknown, not false.
4. Classify silence separately from other failures. A true flag means concurrent-capture-policy silencing. A false flag does not prove speech exists. Record route change, ERROR_DEAD_OBJECT, permission loss, empty read, known acoustic silence, and no-transcript recognition as different observations.
5. Reproduce only within platform rules. Use visible, consented, controlled test apps and normal audio APIs. If testing concurrency, let a second authorized app participate without bypassing system policy. Capture transitions and snapshots; do not assume every API 29 device sends the same callback sequence.
6. Present a bounded user recovery. If the current client is reported silenced, mark capture policy as the earliest known boundary and offer a clear wait/stop/retry path supported by the product. Do not tell the user they were inaudible or automatically recreate AudioRecord when the recorder is still valid.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The feature records API level and checks isClientSilenced only when the API exists; missing snapshots or callbacks stay unknown rather than being inferred as unsilenced.
• Each callback/configuration record is matched to the active AudioRecord session, and silencing, route/format changes, dead object, permission, read results, and recognition remain separate states.
• Tests use visible, consented, policy-compliant capture fixtures; no test bypasses Android capture priority or logs another app's identity or private audio.
• Product wording reports a framework-silenced state only when the API says so and never infers acoustic silence, intelligible speech, Cove behavior, or device-wide reliability from permission/recording indicators.

Decision table

Failure patterns to prevent

• Inferring an unsilenced state from a missing callback
• Guessing which app has capture priority
• Treating permission or recorder state as audible speech

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

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

• Cove Voice transcription
• Android AudioRecordingConfiguration API: isClientSilenced and API level
• Android AudioRecord API: recording callback registration and lifecycle
• Android AudioManager.AudioRecordingCallback API: API 24 observer
• Android audio input sharing: concurrent capture and silence policy

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions