Direct answer
A successful Android app-data restore does not prove that a local-AI model is present or usable. A restored preference may remember a selected model ID, a previous download state, or a setup choice while the corresponding file was excluded, stored in a cache directory, left on another volume, or replaced by an artifact from a different revision. Treat restored metadata as a claim to reconcile, not as proof of model readiness. Do not assume either that Android restored every model file or that it restored none; the result depends on storage location, manifest rules, OS and target versions, transfer type, provider behavior, and the artifact itself. Start by identifying the actual transport. Android Auto Backup and device-to-device transfer are distinct modes. For apps targeting API 31 or higher on Android 12 or higher, data-extraction rules can define separate cloud-backup and device-transfer behavior; applications supporting older Android versions may also need the corresponding legacy rules. Some manufacturers do not make android:allowBackup=false disable device-to-device transfer, even when cloud backup is disabled. Therefore a single manifest flag, an emulator restore, or a successful cloud test cannot establish the behavior of every supported path. Record OS level, target SDK, installed build, transport, and effective rules for each test. Inventory each piece of restored state by its purpose and storage source. A user preference that selects a model is not the model. A database row that says downloaded is not a file check. A file placed under a system-backed app directory may follow different inclusion rules from data placed in cache or no-backup directories, and transfer rules can differ between cloud and device migration. Inspect the configured file domains and the actual paths used by the downloader; do not infer inclusion from a product label such as internal storage. Avoid quoting one universal backup-size limit because limits depend on the documented transport and platform context. External document URIs need a separate check. Android backup guidance warns that a restored URI can be invalid or point somewhere different on a new device. A remembered URI or persistable-grant flag is not evidence that the new installation can still open the model bytes. Re-resolve the URI and attempt a bounded read under current permissions before presenting the artifact as available. If access fails, offer an explicit re-selection or supported repair path. Never convert a content URI into a guessed filesystem path or silently broaden storage access to make restoration appear successful. Reconcile artifact identity before enabling an inference action. Check that the exact expected artifact or revision is present in an app-controlled location, has the expected length or other available integrity evidence, can be parsed by the intended runtime, and passes a representative readiness check. If the available source provides no trusted digest, report that verification limit; do not manufacture a pass from a matching filename or persisted database value. Keep model readiness separate from application installation, restored preferences, network availability, and prior success on the old device. Make the first post-restore screen reflect that evidence. If the artifact is missing, stale, inaccessible, or rejected by the runtime, show a recoverable not-ready state and preserve unrelated restored user data. The user may choose to reselect a local artifact, defer setup, or begin a supported download after seeing its network and storage consequences. Do not start a potentially large transfer merely because a restored preference says that the user previously selected a model. A past choice on another device is not permission for unannounced traffic on this device, especially when the current connection may be metered or roaming. Test cloud restore and device transfer independently, including an offline launch after each. Use fixtures with a restored selection and no artifact, an artifact with the wrong revision, an invalid external URI, and a valid local artifact. Observe actual files and network requests rather than inferring behavior from a preference flag. A model-dependent offline task is ready only after its required local asset and runtime checks succeed under the tested configuration. If a user elects to download after restore, test that separate recovery flow and describe its limits without claiming that every device or transport behaves the same way.
A new phone restores settings but not a usable model
After Android device setup, a local assistant opens with a restored model selection and a saved ready flag. Its large artifact was excluded from the selected backup path, while a saved provider URI no longer resolves on the new phone.
Decision
Check the transport rules, resolve the artifact from current storage, and run the required local readiness checks before trusting restored metadata or offering any transfer.
Expected outcome
The app explains that inference is not ready, preserves other restored data, and waits for the user to reselect or explicitly approve a repair download.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Backup and restore state inventory
- Artifact and consent reconciliation
- Network-denied readiness and recovery tests
A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.
Implementation workflow
- Map restore modes and versions. Record source and target OS, target SDK, app build, cloud or device-transfer route, manifest attributes, and the XML rules that apply to each supported version. Test the modes separately rather than using one successful restore as a universal result.
- Separate preferences from artifacts. List model IDs, selected revisions, downloaded flags, consent choices, database records, content URIs, model files, caches, and temporary data. For each item, trace its real storage path and inclusion or exclusion rule instead of inferring behavior from its name.
- Verify restored references. On first launch, check the selected artifact identity, current file existence, readable length, available integrity evidence, and URI access. Reject stale flags and unresolved references without guessing paths or deleting unrelated user state.
- Gate readiness on local checks. Initialize the intended runtime only after the artifact passes applicable checks. Keep installation, restored selection, file presence, runtime load, and a representative offline task as distinct states with a recoverable outcome for each failure.
- Require a fresh choice for repair traffic. When a required model is absent, show the user whether re-selection or download is available and what network or storage cost is known. Do not start a large or metered transfer based only on a backup preference or consent recorded on another device.
- Exercise both transports offline. Test cloud restore and device-to-device transfer with missing, mismatched, inaccessible, and valid artifacts, then deny the network and run the dependent task. Record visible state, artifact identity, and requests without saving prompts or private media.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Cloud-backup and device-transfer inclusion rules are recorded separately for each tested OS, target SDK, and release configuration.
- A restored preference or URI never marks a model ready without verifying the current artifact and required runtime checks.
- Missing or invalid artifacts do not trigger hidden network traffic, delete unrelated restored data, or enable a false offline-ready state.
- A model repair download requires a current user choice with the available network and storage consequences disclosed.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Restored model preference | Treat it as a user selection to reconcile | It identifies intent or a previous state, but does not prove the referenced artifact was transferred or can be opened. |
| Cloud Auto Backup | Apply the effective cloud-backup rules | File domains, excluded directories, platform version, and backup configuration determine what is restored. |
| Device-to-device transfer | Apply and test its own transfer rules | Do not infer D2D behavior from a cloud test or from android:allowBackup alone. |
| Model readiness after restore | Verify artifact, runtime, and offline task | An installed app or restored “ready” value is not proof that inference can run locally. |
Failure patterns to prevent
- Assuming model binaries are backed up
- Restoring consent without user review
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: Back up user data with Auto Backup
- Android Developers: Data backup overview
- Android Developers: Test backup and restore
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
If Android restored the selected model ID, can the app show the model as ready?
No. The ID is metadata. Resolve the current artifact, check its identity and readability, and run the applicable runtime readiness check before enabling a model-dependent action.
Does android:allowBackup=false disable every kind of transfer?
Do not assume so. For apps targeting Android 12 or higher, behavior can vary by manufacturer and may disable cloud backup without disabling device-to-device transfer. Test the relevant modes and inspect their configured rules.
Should a missing model download automatically after restore?
Not solely because a saved preference says it was selected before. Present a truthful not-ready state and ask for a current choice before a potentially large transfer, especially when its network or storage cost is uncertain.