Large on-device models turn first launch into a delivery system. A reliable Android flow checks storage before transfer, writes to a temporary file, resumes safely, validates the completed artifact, switches it into place atomically, exposes explicit lifecycle states, and gives users a useful recovery path. A progress bar alone is not model download UX.
Tell the user what happens before starting
Before transfer, show:
- exact artifact size for this app version;
- additional temporary or update space required;
- selected network and whether mobile data is allowed;
- whether the download can continue in the background;
- whether interruption is resumable;
- what core features remain unavailable until completion;
- how to cancel and remove partial data.
Avoid “about” values when the application already knows the expected artifact length. If the server may deliver another size, the updater must treat that as a versioned change rather than silently altering the storage requirement.
The first-run experience should also explain why the model is separate from the app package. Users need to understand that the one-time setup enables later local inference, not that the app is unexpectedly downloading their data.
Model the lifecycle explicitly
Cove’s current ModelManager exposes explicit not-downloaded, downloading, downloaded, loading, ready, and error states. It searches configured storage locations, serializes model loading, and deletes the artifact after a load failure before returning to a not-downloaded state.
That state machine prevents the UI from inferring readiness from a file that merely exists. A complete file may still fail validation or runtime initialization. Conversely, a recoverable temporary file should not be presented as a completed model.
A useful product-level state model separates transfer and runtime:
not-present -> checking-space -> downloading -> verifying -> installed
installed -> loading -> ready
-> load-failed -> repair-requiredExpose repair as an action. “Something went wrong” without delete-and-retry or resume leaves the user stranded with storage consumed by an unusable artifact.
Resume only when the server confirms it
Cove’s current downloader writes into a temporary file and sends an HTTP Range request using the existing temporary length. It appends only when the server responds with partial content; otherwise it restarts the temporary file. This distinction matters because appending a full response to partial content corrupts the artifact.
Resume metadata should be tied to artifact identity. If the model URL or revision changes, an old partial file must not be resumed into the new artifact. Store the expected revision and length next to the temporary file or encode identity in its path.
Test interruption at different points, including before the first progress event, during transfer, after the final byte, and during verification. A resume feature tested only by pausing the UI is not enough.
Temporary files and final placement
The final model filename should appear only after verification succeeds. Until then, use a clearly separate temporary path. This prevents process restarts from mistaking an incomplete file for an installed model.
Final placement should be checked. A rename operation can fail because of storage behavior, permissions, or destination conflicts. After placement, verify that the final file exists, has the expected identity, and can be opened. Do not emit a completed state solely because the input stream reached end-of-file.
Updates need two slots or another recoverable strategy. Replacing the working artifact before the new one is verified can turn an update failure into a total loss of functionality.
Integrity is not optional evidence
The current Cove downloader can calculate and verify SHA-256 when a digest is configured. On mismatch, it deletes the temporary file and reports an integrity error. When no digest is configured, that verification path is skipped.
Cove’s current Gemma 4 E2B configuration has an empty SHA-256 field. Therefore the site and app must not claim that the current artifact is hash-verified. Filling the digest from the actual pinned artifact is a release task, not a marketing detail.
Length validation and cryptographic integrity answer different questions. The expected length can catch truncation and some version mismatches. A trusted digest verifies exact bytes against the release manifest. Keep the manifest in version control and review it with the code that changes the artifact URL.
Storage checks need update headroom
The currently pinned Cove Gemma 4 E2B LiteRT-LM artifact records an expected length of 2,583,085,056 bytes. That exact number is useful for its own storage precheck. It is not a universal Gemma size and should not be copied into another product without using the same artifact.
Storage planning must include the temporary file and, during safe updates, both the old working artifact and the new candidate. Also account for database, cache, and user-generated content. “The model fits in remaining storage” may still be false if the update procedure temporarily needs another full copy.
When storage is insufficient, show the required amount and offer a direct path to retry after cleanup. Do not begin a transfer that predictably fails near completion.
Network fallback without artifact ambiguity
Cove’s downloader supports a configured mirror after timeout or DNS failure on the primary source. A mirror can improve reachability, but both destinations must serve the same pinned artifact. The release manifest should verify that assumption rather than treating matching filenames as proof.
Record which source completed the transfer for diagnostics. Do not expose internal exception dumps to users, but preserve a structured category such as DNS, timeout, HTTP response, read failure, integrity failure, storage, or placement.
Background execution and cancellation
Android’s official persistent background-work guidance distinguishes durable scheduled work from ordinary in-process work. A downloader should use and test an appropriate lifecycle mechanism before promising that a large model transfer will finish in the background.
Android may stop work when the app leaves the foreground unless the transfer uses an appropriate lifecycle mechanism. The UI should never promise background completion until that path is tested under process recreation, lock screen, network change, and power constraints.
Cancellation must close the network connection and choose whether to keep the temporary file for resume. Make that policy visible. “Cancel and keep progress” and “cancel and remove download” are different actions.
Download test matrix
| Area | Cases |
|---|---|
| Storage | insufficient, exact boundary, update with old artifact present |
| Network | primary success, timeout, DNS failure, mirror, redirect |
| Resume | server accepts range, server returns full response, stale partial file |
| Integrity | expected artifact, wrong length, wrong digest, missing digest |
| Placement | destination exists, rename fails, process dies after verification |
| Lifecycle | foreground, background, lock screen, process recreation |
| User control | cancel and keep, cancel and delete, retry, remove installed model |
| Runtime | installed artifact loads, load fails, repair flow succeeds |
Release checklist
- Pin the artifact revision and expected length.
- Record and verify a trusted digest.
- Keep temporary and final filenames distinct.
- Resume only after a valid partial response.
- Bind partial files to artifact identity.
- Verify final placement before reporting completion.
- Preserve the previous artifact until an update is ready.
- Test background and process recreation honestly.
- Normalize user-facing error categories.
- Provide retry, repair, and delete controls.
- Keep website size claims synchronized with the actual release manifest.
Continue with RAM requirements for runtime memory and how to test an on-device model for the measurement record.
Last reviewed: 2026-09-16.