Direct answer
A resumable download is not simply a request that retries after a timeout. The client must know which artifact it is fetching, where partial bytes live, what the server’s range response means, how a changed entity is detected, how progress is reconciled, and when the temporary file becomes eligible for final placement. Cove’s current downloader source records storage precheck, temporary-file writing, HTTP Range resume requests, byte progress, a configured mirror for selected connection failures, optional SHA-256 verification when a digest exists, and a final rename. Those source-code facts describe the current implementation; they are not evidence that a public APK is available or that every server honors resume semantics. Keep four states separate: transfer started, transfer has partial bytes, transfer response completed, and artifact verified and placed. A timeout may leave a partial file that cannot safely be appended if the remote representation changed. The client should retain validators such as an entity tag or last-modified value when the protocol and server provide them, compare response metadata, and restart rather than combine unrelated byte ranges when identity cannot be established. A 200 response to a range request may mean the server ignored the range; appending that full response to an existing partial file would corrupt the artifact. Treat response status, content range, expected length, and checksum as validation inputs rather than relying on the progress bar. Use a unique temporary path per artifact revision. Do not overwrite a working model while an update downloads. If the process stops, persist only the identifiers and transfer metadata needed to resume; on restart, reconcile file length with server response before continuing. Report a progress denominator only when the expected length is known and consistent. If the source does not provide a trusted digest, say integrity is not fully verified; length alone detects some truncation cases but does not prove authenticity. Never silently mark a file ready just because the HTTP body ended. Choose a lifecycle mechanism based on product behavior. User-visible foreground downloads and deferrable persistent work have different user controls and platform rules. WorkManager can schedule persistent work under constraints, but it does not promise that a transfer continues uninterrupted through every process or network event. Store progress durably, make workers idempotent, and expose cancel, retry, and failure states. Avoid multiple workers writing to the same artifact path; coordinate one transfer per revision and let observers attach to the same job. Before final rename, verify the received representation against the expected artifact identity and any available digest. Then atomically place the file on the same filesystem when possible, reopen it, and let the runtime perform a load check before the UI reports it ready. If verification fails, keep the previous known-good artifact and explain that the new one is not installed. A cache or mirror is a transport choice, not proof of trusted publisher identity. Test a matrix of interrupted points: before response headers, mid-transfer, after the last byte but before verification, during rename, and during runtime load. Include server responses that support Range, ignore Range, return a changed entity, or terminate early. Keep logs free of authentication tokens and signed URLs. Implementation sequence: 1. Assign an immutable artifact identity and temporary path; capture expected length and a trusted digest only when the release source supplies them. 2. Persist transfer revision, byte count, and available HTTP validators. On resume, ask for the remaining range and validate status, Content-Range, entity identity, and response length before appending. 3. Make progress, cancellation, retry, and mirror selection explicit; ensure one worker owns each artifact revision and process recreation cannot start competing writers. 4. Verify length and digest when available, rename atomically, reopen the final path, and perform a runtime load check before marking the model ready. 5. Preserve the old artifact and user data on failure; record the stage and offer a bounded retry rather than silently deleting content. A safe download pipeline proves each state transition. It does not convert transport completion into a distribution or compatibility claim.
A large model download is interrupted on a train
A user starts downloading a model on a metered mobile connection. Signal disappears partway through, the app process is later recreated, and the user returns expecting to continue rather than restart or open a corrupt file.
Decision
Resume only when artifact identity and byte-range metadata match; otherwise restart into a clean temporary file and keep the previous usable artifact.
Expected outcome
The interface reports saved progress honestly, verifies the completed artifact, and exposes the stage if recovery cannot continue.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Partial-response evidence
- Temporary-file identity
- Interrupted transfer tests
A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.
Implementation workflow
- Create an artifact-scoped temporary transfer. Key the temporary file and worker by immutable model revision. Store expected length, optional trusted digest, and the response validator without placing authorization tokens or signed query parameters into ordinary logs.
- Validate the resume response. Before appending, inspect status code, Content-Range, total length, entity tag or other available validator, and the current temporary-file length. Restart if the remote representation cannot be shown to match the partial bytes.
- Reconcile durable progress after restart. On process recreation, compare persisted byte count with the actual file and the server response. Ensure a unique-work policy prevents a second worker from writing concurrently to the same revision.
- Verify before final placement. Check complete length and a trusted digest when one exists, rename the temp file atomically when possible, reopen it, and request a runtime load check before showing ready. Keep the previous artifact if any stage fails.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Resume never appends bytes from an unverified or changed remote representation.
- Only one writer owns an artifact revision, and process recreation produces a consistent progress state.
- The model is not labeled ready until available integrity checks and runtime loading succeed.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Retry from byte zero | Simple restart into a fresh temp file | Works when safe resume identity cannot be established, but discards partial transfer progress. |
| HTTP Range resume | Append only after response identity checks | Can reuse partial bytes when validators and Content-Range confirm the same artifact. |
| Model marked ready after HTTP completion | Transport-only status | Insufficient; integrity, placement, and runtime load remain separate checks. |
Failure patterns to prevent
- Appending a full response
- Resuming across revisions
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 persistent background work
- Cove ModelDownloader implementation
- Android Developers — persistent background work
- IETF HTTP semantics and range requests
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does HTTP Range guarantee a correct resume?
No. The client must verify the server response and representation identity. If a server ignores the range or the entity changed, appending can corrupt the file; restart safely when the response cannot be reconciled.
Is a complete byte count proof that the model is authentic?
No. A length check can detect some truncation but not publisher identity. Use a trusted digest or signed release metadata when the source provides it, and state clearly when integrity remains partial.
Does WorkManager promise a download never stops?
No. It provides a persistent work mechanism with constraints and lifecycle behavior, not uninterrupted network availability. Design durable progress, idempotent writes, cancellation, and retry states.