Direct answer
Local inference does not decide what Android backs up. Android Auto Backup and device-to-device transfer are separate data flows from model inference, and Android documents that most app data can be included by default unless the app configures exclusions or includes. Android 12 and higher use data-extraction rules for cloud backup and device transfer; apps also need to consider support for older OS versions. A privacy review must inspect the manifest, backup-rule files, storage locations, target SDK, and actual restore behavior. A “data stays on device” product statement is not supported by model placement alone. Start with an inventory of each data type and where the app stores it: user prompts, generated results, audio, images, logs, authentication tokens, preferences, model artifacts, and caches. Map each path to app-private files, databases, shared preferences, external app-specific storage, cache, or no-backup directories. Do not assume that all files are included or excluded based on the model being local. Android’s backup behavior depends on app configuration and platform/version rules. Then classify transfer modes separately. Cloud backup and device-to-device migration can use different rule blocks. Excluding a path from cloud backup does not necessarily exclude it from device transfer, and a missing device-transfer section may leave default behavior enabled. The policy should specify which data is necessary to restore a useful experience and which must not leave the device through backup. Large model weights may be redownloaded rather than backed up, but that is an app design choice and must be confirmed in the configuration. Do not put credentials or secrets in ordinary preferences or exported task data. Use a test matrix rather than relying on a manifest review alone: install the app fresh on supported Android versions, create each data type, run backup or transfer through a testable path, restore to another install, and inspect which items returned. Verify cloud and device-to-device behavior separately. Include migration from older backup-rule formats when target SDK changes. If the app cannot test a particular transfer surface, describe it as unknown and avoid a broad privacy guarantee. Backup policy also affects deletion promises. Deleting an item from the visible database may not erase earlier backup snapshots or exports. Explain retention honestly, separate cache cleanup from user-data deletion, and do not claim “permanently erased everywhere” without evidence for each storage and backup destination. Any restore flow should also reapply the current user’s consent and permission state rather than silently reactivating microphone or camera access. For a local AI app, the practical questions are: which data is backed up, to which transport, under which OS rules, when does backup run, what can the user disable, how are restores authenticated, and what is redownloaded? This guide is a verification method, not a statement about Cove’s current backup configuration. Review sequence: 1. Inventory data types and storage paths in the application; include logs, generated output, model files, and temporary media rather than only the source prompt. 2. Read manifest flags and version-appropriate full-backup and data-extraction rules. Compare cloud-backup and device-transfer sections; examine default behavior for any missing rule. 3. Run fresh-install, backup, device-transfer, restore, and deletion scenarios on supported versions. Inspect actual restored data, not only configuration XML. 4. Update privacy wording to state what was verified, what is excluded, what can return through restore, and which behavior remains untested. A local model can keep inference local while backups remain enabled; only a reviewed and tested data-path configuration supports a more specific claim.
A user restores an offline translator on a new phone
A privacy reviewer needs to know whether translation history, voice notes, user settings, diagnostics, and a multi-gigabyte model file appear after cloud restore or device-to-device setup. The app’s inference engine runs locally, but that fact does not answer the backup question.
Decision
Map each data type to storage and to each Android transfer mode, then test actual restore behavior before updating the privacy statement.
Expected outcome
The team can distinguish data that restores, data that is intentionally excluded, model resources that must be redownloaded, and unverified transfer paths.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Backup configuration
- Restore test
- Deletion after restore
A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.
Implementation workflow
- Build a storage inventory. List every user and app-generated data type, its storage directory or database, whether it is sensitive, how long it is retained, and whether an export or cache copy exists.
- Review rules for every transfer mode. Check manifest backup attributes and XML rules for the relevant Android versions. Review cloud backup and device-to-device transfer separately, including default behavior when a rule section is omitted.
- Exercise backup and restore. Create representative test records, run supported backup and device-transfer paths, restore into a clean install, and inspect which records, settings, logs, and model files return. Do not treat static XML as observed behavior.
- Align deletion and privacy statements. Describe the verified restore and deletion limits, including backups and exports. Separate cache cleanup, user deletion, model removal, and account data; re-check permissions and consent after restoration.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Every sensitive data type has a documented storage location and cloud/device-transfer decision.
- Cloud restore and device-to-device transfer are tested independently on relevant Android versions.
- Public wording does not promise local-only or permanent deletion beyond observed configuration and tests.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Local model inference | Input processed on the device | Describes an inference path, not whether app files are backed up. |
| Cloud backup rules | Files included in remote backup according to configuration | Must be inspected and tested separately from inference. |
| Device-to-device transfer | Data moved during device setup | Can have rules different from cloud backup and may restore different files. |
Failure patterns to prevent
- Saying never leaves device while backup is enabled
- Ignoring derived indexes
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
- Android privacy and security
- Android Developers — Auto Backup user data
- Android Developers — backup security recommendations
- Android Developers — privacy and security overview
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
If an app runs a model locally, are its notes automatically kept only on the device?
No. Backup and transfer are separate platform data flows. Inspect the app’s manifest, storage locations, backup rules, and actual restore behavior before making a local-only statement.
Does excluding cloud backup also exclude device migration?
Not necessarily. Android defines separate rule sections for cloud backup and device-to-device transfer. Check both sections and test the supported OS versions.
Does deleting a conversation prove every copy is gone?
Not by itself. Prior backups, exports, caches, and user-created copies may have separate retention. Describe which locations the app controls and avoid promising erasure from destinations it cannot inspect.