Direct answer
A model download storage precheck should estimate the space needed for the exact operation that is about to happen, then compare that budget with a current measurement from the destination volume. Do not use a universal “free space above X gigabytes” rule or multiply model parameters into a pretend installation size. A transfer may use a partial file, a completed candidate, a retained active model, caches, and user-authored data at the same time. The precheck must state which of those bytes are included and must leave enough room for the application’s tested recovery path. Start with an artifact identity and its measured or configured byte length. The configured length is evidence about a specific manifest or code snapshot, not a measurement of every release. If the value is missing, stale, or a placeholder, do not turn it into a precise storage promise. Determine whether the update is performed by writing a separate candidate while the old model remains active, replacing in place, or using another tested strategy. A safe candidate-swap design normally needs room for the existing active artifact and the candidate simultaneously. Add partial-transfer data only if the current operation retains it, and count caches or derived files only when the workflow actually creates them. Choose an API that matches the decision. Android documents StorageManager.getAllocatableBytes() as appropriate for deciding whether an allocation can proceed, because the system may reclaim cache to satisfy a request. A user-facing free-space display has a different purpose and can use a value intended for display. StatFs.getAvailableBytes() describes bytes available to applications on a filesystem path; it is not a reservation and can change after the query. None of these values guarantees that a long download will complete, so re-check at meaningful stages and handle allocation failures after the precheck. Make the budget explicit and auditable. For each required file, record whether the amount is exact, measured, expected from a manifest, or a conservative allowance. Keep the destination volume and its UUID or path distinct from application-wide storage. If an optional cache can be reclaimed, distinguish it from user data and active artifacts; never silently delete conversation history or photos to make room. If the system reports enough allocatable space only by reclaiming cache, communicate that boundary accurately and let the platform manage cache rather than inventing an application cleanup claim. A precheck is a user decision point, not merely a boolean guard. If the estimate exceeds available allocatable space, do not start a transfer that is predictably unable to finish. Offer a clear explanation and supported actions: cancel, choose a different artifact or destination if the product supports that, remove a specifically identified model through a separate consented flow, or open system storage management. Explain if keeping the old model during an update requires extra temporary space. If a user elects to proceed despite uncertainty, record that choice but do not bypass file-write errors or mark a partial candidate ready. The result should be scoped to the current artifact and operation. It is not a device compatibility rating, minimum RAM recommendation, installed-size guarantee, or universal model requirement. Record the model revision, size source, destination, measured availability, budget components, test device and storage conditions, and outcome. Re-run after a storage change or before a separate update attempt. This gives support and QA enough evidence to reproduce a decision without claiming every phone behaves identically.
Update a model without removing the working copy
The active model must remain usable while a candidate is written. Partial bytes and user history also occupy the destination device, so a final-file-only estimate is insufficient. QA is checking a specific revision before showing a start button and deciding whether to defer or ask the user to manage space.
Decision
Budget the files that coexist in the implemented update strategy, query the target volume, and defer or offer an explicit reversible choice when the evidence is insufficient.
Expected outcome
The app starts only when its measured operation budget is supportable, keeps user content untouched, and can recover from storage loss after the precheck.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Exact artifact length
- Simultaneous-copy policy
- Insufficient-space path
A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.
Implementation workflow
- Pin artifact identity. Read the revision and expected length from the exact manifest or configuration used for this operation. If the value is missing, stale, or a placeholder, mark it unknown instead of deriving a precise estimate from parameter count.
- Map simultaneous files. List the active artifact, candidate, partial transfer, verification copy, caches, database, and user files. Include only objects that the chosen install or update algorithm can truly have at the same time.
- Query the destination volume. Use an Android API whose semantics match the decision: allocatable space for an allocation check and a separately labeled free-space estimate for display. Record volume and time because available space may change.
- Document the budget. Identify each value as exact, manifest-expected, measured, or a safety allowance. Explain cache reclaimability and why any margin exists; do not present a margin as a universal phone-compatibility threshold.
- Offer a reversible outcome. When measured space is insufficient or uncertain, offer cancel, defer, system storage management, or a supported artifact choice. Do not remove user data or the active model automatically to make room.
- Inject later write failures. Test low storage during transfer, final write, verification, and promotion. Confirm the prior model remains usable and that partial state has a tested recovery path or consented cleanup action.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Each estimate names one artifact revision, destination volume, and actual file lifecycle for the selected operation.
- A configured length is not described as measured installed size, RAM need, or a device-wide minimum requirement.
- Low space never silently deletes user content or promotes an incomplete candidate over the active model.
- The system handles storage failure after the check; a precheck is not treated as a guarantee of future capacity.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Allocatable bytes | Use to decide if an app allocation can proceed. | The system may reclaim cache; the value can change and is not a reservation. |
| Available filesystem bytes | Use as a labeled user-facing free-space estimate for a path. | It does not promise that a long transfer or update will finish. |
| Configured artifact length | Use to plan a known candidate file from its manifest. | It excludes active models, temporary copies, app data, caches, and runtime memory. |
Failure patterns to prevent
- Checking final file only
- Starting a doomed transfer
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
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Can downloads be blocked below one fixed space threshold?
A universal threshold is usually too coarse. Base the check on the exact artifact, volume, active-model retention, temporary files, and tested recovery strategy, and state uncertainty instead of asserting a device-wide rule.
Does Android allocatable space guarantee a model transfer will finish?
No. It helps decide whether an allocation can start and may include reclaimable cache, but space can change during a transfer. Recheck as needed and handle write failure at every stage.
Should the app delete conversations to make room for weights?
No. User-authored data and model artifacts have different ownership. Offer a separate consented flow for eligible model files or system storage settings; do not silently remove history or media.