Clean-Install Testing for On-Device Models

Direct answer

A clean install of a model artifact begins with the application still installed and the model-owned destination empty. It tests the path from an explicit user decision through transfer or supported import, integrity checks that are actually configured, runtime initialization, and a representative first task. It is not the same as uninstalling the Android app, wiping application data, reinstalling the package, or restoring backup state. Keep those test conditions separate or the team will not know whether a failure belongs to the model-delivery path, app first-run flow, database migration, permissions, or stale device files. Define “clean” in observable terms. Confirm the app build and configuration, remove only model artifacts that the test owns, inspect active and temporary locations, and verify no candidate or cache is being reused. Do not delete user history or reset unrelated preferences to make the test convenient. If user consent for a transfer is part of the flow, record its state separately. A model-only clean install should be repeatable while preserving the installed app and test account; an app reinstall test should have its own fixture for app data, permissions, backups, and retained external files. Run the test as a state sequence rather than a single screenshot. At the start, the model manager should report no model or a clearly unavailable state. Before the first network request, the UI should disclose the artifact, available size evidence, network rule, storage implications, and cancellation choice. During transfer, capture expected and observed lengths and the temporary path. After completion, run configured verification; if no trusted digest is configured, record that limitation rather than claiming SHA-256 success. Then load the exact artifact with the intended runtime and run a defined task. “File downloaded” and “model works” are different assertions. Test failure and recovery from an empty model store. Cancel before transfer, interrupt network, fill storage, reject a malformed or mismatched candidate, remove the selected external source, and force runtime initialization failure. Verify each case leaves a clean state that can recover, and that a failed candidate never becomes active. If cleanup removes model-owned bytes, ensure it does not touch conversations, imported files, or database records. Confirm retry begins with a new or valid candidate identity; never append bytes to an unknown leftover file. Reproducibility requires a manifest for the fixture. Record app build, model config revision, artifact identifier, expected size source, digest availability, storage volume, network condition, test account and app data setup, and every initial file location. Keep seed artifacts in a controlled test fixture and record the expected checksums only when they are obtained from a trusted source. Compare the final filesystem inventory and manager state to the test oracle. A fresh emulator snapshot can help, but also test a physical device or storage condition only if the test scope calls for it; do not generalize results beyond the recorded environment. Keep “clean model install” distinct from “reinstall app with model assets.” The latter can involve backup restoration, uninstall cleanup, signing updates, database schemas, consent renewal, and files outside app-managed storage. A model-only test instead evaluates delivery while the app identity and its non-model data remain. If the product bundles the model inside an app package, test the package artifact and split delivery separately; a model-download test cannot establish what an APK or App Bundle contains.

Install a model into an already-installed app

QA keeps the app database and consent state but removes every model artifact and partial download. The team wants to test model delivery and first use, not package uninstall or database recreation.

Decision

Reset only model-owned storage, record the baseline, then test disclosed transfer, configured checks, runtime load, one task, and recovery from failure.

Expected outcome

The result isolates model delivery while preserving app identity and user-owned data, making failures reproducible.

Evidence to collect

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

• Fresh app state
• Artifact transfer record
• First task and reinstall result

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

Record the fresh app state, the artifact transfer record, and the first task and reinstall result. Compare each of these recorded items against the same measurements taken after the reinstall sequence completes.

1. Declare the fixture boundary. State that the package stays installed and identify preserved database/preferences. Enumerate model-owned active, partial, staged, cache, and import locations that must begin empty.
2. Record a baseline. Capture app build, model configuration, target volume, network condition, permissions, selected variant, manager state, and file inventory before user interaction.
3. Test the disclosed start choice. Verify that artifact identity, available size evidence, network/storage impact, consent, cancel, and defer are explained before transfer or import begins.
4. Observe transfer and checks. Capture artifact identity, accepted ranges, observed final length, and the actual configured verification outcome. If expected digest is absent, record no digest result rather than passing it.
5. Load and execute a defined task. Initialize the intended runtime with the candidate, record manager transitions, and run a deterministic input fixture. Keep successful load distinct from output and task correctness.
6. Inject failures and repeat. Test cancel, low storage, network interruption, invalid candidate, removed source, and load error. Ensure failed candidates never become active and the next test starts from known state.

Acceptance criteria

• The application remains installed and its data/consent fixture is preserved while only model-owned test data is cleared.
• Identity, transfer, supported verification, runtime load, and first task are recorded as distinct assertions.
• Partial, failed, or unknown candidates cannot become active, and recovery does not erase user-owned content.
• The result is not presented as proof of app uninstall cleanup, backup restore, package signing, or bundled-model contents.

Decision table

Failure patterns to prevent

• Testing upgrades only
• Reusing hidden cache state

Avoid limiting release wording to testing upgrades only and to reusing hidden cache state. Release decisions must be tied directly to the recorded evidence rather than to assumptions about upgrades or to assumptions about background state.

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 app-specific storage
• Android persistent background work
• Android StorageManager API
• RFC 9110: HTTP range requests and validators

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

Frequently asked questions