Direct answer
An offline speech translator is a pipeline, not a single “translation API.” On Android, the app must first obtain permission and capture microphone input, then pass a documented audio representation into an inference path that is available locally. It must validate and present the model result, preserve failures as failures, and treat optional text-to-speech as a separate capability. The order and boundaries matter: capturing speech is not proof of transcription, a model-produced translation is not proof that playback works, and an installed model does not establish that every supporting service is network-independent. In Cove Travel's current code, the user records a turn, the recorder returns audio data when recording completes, the view model sends that data and a translation instruction through the local inference engine, and the parsed translation is saved to history. The app also has a separate Android TextToSpeech wrapper for reading translated text. This is a record-then-infer flow, not evidence of continuous streaming or universal offline voice availability.
Scenario: a traveler asks for directions with no connection
A traveler speaks a short request, waits for translated text, and may ask the phone to read that text aloud. The model file was installed before the trip. A correct architecture must distinguish a permission denial, an empty or unusable recording, model-not-ready state, failed inference, and a missing target-language speech voice.
Decision
Keep capture, inference, result parsing, history, and speech output behind separate contracts. Make the user-visible state identify which stage failed, and keep a text result usable even when optional TTS cannot speak the chosen language.
Expected outcome
The user can tell whether the app captured audio, generated a translation, saved it, or played it. An airplane-mode test after model setup can then determine which complete path really works locally on that device.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Permission-gated microphone capture and lifecycle
- Audio format and model-input contract
- Translation output, optional TTS, and offline failure paths
Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.
Implementation workflow
- Request microphone access at the feature boundary. Ask for recording permission when the user starts the voice feature, explain why capture is needed, and do not begin reading microphone data before permission is granted. Handle a denial without disguising it as a model or translation error. Android also allows users to disable microphone access at the device level, so the capture stage must be able to stop and report a recoverable state.
- Define the recorder-to-model contract. Specify whether the recorder returns a complete clip or incremental frames, the audio encoding and channel policy, who owns buffering, and how stop, interruption, cancellation, and maximum input length are handled. Pass an explicit representation into the inference adapter. Do not assume that the model accepts the platform recorder object or that an arbitrary PCM byte array has the expected sample format.
- Make local inference a distinct stage. Before starting translation, verify that the required artifact is present and the runtime is ready. Keep model ownership outside the screen, serialize access if the native engine requires it, and route the audio with a task instruction that names source and target language. Collect the full response according to the runtime contract, then parse it into a typed result rather than treating raw model text as a stable interface.
- Separate translated text from speech synthesis. Render the translation as text first. Offer playback as an optional next action with an explicit target locale, and check whether the Android TTS engine initialized and supports that locale. A locally executing model does not prove that a voice package is installed or that synthesis itself needs no network. If playback is unavailable, preserve the text and explain that only the spoken-output stage failed.
- Test the whole journey and every interruption. After model setup, disable networking and perform the complete user task from microphone permission through visible translated output. Repeat with revoked permission, device microphone privacy controls, an interrupted recording, empty audio, a model load error, malformed output, unavailable TTS language, and app recreation. Keep each stage's result separate so one successful output does not hide an earlier fallback or an incomplete offline path.
- Report exactly what was verified. Describe whether the app is push-to-talk or continuous, whether it returns text or speech, which stages were tested offline, and what setup must happen before disconnecting. Avoid advertising “real-time,” “works everywhere,” or speech-language coverage from a successful sample. Compatibility and performance statements require raw runs tied to a specific app, artifact, runtime, device, and workload.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Microphone access is requested in context and denial or system-level blocking is visible and recoverable.
- The recording format, ownership, stop behavior, interruption behavior, and model input contract are documented and tested.
- Model readiness, inference, parsing, persistence, and optional TTS have separate outcomes.
- A complete post-setup task succeeds in airplane mode on the recorded device; unsupported stages are disclosed.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Capture | Android AudioRecord or another explicit recording API with permission handling | Proves only that input capture was attempted; validate state and actual returned audio before inference. |
| Inference | Local runtime and installed model receive the recorded representation | Test model readiness, input contract, cancellation, result parsing, and offline execution separately. |
| Presentation | Show translated text independently from optional TTS playback | Text can remain useful when the device lacks a compatible installed speech voice. |
| Network claim | Run the full post-setup task with connectivity disabled and inspect dependencies | A local inference step does not by itself prove model setup, telemetry, or speech output is network-free. |
Failure patterns to prevent
- Calling a record-then-infer app streaming
- Treating TTS as the model output
- Assuming a downloaded model proves every stage is offline
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
- On-device AI architecture overview
- Cove Travel voice translation
- Cove Voice transcription
- Android AudioRecord API reference
- Android guidance on explaining microphone permission
- Google AI Edge LiteRT-LM repository and runtime documentation
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Is offline voice translation the same as offline speech recognition?
No. Speech recognition produces or interprets source-language words; translation maps meaning into a target language. An app can combine both stages inside one model, but the product should still test and debug input capture, language direction, translation output, and any later speech synthesis separately.
Does Android TextToSpeech automatically work offline?
Do not assume so. Android exposes a TextToSpeech service, but the available engine and language voice data depend on the device configuration. Check initialization and language availability on the target device, test playback after setup with the network disabled, and preserve translated text if spoken output is unavailable.
Can a phone translator call itself real-time if it records before inference?
A record-then-infer flow should be described as turn-based or push-to-talk, not continuous streaming. “Real-time” requires a defined latency boundary and evidence about interim recognition, revision behavior, interruptions, and sustained operation. A label in the interface or a short successful recording does not establish those properties.
What is the minimum test for an offline claim?
Install and verify required artifacts first, then disable connectivity and complete the actual user task from capture to the result the user relies on. Include permission handling, recovery, and optional output such as TTS. Record any step that still requires network access rather than inferring offline behavior from the inference engine alone.