Direct answer
A reply suggestion is not the same operation as translating a conversation. Translation should preserve the meaning of the other speaker’s message; a reply suggestion proposes new words that the user might choose to send. The interface should label those outputs separately and let the user review, edit, reject, or ignore a suggestion before any send action. Android exposes ConversationAction and TextClassifier APIs that can represent or suggest a text reply, but the API documentation does not guarantee that a device’s classifier generates those replies offline. A locally deployed language model can generate text on a device, but that alone does not prove a translation app integrates a reply feature, uses only local context, or avoids other network requests. To verify an offline reply workflow, test source-message translation, suggestion generation, user review, and sending as separate stages. Start from a cold app session with the required assets prepared, disable connectivity, and use synthetic conversations. Record whether suggestions appear, whether they remain distinguishable from translated text, and whether the app waits for an explicit user action. If the feature or its network behavior is undocumented, call it unverified rather than advertising it as an offline capability.
Scenario: replying to a short message while traveling offline
A traveler receives a message in a language they are still learning. The app displays a translation, then offers possible replies such as “I can meet at five” or “Please send the address.” One answer may introduce a time, commitment, or request that the original message never contained. The traveler wants to prepare a reply with no data connection but must remain the author and decide exactly what gets sent.
Decision
Keep the incoming literal translation visually separate from any generated reply idea. Show that a suggestion is newly drafted content, retain the original message for comparison, and require the person to inspect and explicitly send or edit it. Test translation and suggestion generation independently while offline; do not infer one from the other.
Expected outcome
The traveler can tell what the other person said, which text is an optional machine-generated draft, and whether the app can create that draft without network. If suggestion generation is unavailable, the translated message remains usable and the app offers no misleading substitute.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Conversation intent and reply fixtures
- Translation-versus-generation labels
- Offline, review, reject, and send-boundary tests
Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.
Implementation workflow
- Define the conversation outputs. List the incoming source message, literal translation, optional suggested reply, user-edited reply, and transmitted message as distinct records or interface states. Decide how the original text remains visible and how the suggestion is labeled. Avoid a single chat bubble that makes a generated response look like part of the translated conversation.
- Specify authorship and the send boundary. Require a clear user action before a reply leaves the device. A suggestion can be dismissed, edited, or replaced with a blank composer; it should not send automatically after generation or translation. Preserve a visible distinction between “translation of received text” and “draft response,” especially when suggestions express agreement, refusal, dates, prices, or commitments.
- Choose and document the suggestion route. If suggestions come from Android TextClassifier, record the selected classifier and whether its documentation establishes offline behavior. If the app uses a local language model, pin the artifact and runtime, define what conversation context is supplied, and record any model or safety filter dependency. Neither an API method called “suggest” nor a model described as on-device proves that this app’s full feature is offline.
- Build synthetic conversation cases. Create short examples for a clear question, a neutral acknowledgement, an ambiguous message, a request containing a date or amount, a refusal, and a message where no reply should be proposed. Have fluent reviewers confirm the incoming translation and define which reply options are safe and faithful to the user’s stated intent. Do not test with real private chat logs.
- Run translation and suggestion tests separately. With required assets installed, disable Wi-Fi and cellular access and cold-start the app. First translate each incoming message without requesting a reply. Then request suggestions and record whether a new candidate appears, what context it used, and whether it differs from the literal translation. Repeat with network access restored only after preserving the offline result; do not mix the two runs.
- Inspect review, rejection, and transmission behavior. For every proposed reply, verify that the user can inspect and edit the full text, discard it, and choose whether to send. Confirm that generating or selecting a suggestion does not itself dispatch a message. Record how cancellation, missing model assets, ambiguous intent, and unavailable network are displayed, and ensure diagnostics do not collect conversation text without a justified and disclosed need.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- The incoming literal translation and generated reply suggestion have distinct labels and remain traceable to the original message.
- A fresh suggestion is generated in the tested offline state; translation success or an earlier cached draft is not counted as proof.
- The user can edit or reject every candidate, and sending requires a separate explicit action after reviewing the final text.
- Ambiguous, high-impact, or unsupported cases remain unresolved or produce no suggestion rather than an invented commitment.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Literal translation | Re-express the received message in another language | Its purpose is fidelity to the source; it should not add a response, decision, or new factual detail. |
| Generated reply suggestion | Draft new text based on the translated conversation and user intent | This is authored content, not a translation; label it, review it, and keep it separate from sending. |
| Android TextClassifier reply action | Platform API represents or suggests a text reply action | The API shape does not certify that a particular classifier or app suggestion runs offline. |
| On-device LLM draft | A configured local model generates candidate response text | Local generation is one possible architecture; verify exact context, assets, runtime, and all other app network paths. |
| Fixed phrasebook | Offer a user-selected, reviewed phrase from a prepared set | It is not generated conversation understanding, but it is predictable and can work as a transparent offline fallback. |
Failure patterns to prevent
- Presenting generated replies as source meaning
- Sending a suggestion without user confirmation
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
- FunctionGemma mobile actions
- Android privacy and security
- Android Developers — ConversationAction reply type
- Android Developers — TextClassifier conversation-action API
- Google AI for Developers — Deploy Gemma models on mobile
- Android Developers — Privacy and security responsibilities
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Are reply suggestions just translations of the other person’s message?
No. A translation restates the source message in another language. A suggested reply adds new content that the user might choose to send. The interface should label these separately, keep the original message available, and never present a generated response as if the other person said it.
Does Android’s ConversationAction API guarantee offline reply suggestions?
No. Android defines a ConversationAction type for text replies and a TextClassifier API for suggested conversation actions, but those references do not guarantee that a particular classifier or app generates suggestions without a network. Test the exact app, system service, device, and language context while disconnected.
If a translation app uses an on-device LLM, are reply suggestions offline?
Not automatically. The model may run locally while account checks, suggestion services, moderation, analytics, or other stages still use a network. Verify the exact suggestion path after assets are prepared and connectivity is disabled, and review the app’s other data flows separately.
Should a suggested reply be sent automatically?
This guide treats a reply as new user-authored communication. A person should be able to inspect, edit, reject, or ignore the suggestion, and sending should require a separate explicit action. That is especially important when a draft contains a date, price, agreement, refusal, or promise not present in the incoming message.
How can I test reply suggestions without sharing private chats?
Use synthetic conversations that cover clear, ambiguous, negative, and high-impact cases. Have a fluent reviewer check the incoming translation and define acceptable candidate replies in advance. Then test fresh offline generation, review, edit, reject, and send boundaries without uploading personal conversation history.