External Microphone Offline Translation Test

Direct answer

Test external-microphone translation from the first input-selection decision, not from a headset icon or a successful translation alone. Android can report currently connected input devices, and AudioRecord can request a preferred input on supported API levels. That preference is not proof of the device that supplied the active recording: Android documents that getPreferredDevice() may differ from the actual route, while getRoutedDevice() identifies the current route only while AudioRecord is recording. Preserve all three facts separately: device discovered, device requested, and device observed on the active session. Confirm the API level and object before requesting a route. AudioRecord.setPreferredDevice() was added in API 23. The call returns whether the specified object is a valid input device for that recorder; a successful return still does not certify acoustic input or guarantee that the preferred device is the active route. If the API level, capture wrapper, or device does not expose this operation, show the system-selected/default route as such and record the limitation. Do not silently label the built-in microphone as the user's chosen external input. AudioManager.getDevices(GET_DEVICES_INPUTS) is an inventory of connected devices, not a capture selection API. Keep initial selection distinct from mid-session recovery. This guide tests what the app can choose before recording begins and what it can verify once recording is active. It does not define how to stitch, discard, or resume segments after an accessory is unplugged during capture. Ask for microphone permission in the user-started capture flow, explain that a short test phrase will be recorded, expose an explicit stop action, and do not start capture after denial. A local model does not change Android recording permissions. These steps are a verification method and do not assert that Cove Travel or Cove Voice currently offers external-microphone selection. Use a paired, human-audible control. Record the same short phrase through the built-in mic and the candidate external input, with the same recorder configuration and no model or prompt changes. Choose a phrase with a clear onset, two distinct words, one number, and a short pause. Preview the captured clip locally through a user-controlled action and compare the recognizable phrase and obvious silence/noise; do not publish this as a transcription accuracy metric. The listening check complements route evidence; it does not replace the API route query. Avoid using private speech as a public fixture, and delete the temporary clip according to the test plan. For each attempt, record Android version/API level, device and accessory identity, capture API, recorder initialization state, requested preferred device and its return value, active routed device while recording, configured format, bytes or frames read, and the human review outcome. If the route is null because recording has not started, do not treat it as evidence that the selected route failed; query it at the API-documented time. If the preferred request returns false or the active route differs, show a clear fallback choice before interpreting the capture. Distinguish format observation from audio quality and keep translation output as a separate later stage. After input selection is verified, run a narrow translation fixture with a known source phrase and target direction. Keep the phrase, language pair, model artifact, runtime, prompt, and playback route fixed while comparing microphones. Record transcription, translation, and spoken playback as separate outcomes. For an offline claim, disable connectivity in a controlled run and observe whether setup, model access, transcription, translation, and playback remain available; inspect app-owned network paths separately because local inference alone does not prove the whole application makes no requests. If the selected build requires a remote translation service, this test is not an offline pass. The report should state the tested accessory, Android/API level, app build, recorder implementation, requested and observed input routes, format, phrase fixture, language direction, model/runtime, and all failures. A successful AudioRecord route query plus an understandable control recording supports a narrow statement about that combination. One accessory test does not establish a universal supported-microphone list, language quality, transcription accuracy, latency, battery use, or every Android routing behavior. These product claims need separate repeated raw records; the repository benchmark gate currently supports methodology only.

The first capture should use a selected USB microphone

A user opens an offline translation feature with a USB microphone already attached and chooses it instead of the built-in input. The system exposes an input device, but the app has not checked AudioRecord API support, the preferred-device result, the active route, or whether a short phrase is audible in the captured sample.

Decision

Check the API-level and recorder support, request the selected device only where supported, inspect the active routed device during recording, and compare a user-approved control phrase with built-in capture.

Expected outcome

The app can report a verified route for this exact setup, show a clear default-input fallback, or label route evidence unavailable without claiming accessory-wide support.

Evidence to collect

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

• Phone, microphone, and route identity
• Audio and transcript fixtures
• Connect, disconnect, task, and recovery records

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

Implementation workflow

1. Check recorder support before selection. Record the Android API level and exact capture API. AudioRecord.setPreferredDevice() is available from API 23; if the app wrapper cannot call it, expose only the system-selected route and mark the choice control unavailable.
2. Inventory connected input candidates. List input devices using the inventory supported by the capture API. Keep device identity/type separate from a user choice; AudioManager discovery does not tell you which input an active recorder uses.
3. Request then observe the route. Request the selected AudioDeviceInfo only when supported and record the boolean result. Start recording, then query AudioRecord.getRoutedDevice(); getPreferredDevice() is not guaranteed to match the active route.
4. Compare a human-audible control. Record the same short consented phrase with the built-in mic and selected external mic using unchanged recorder settings. Preview both locally and check recognizable words and obvious silence/noise alongside route evidence.
5. Run a fixed translation task. Only after input selection is verified, run the same source phrase, language pair, model, prompt, and playback settings. Record transcription, translation, and playback separately, then repeat with connectivity disabled for an offline claim.
6. Report fallback and scope. If the preferred request fails, the active route differs, or route evidence is absent, show the system-selected fallback or unknown state. Name the API level, device, accessory, fixture, and build; do not infer broad support.

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

Acceptance criteria

• The record distinguishes input inventory, user selection, preferred-device request/result, and actual AudioRecord route during capture.
• A paired human-audible control uses the same short phrase and recorder settings for built-in and selected external input.
• The exact Android API level and accessory/build scope are reported; unsupported selection or unavailable route evidence is not called success.

Decision table

Failure patterns to prevent

• Assuming the selected input was used
• Changing microphone and model together

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 benchmark method
• Android Developers — AudioManager input-device inventory
• Android Developers — AudioRecord preferred and routed devices
• Android Developers — AudioDeviceCallback connection events
• Android Developers — platform audio capture overview

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

Frequently asked questions