Large Model Downloads on Metered Networks

Direct answer

A metered-network policy should control when a large artifact transfer begins, not make unsupported assumptions about what a connection costs. Android exposes network capabilities and Data Saver preferences that applications can use to reduce background data usage. Those signals do not reveal the user’s exact carrier price, remaining allowance, roaming contract, or whether a Wi‑Fi network is free. The app should present its own transfer choices: defer until an unmetered network, allow a user-started transfer with a clear warning, pause in background under Data Saver, or continue only when the user’s explicit setting permits it. Do not treat “Wi‑Fi” as a synonym for unmetered. Android allows networks to be marked metered, including Wi‑Fi, and the user or system can change that state. Recheck network capability before starting and while a transfer runs. Handle loss, change from unmetered to metered, Data Saver activation, and background restrictions as normal state transitions. If the app cannot determine the network status, label it unknown and ask the user rather than guessing. The model artifact may be large, but this page does not claim Cove has a publicly downloadable APK or a published model download. The current fact card records a source-code download implementation, not a public distribution URL. Use this guide for application design and user control, not as an installation promise. A good policy separates the size estimate from billing. If expected file length is known and verified against a source manifest, show it with a timestamp and explain whether the figure refers to a model file, patch, or complete bundle. Do not estimate network charges from file size because radio overhead, retries, compression, and carrier plans vary. Let the user choose: download now, wait for unmetered, pause, cancel, or open settings. Make retries resumable only when artifact identity and range responses can be validated. Background scheduling introduces another boundary. WorkManager constraints can defer a task until the chosen network requirement is met, but a long-running transfer still needs durable state, cancellation, retries, and a visible way to resume. The app must decide what happens if the user switches networks mid-transfer, disables background data, revokes storage permission, or exits. Avoid repeated automatic prompts or silently starting a very large transfer after install. Testing should cover the system signal and the user policy separately: unmetered Wi‑Fi, metered Wi‑Fi, cellular metered, Data Saver on, app foreground/background, network changes during a partial transfer, and unknown status. Use emulator or test-network configuration to simulate metered Wi‑Fi where supported; never toggle a customer’s actual network settings as part of a hidden test. Record the action and result without logging credentials or private user content. Acceptance sequence: 1. Inspect active network capabilities and Data Saver state through the documented Android APIs; define an explicit unknown branch. 2. Present file-size provenance and user choices before a large transfer; do not infer a bill or unlimited data status. 3. Apply a persistent-work constraint only when it matches the selected policy, and preserve a visible pause, cancel, and retry state. 4. Test network transitions and process recreation; resume only after checking partial-file identity, response range, and current user choice. A responsible app respects the user’s data decision and Android’s signals without claiming to know the carrier contract.

A model transfer begins on metered Wi‑Fi

A user joins a hotel Wi‑Fi network that Android reports as metered. An app has a multi-gigabyte candidate artifact and wants to avoid silently consuming a limited plan while still allowing the user to proceed.

Decision

Treat Android network capabilities as an input to policy, show the file-size source and available actions, and ask the user when the status or consequence is uncertain.

Expected outcome

The transfer starts, defers, pauses, or cancels according to a visible choice rather than an assumed network price.

Evidence to collect

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

• Network-state behavior
• User choice record
• Pause and resume test

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

Implementation workflow

1. Read current network and Data Saver signals. Use documented connectivity capabilities and data-saver status. Treat a network marked Wi‑Fi as potentially metered, and represent missing or changing status explicitly as unknown rather than defaulting to free.
2. Explain the actual transfer estimate. Display verified expected file length and clarify whether it is one artifact or the complete bundle. Avoid estimating carrier charges or promising that a Wi‑Fi connection has no data limit.
3. Offer visible user controls. Provide download now, wait for unmetered, pause, cancel, and retry choices. Do not silently trigger a very large model transfer after installation or repeatedly prompt after the user has selected a policy.
4. Re-evaluate during background work. Handle network changes, Data Saver activation, process recreation, cancellation, and partial bytes. Resume only if the artifact and range response match and the current user policy still allows the transfer.

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

Acceptance criteria

• Metered, unmetered, and unknown network states produce explicit, testable policy branches.
• A large transfer is initiated only after an allowed user or policy action, with a visible pause and cancel path.
• Network change and resume never bypass user choice or combine bytes from different artifact revisions.

Decision table

Failure patterns to prevent

• Starting silently
• Assuming Wi-Fi permanence

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 Developers — optimize network data usage
• Android Developers — read network state
• Android Developers — persistent background work

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

Frequently asked questions