Direct answer
A first-run model download should be an explicit, reversible setup choice, not a surprise side effect of opening the app. Before transfer begins, identify the exact artifact or explain which values are still unknown, state its size only when a trustworthy manifest or configuration supplies it, explain the storage and network decisions the user can make, and offer a clear way to start, defer, or cancel. The application should remain useful enough to explain setup while the model is absent. It must distinguish “app installed,” “download requested,” “bytes received,” “artifact verified,” and “model ready for this task.” Do not promise a completion time unless the application has a defensible estimate and can explain its uncertainty; a byte count is not a time estimate. This flow is different from an in-progress download notification. The first-run question occurs before the transfer: should this person begin now, on this network, with this artifact? Notifications and progress controls matter after that choice. A screen that says “Continue” without showing the artifact’s identity, approximate storage consequence, or network policy has not gained meaningful consent merely because the button was tapped. If a reliable size is unavailable, disclose that uncertainty instead of inventing a rounded number. The current Cove facts describe a configured model size and downloader behavior, but this draft does not claim that Cove has a public release or that every user sees a particular first-run screen. Map the user journey as separate states. A fresh install can show an explanation and available choices; a deferred user can enter other screens that do not require inference; an accepted download can show queued or connecting status; a transfer can be paused or canceled according to implemented behavior; a complete file may still require integrity checks; and a verified file may still fail to initialize in a runtime. Only the last state that has actually been tested should unlock the task. If an app has an offline use case that can work without the model, preserve that route. If all meaningful AI work needs the artifact, say so before the user commits rather than discovering it after a blocking screen. Build the information hierarchy around decisions rather than internal implementation. The primary choice is start, not now, or cancel. Supporting information should answer: which model or pack is involved; who provides it; the evidence for its size; where it will be stored in broad terms; whether a network preference can be selected; whether another task is available during setup; what happens if the device goes offline; and what “ready” means. Avoid displaying a fabricated progress bar before bytes move. Do not use “installing” as a synonym for “downloading” if the application has later verification or runtime-load phases. The project downloader has a storage precheck, temporary file, range request, byte progress, optional digest verification, and final rename. Those code facts support clear explanations of stages, but they do not prove a background-completion guarantee. Android’s guidance distinguishes persistent background work from work that exists only inside a process. If the product offers “continue in background,” the selected scheduling mechanism and its cancellation, constraints, notifications, and process-recreation behavior must be tested. Otherwise, describe the supported in-app behavior without implying that dismissing the screen leaves transfer active. Use evidence-based copy. A size statement should name the artifact revision or provide a way to inspect it; distinguish downloaded bytes from installed storage when both matter; state whether the value is exact, approximate, or unknown; and avoid treating model parameter count as a file-size measurement. Explain whether network policy is automatic, user-selectable, or not yet verified. If metered-network behavior is configurable, expose the choice before bytes start and honor it after the user acts. If the product cannot currently offer a reliable choice, do not put a mock selector in the design and claim that it works.
First use on a constrained connection
A traveler opens a newly installed offline assistant before boarding. The model is not yet present, network availability is limited, and the user needs to know what will happen before authorizing a transfer.
Decision
Show only artifact facts supported by a versioned source, explain the available network and storage choices, and offer start, defer, or cancel before any bytes are requested.
Expected outcome
The user can leave setup without a hidden transfer, return later, and see separate transfer, verification, runtime-load, and task-ready states.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Exact artifact facts
- User cancellation test
- Return-to-download flow
A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.
Implementation workflow
- Map model dependencies. List each screen and task that works without the model and each one that requires a specific artifact revision. Validate those boundaries in code and fixtures so that a marketing phrase or an asset filename never gets mistaken for working offline capability.
- Trace size provenance. Tie a displayed byte count to a versioned manifest or model configuration and label what it measures. If the source is missing or stale, show an unknown value and explain the uncertainty instead of deriving a download promise from parameter count.
- Expose choices before transfer. Place start, defer, and cancel controls before the first request. Describe the network policy and storage precheck in language that matches the implementation, and do not display a selectable Wi-Fi or metered option unless the build honors it.
- Separate readiness states. Represent app installation, consent, queued work, received bytes, artifact verification, runtime initialization, and task readiness as separate states. On relaunch, compare persisted state with the actual file before restoring a completion message.
- Test refusal and failure paths. Exercise not-now, cancel, app backgrounding, process recreation, network loss, insufficient storage, verification failure, and runtime-load failure. Record the visible next action and prove that no failed or partial file becomes the active model.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Before the first request, the screen identifies the artifact, evidence for any size, network policy, and available start/defer/cancel actions.
- Choosing defer does not schedule hidden work; returning later reopens a truthful setup choice rather than stale consent.
- Transfer, verification, runtime initialization, and task readiness are visibly distinct, with recoverable actions for failed phases.
- Background-continuation copy is present only when the chosen scheduler and its constraints, cancellation, notifications, and recreation behavior are tested.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Start now | Use when artifact identity and network/storage choices are clear. | A tap starts the supported work; it does not make the model immediately ready. |
| Defer | Use when the user wants to explore or wait for a preferred network. | The choice must not start an invisible download or consume consent later. |
| Cancel | Use after a transfer has started when cancellation is implemented. | Explain whether partial bytes remain or are removed; do not imply either behavior without a test. |
Failure patterns to prevent
- Surprise download
- Promise of background completion without test
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
- Cove Gemma 4 model page
- Android persistent background work
- Android network access and connectivity guidance
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Should every screen be blocked until a model downloads?
No. Block only tasks whose verified dependencies are missing. Keep safe setup, settings, or other non-model functions available, and label model-dependent actions unavailable until actual readiness checks pass.
Can the first-run screen promise a fixed download time?
Only when a representative estimate and uncertainty are measured. File size alone cannot predict a user’s throughput, interruptions, storage latency, or verification time, so avoid a fixed promise when those inputs are unknown.
Does a completed download mean the model is usable?
No. Transfer can finish before integrity verification, and verification does not prove runtime initialization or task execution. Keep these states separate and enable the task only after its required checks succeed.