On-Device Model Cache Cleanup Policy

Direct answer

Model cleanup should operate on a classified storage inventory, not on a broad directory wipe. Distinguish the active model, pending candidate, resumable partial file, derived cache, logs, and user-created records. Give every managed artifact an owner, identity, path, and recoverability rule. Cleanup should select only items whose identity is known and whose retention policy allows deletion; it should not infer that a file is disposable from its extension or age alone. When space is insufficient, explain the tradeoff and ask for a reversible user choice rather than deleting conversations, notes, images, or the only working model. The local ModelDownloader exposes deleteModel, which removes the configured model file and its temporary partial file. ModelManager can search a shared model directory and an app-specific fallback directory, and the shared directory behavior differs from app-specific storage on uninstall. This repository code shows why cleanup must know both path and ownership. A cleanup command created for one variant should not delete a different variant’s file, and a shared directory should not be wiped by one app without coordination. These observations describe code; they do not establish actual user data loss or a universal Android storage guarantee. Define storage classes explicitly: active executable artifact, candidate under verification, incomplete transfer, cache derived from a model, app preferences, conversations or history, imported media, and transient diagnostics. For each class record owner component, artifact revision, whether it can be regenerated, whether user confirmation is required, and whether another app module can read it. Derived caches can often be rebuilt only if their sources remain available; the model itself may require a trusted re-download. User-authored data should not be treated as a cache even if it is stored next to model files. A cleanup run should be idempotent and auditable. Build a deletion plan first, show category totals based on actual file metadata, and make the plan safe to repeat. Protect files currently mapped by an inference engine or owned by an active download. Use a lock or owner protocol before deleting. Remove stale partial files only after reconciling them against a durable transfer record; a partial file may be resumable. After deletion, verify expected targets are absent and unrelated paths remain. If deletion fails, preserve a clear error state rather than reporting space reclaimed. Operating-system storage policy adds boundaries. Android app-specific external files are tied to the app’s lifecycle, while shared or user-selected documents have different owners and permission lifetimes. Do not assume one app’s uninstall, permission, or cleanup behavior applies to other locations. Use documented storage APIs and user-selected access where needed; do not request broad access simply to simplify deletion. Backups and transfers are separate from local cleanup, so removing a local file does not prove every backup copy was erased. Test cleanup with a fixture tree containing two variants, an active file, candidate file, partial file with known transfer state, orphan partial with no state, derived cache, a conversation database, and user media. Attempt cleanup under normal state, active inference, ongoing download, insufficient space, permission loss, and concurrent module access. Assert only policy-approved paths disappear. Test restore/re-download separately and avoid claiming that a model is available offline until verified again. ### Procedure 1. Inventory storage paths and owners. Map each directory to app, model identity, revision, user-data category, and access scope; include shared and app-specific paths. 2. Classify records by lifecycle and recovery: active, candidate, partial/resumable, derived cache, user-authored, or transient. Mark which categories require explicit confirmation. 3. Produce a dry-run cleanup plan with concrete paths and expected outcomes. Exclude active or locked files and reconcile partial transfers before deletion. 4. Execute only approved deletions through the owning component, then inspect the actual filesystem and preserve failures for user recovery. 5. Run isolation tests with multiple variants, user data, concurrent download/inference, permission changes, and app reinstall; verify unrelated files and history remain intact. ### Acceptance criteria - Every deleted path is mapped to a known artifact or cache identity and approved lifecycle rule. - Active, candidate, or potentially resumable files are not removed while in use or without reconciliation. - User-created records and unrelated model variants remain untouched unless the user explicitly selects them. - The app verifies deletion outcomes and reports failure honestly; cleanup never implies backup erasure or offline readiness. ### Comparison | Storage class | Typical cleanup decision | Required caution | |---|---|---| | Temporary partial transfer | Retain if identity and resume state are valid; otherwise isolate | Do not delete during an active writer or assume it is useless | | Derived cache | Rebuild or remove when dependencies change | Preserve source records and key cache by model/runtime revision | | User-authored history/media | Keep unless the user explicitly requests deletion | Do not classify as disposable model cache | ### FAQ **Can an app delete every file in its model directory to free space?** Not safely without classifying paths and checking active ownership. The directory may contain another variant, a candidate, or a resumable transfer; user content may also be stored elsewhere and must remain protected. **Is every temporary model file disposable?** No. A partial file can be safely resumable if its artifact identity and transfer state remain valid. Reconcile it with the owner record before cleanup. **Does deleting the local model erase backups too?** Not necessarily. Local deletion, Android backup, device transfer, and user exports are separate storage flows. Make no broader erasure claim without testing each destination. **Can cached embeddings or summaries be deleted with the model?** Only after checking dependency and rebuild rules. Keep user source records, and invalidate derived data based on model/runtime identity rather than deleting an entire database.

A storage warning prompts cleanup before a model update

An app has an active model, a candidate under update, a partial file left by an earlier attempt, derived results, and user history. A user asks to free space but does not want conversations or the working model lost.

Decision

Show an inventory by storage class, protect active owners, reconcile partial state, and remove only identified items that policy permits.

Expected outcome

The user can choose reversible cleanup actions, and the app confirms exactly what was deleted while preserving user data and the current usable artifact.

Evidence to collect

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

• Storage inventory
• Deletion tests
• Recovery after cleanup

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

Implementation workflow

1. Enumerate paths and owners. Inspect app-specific and shared directories, resolve each file to model/variant/revision where possible, and identify who can write or read it.
2. Classify active and recoverable state. Separate active, candidate, resumable partial, orphan partial, derived cache, user record, media, and diagnostics. Consult the transfer owner before marking partial bytes disposable.
3. Present a dry-run plan. Summarize actual candidates by category and state. Exclude open or locked files and allow the user to select categories rather than offering an opaque “clear all” action.
4. Delete through the right owner. Use the component responsible for the artifact, coordinate shared storage access, and keep deletion idempotent. Preserve a result for each path rather than assuming all deletes succeeded.
5. Verify filesystem and recovery. Confirm approved paths are gone, active and user paths remain, and failed deletions are reported. Test re-download or cache rebuild separately before claiming readiness.

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

Acceptance criteria

• Cleanup selection is based on classified identity and policy, not broad directory matching or extension.
• Active inference, active download, resumable files, and user-authored data are protected.
• Every attempted deletion has a verified result and any failure has a recovery message.
• Local cleanup is not described as backup erasure or proof of offline readiness.

Decision table

Failure patterns to prevent

• Deleting user history with model cache
• Leaving orphaned partial files

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 app-specific storage
• Android Storage Access Framework
• Android Auto Backup behavior

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

Frequently asked questions