Auto-Translate Selected Text Without Internet

Direct answer

Selected-text processing is an inter-app handoff, not permission to read arbitrary screen content. Android defines PROCESS_TEXT as an intent for processing a piece of text: a host can supply selected text in an intent extra and processed text can be returned in an extra. The selection menu, read-only state, and replacement behavior depend on the source and target applications. ANDROID-PRIVACY-01 and PRIVACY-01 support testing user choice and data boundaries; they do not establish that Cove implements this integration or that translation works offline.\n\nLimit the workflow to a user highlighting text, explicitly choosing a named processing action, reviewing a draft, and deciding whether to accept or copy it. It must not scrape the screen, poll accessibility content, or silently copy selected text. The UI should make the target visible and state what crosses from the host app. A host may not show a processing target, may mark the input read-only, or may ignore a returned value. Record these as observations for the tested app pair, not universal Android guarantees.\n\nBuild a fixture matrix before running a model: empty text, one word, a paragraph, line breaks, mixed scripts, Unicode punctuation, long selections, sensitive-looking synthetic strings, host cancellation, target failure, and no returned result. Define expected behavior in advance and inspect both input and result extras at the Activity boundary. Keep real private text out of logs and analytics. A Share action is a separate route with its own destination and retention behavior; do not combine it with PROCESS_TEXT merely because both can pass text to another app.\n\nOffline readiness is a separate assertion. The Android intent contract describes transfer between apps, not the target's model, language assets, connectivity, or first-run setup. Test the exact path from a cold launch in a controlled disconnected environment, including missing assets and reconnect behavior. Inspect network clients and provider paths rather than assuming the selected text remains local. If the route is unsupported or required resources are absent, show that state instead of silently uploading text or displaying the unmodified source as a translation.\n\nThe receiving screen should show the selected source and generated draft, allow cancel and reject, and avoid executing or forwarding output automatically. If the host marks text read-only, do not claim replacement. Where replacement is supported, test selection ranges and cursor behavior for the exact host, and let the user compare before acceptance. Treat generated text as untrusted data: it should not become a command or trigger another operation in the host app.\n\nAfter completion, inspect whether content is retained in activity state, history, a database, clipboard, diagnostics, or crash reports. Test both cancellation and success against the stated retention policy. Clipboard is another user-visible boundary and should not be written by default. If the host application is a remote service, an intent can hand text to another application; one on-device inference step does not make the whole route local.\n\nRecord Android version, source host and version, target build, action and extras, read-only status, fixture, returned value, connectivity, and failures. Conclusions apply only to the observed host-target pair. They do not prove that every editor exposes the same menu or accepts a result. Evaluate integration behavior, offline operation, and translation quality as separate axes. A scoped test record is more useful than claiming any Android selection can be translated offline.

A reader translates one highlighted sentence

A reader highlights a sentence in an Android reading app and selects a translation action from the text menu. The host marks the selection read-only; the reader wants to inspect a returned draft before deciding whether to copy it into a note or leave the original unchanged.

Decision

Test the exact PROCESS_TEXT contract for that host and target pair, show the target and result, and preserve cancellation and review.

Expected outcome

The test records selected input and returned output without claiming silent screen access, universal host support, or offline availability.

Evidence to collect

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

• Text-handoff mechanism
• Denied and unsupported fixtures
• Clipboard, history, and deletion tests

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Inspect the intent contract. Record the action, input extra, read-only flag, returned extra, and Activity lifecycle for the Android versions and host apps in scope.
2. Exercise controlled input cases. Use synthetic short, long, multiline, mixed-script, empty, and sensitive-looking fixtures across editable and read-only host selections in multiple applications under repeatable test conditions.
3. Verify review and return behavior. Check whether the host accepts output, whether replacement is allowed, and whether a user can inspect or reject the draft before acceptance.
4. Test cancellation and unsupported paths. Cancel before processing, close the target, simulate no output, and test unsupported input without unexpected copying or source persistence in either app.
5. Verify offline and retention separately. Cold-start with network access controlled, inspect setup and reconnect traffic, then review history, clipboard, logging, deletion, and source cleanup behavior.

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

Acceptance criteria

• Only explicit user selection starts the workflow, and the record names the exact intent contract and host behavior.
• Read-only input, cancellation, unsupported host behavior, and missing output remain visible; silent reading or replacement is not claimed.
• Offline operation and translation quality are tested separately for the exact route and build, with network and retention limits stated.

Decision table

Failure patterns to prevent

• Reading every screen silently
• Replacing source text without review

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

• Android privacy and security
• Android Intent ACTION_PROCESS_TEXT
• Android common intents and text processing
• Android security and privacy overview

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

Frequently asked questions