Android App Update During an Active Model Download

Direct answer

An app upgrade during a model transfer is a version-compatibility event, not merely a network interruption. Before resuming, compare the old and new app build, transfer-state schema, artifact identity, expected metadata, and partial-file format. The new version must either prove it understands the persisted state or reject that state and start a safe replacement candidate. Do not assume a worker survives an update, that it stops cleanly, or that its database record and temporary bytes still agree. Reconcile actual files and recorded identity after the upgraded process starts; only then decide whether to continue, restart, or request user action. The project’s ModelDownloader writes an in-progress artifact to a temporary file, makes a Range request using the existing length, and may verify an optional SHA-256 before attempting final rename. ModelManager’s current startBackgroundDownload method is backed by an in-process coroutine scope rather than a WorkManager Worker; the repository fact therefore does not justify promising that a download continues across app upgrades. The E2B configured digest is empty, and E4B metadata remains placeholder. These code facts make an upgrade test especially important, but they do not show that an actual user update corrupted a file or that Cove currently has a public update channel. Android accepts an app update only when the update is compatible with the installed package identity and signing rules, and the delivered version must follow platform version-code policy. That package-level acceptance says nothing about the application’s model-transfer database or temporary-file format. The app must own that compatibility contract. A release that changes the transfer schema should version it and provide a migration or invalidation rule; a changed model revision must never inherit old partial bytes just because the path name stayed the same. Keep app version, transfer-state version, and artifact revision as separate fields. Define the upgrade boundary for every execution mechanism. An in-process coroutine has the lifecycle of its process; if the process exits, its current execution is not a persistent-work guarantee. Persistent WorkManager jobs have their own stored work state and constraints, but the worker’s input schema and code still change across package versions. The correct result depends on the implementation, so test it rather than relying on a generic statement that Android “keeps downloads running.” If a foreground service is used, assess its specific platform requirements separately; do not infer service behavior from the presence of a notification. Persist enough information to decide whether a transfer can resume: work identity, app schema version, artifact id and immutable revision, source identity, expected length and digest provenance, partial path, bytes written, last response range/validator, and last durable phase. On first execution after upgrade, validate every field against the new policy. If the schema cannot be migrated without guessing, quarantine the partial candidate and offer a fresh download or explicit discard. Keep an already-active, known-good model separate from an in-progress candidate, and never remove user notes, conversations, or media as part of transfer-state migration. Test upgrades at meaningful timing points: before the transfer is scheduled, while connecting, during a body write, after bytes are flushed but before state persistence, after the temporary file is complete but before verification, during verification, and after final promotion. Reboot or process recreation tests are separate from package update tests. For each case, assert whether work resumes, restarts from zero in a new candidate, or stops for user action. Compare disk reality with the transfer database and verify that only matching revisions can be appended. Include old app data schema fixtures and an update path from every still-supported prior schema. Communicate the actual state after upgrade. “Updating app” is not “model download complete”; “file exists” is not “verified”; and “verified” is not “loaded.” If the old transfer cannot resume, present a recoverable explanation rather than a generic error or endless retry. Do not claim the model was preserved if the file lives on storage that is unavailable. Keep diagnostics to app build, transfer schema, artifact revision, stage, and error category; exclude prompts, transcripts, authorization headers, and token-bearing URLs. ### Procedure 1. Inventory transfer execution and persistence. Identify whether the app uses an in-process coroutine, foreground service, persistent worker, or a combination; list the data store and file format each mechanism owns. 2. Version transfer state and artifact identity separately. Record old/new app build, state schema, model revision, partial path, metadata provenance, and supported resume policy. 3. Define upgrade reconciliation. On new app startup, compare database state with actual file length, revision, and last response metadata. Resume only when the new code can prove the same representation; otherwise isolate and replace the candidate. 4. Inject app upgrade at each transfer and verification boundary. Assert the chosen resume/restart/repair behavior, active-model preservation, and no mixing of old and new artifact revisions. 5. Update user-facing status and support diagnostics. Report exactly which phase survived, which state was rejected, and what reversible action is available without exposing user content. ### Acceptance criteria - The app does not promise transfer persistence unless its chosen execution mechanism and state migration have been tested across package upgrade. - A new app build resumes partial bytes only when transfer schema, artifact revision, and range metadata remain valid. - Update interruption cannot promote an incomplete candidate or replace the prior active artifact. - User-authored data and unrelated variants remain untouched; unrecoverable state has a clear, non-looping recovery action. ### Comparison | Event | What it tests | What it does not prove | |---|---|---| | Process death/restart | Recovery of the same installed app build | Compatibility with a new transfer schema or package code | | App package upgrade | Old state and files under new code | That a transfer necessarily continues in the background | | Network interruption | Range and partial-byte behavior | That app update migration is safe | ### FAQ **Will Android keep a model download running while the app updates?** Do not assume so. The result depends on the app’s execution mechanism and upgrade path. Test the actual worker/service and state migration; a notification alone does not guarantee persistence. **Can the new app resume an old partial file automatically?** Only after reconciling the old state schema, immutable artifact revision, partial-file length, and response metadata. If those facts are missing or incompatible, isolate the candidate and use a safe restart or user action. **Is an app update the same test as killing the process?** No. Process restart uses the same installed code and schema; an app update can change code, database structure, download behavior, and artifact policy. Test both separately. **What if transfer-state migration cannot be proven safe?** Do not guess or append the bytes. Preserve the active model, quarantine only the uncertain candidate, and explain whether a new download or explicit discard is required.

The app is upgraded while a partial model file exists

A user upgrades the app while a large model transfer is in progress. The new build may change its transfer-state schema or artifact revision. A partial file remains on disk, but the app cannot assume its record, byte range, and file still describe the same release.

Decision

Reconcile package, state schema, artifact revision, and file reality before permitting resume; otherwise isolate the candidate and use a safe restart or user decision.

Expected outcome

The upgraded app either proves a compatible transfer and continues under policy or clearly stops without mixing revisions or replacing the previously usable model.

Evidence to collect

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

• Old and new app and artifact manifests
• Update timing and partial-state fixtures
• Resume, reject, and repair results

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

Implementation workflow

1. Document the actual execution owner. Trace whether transfer runs in a process coroutine, foreground service, persistent worker, or multiple mechanisms. Record each owner’s durable state and do not call an in-process scope persistent.
2. Version the transfer record and artifact. Store old app build, state schema, immutable model revision, source, expected metadata, partial path, last range response, and phase. A filename alone cannot bridge old and new versions.
3. Reconcile before resuming. After upgrade, compare persisted state with the file on disk and new policy. Verify revision, byte offset, and response representation; if any part is ambiguous, quarantine the candidate rather than append.
4. Exercise update fault points. Upgrade while connecting, writing, after a flush, before verification, during hashing, and around final promotion. Separately test process death and reboot to avoid conflating their guarantees.
5. Expose a reversible recovery result. Show whether work resumed, restarted, or needs user action. Preserve the last active artifact and user-created records, and keep diagnostic fields free of private content and credentials.

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

Acceptance criteria

• Persistence claims match the actual execution mechanism and tested app-upgrade path.
• Partial bytes resume only when state schema, artifact identity, and response metadata remain compatible.
• Interrupted migration cannot promote a partial file or replace the active artifact.
• User records and unrelated artifacts are preserved, with a clear recovery choice for rejected state.

Decision table

Failure patterns to prevent

• Assuming worker state is compatible across releases
• Mixing old partial bytes with a new artifact

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 persistent background work
• Android app updates and package compatibility
• Android WorkManager persistent work and constraints
• IETF HTTP Semantics and range responses

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

Frequently asked questions