Direct answer
Calling an export “encrypted” is incomplete unless the product identifies which bytes are protected, when plaintext exists, who controls the key, and what happens if the key is lost. Distinguish an encrypted app database, an encrypted archive generated for export, encryption in transit during a share, and the recipient's copy. `ANDROID-PRIVACY-01` places storage and user control within application responsibility; `PRIVACY-01` reminds us that local inference does not determine other data routes. These facts support an audit method, not a claim that any current Cove export is encrypted. Start with the export lifecycle: select records, assemble fields, create a temporary file, encrypt or package it, preview, hand it to Android Sharesheet or a document provider, optionally import it back, and delete local temporary data. For each stage record the data classification, storage location, permission boundary, and whether plaintext appears. A UI label or file extension is not proof of encryption. If the export includes transcript, prompt, image, model metadata, or account identifier, list each field and provide a user preview. Avoid adding hidden diagnostics to a support bundle. Specify the cryptographic boundary before implementation review. Identify algorithm and mode only if the implementation and official library contract expose them; record key generation, storage, use, rotation or replacement, and backup/recovery policy. Android Keystore can protect key material and control key use, but it does not automatically encrypt an arbitrary export file or solve user recovery. The app must bind ciphertext to the intended data and reject malformed or altered archives. Never store the key beside the export in plaintext and call that secure. If passphrase-based recovery exists, document how the passphrase is obtained, whether it leaves the device, and what happens on loss without promising recoverability the code does not provide. Temporary plaintext is a frequent blind spot. The export may first be assembled in cache or app-private storage before encryption; a failed encryption, crash, or cancellation could leave a readable file. Inspect file permissions and lifecycle cleanup, and test interruption before writing, mid-write, after encryption, and during share handoff. Make cleanup retryable and do not delete the only user source record when an export fails. Once the user shares the file, the receiving application may copy, decrypt, or retain it under its own policy; the exporting app cannot promise control over that destination. Use synthetic test content with recognizable canary strings. Create an export, inspect its bytes and metadata with the documented test procedure, attempt a round trip with the authorized key, reject a wrong key, and mutate a byte to verify integrity behavior only if the format provides such protection. Check that canary text does not appear in filenames, logs, temporary leftovers, notifications, or analytics. Review Android Sharesheet/document-provider behavior and inspect the exact URI permissions granted. Verify that only selected records were exported and that preview matches the payload. Report encryption as a scoped result: exact app build, export format version, key path, fields, local plaintext stages, recovery method, destination boundary, and tests. Do not say “end-to-end encrypted,” “secure export,” or “only on this device” unless each term is supported by the actual design. A user may choose to share an encrypted file elsewhere; that transfer and the recipient's ability to decrypt are separate from local model execution. The guide should help teams make a verifiable, narrow promise rather than treating the word “encrypted” as a complete privacy explanation.
A user exports selected transcripts for personal archiving
The app offers an optional encrypted archive of selected local notes. The team must determine whether a temporary plaintext file exists, how the key is stored or recovered, and what the receiving app can retain.
Decision
Map encryption and plaintext boundaries, test preview and key failure behavior, and disclose the handoff boundary before the user shares the archive.
Expected outcome
The record states exactly which payload and local stages were tested without promising control over recipient storage or universal recovery.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Export format
- Key and recovery policy
- Round-trip and failure tests
A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.
Implementation workflow
- Inventory export fields and lifecycle stages. List selected records, generated fields, temporary files, archive format, preview, URI handoff, import/restore, and cleanup. Mark where plaintext and ciphertext exist.
- Review key creation and recovery design. Identify the actual key API, storage, permitted operations, loss behavior, and backup policy. Do not treat Keystore presence as proof an arbitrary file is encrypted.
- Test temporary and failure paths. Interrupt creation, encryption, cancellation, and share handoff. Inspect app-owned storage for readable leftovers and ensure a failed export does not delete source records.
- Verify content and cryptographic behavior. Use synthetic canaries to inspect the payload, test authorized round-trip, wrong-key rejection, and integrity behavior supported by the format. Check logs, filenames, and metadata.
- State destination and recovery limits. Review Sharesheet or provider URI grants, preview exact selected fields, and explain that recipient retention is outside the exporter’s control after handoff.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- The report distinguishes encrypted database, export archive, transfer, and recipient copy; it names the protected bytes and plaintext stages.
- Key creation/storage/recovery behavior is documented, and cancellation or crash tests find no unintended app-owned plaintext residue.
- Only user-selected, previewed fields are exported; security and recovery claims are limited to the tested format and implementation.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Encrypted app storage | Protects data while stored under a configured mechanism | Does not prove a subsequently created export archive is encrypted. |
| Encrypted export archive | Protects specified payload bytes with a key | Requires key lifecycle, recovery, plaintext cleanup, and format integrity testing. |
| Shared recipient copy | File handed to another application or provider | Recipient may copy or retain it; the exporting app cannot promise destination control. |
Failure patterns to prevent
- Saying encrypted without scope
- Leaving plaintext temporary files
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
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does Android Keystore automatically encrypt exported files?
No. Keystore can protect key material and operations, but the application must implement and verify encryption of the actual export bytes and manage recovery.
Can an export be called end-to-end encrypted after sharing?
Only if the complete design supports that claim, including recipient keys and decryption boundaries. A local encrypted file alone does not establish end-to-end protection.
Should plaintext temporary files be ignored after cancellation?
No. Inspect app-owned cache and temporary paths after cancellation, crash, and encryption failure. Cleanup should be tested and must not delete the only source record.