Recover When Android Model Storage Volume Is Removed

Direct answer

A storage-volume loss should be handled as a change in artifact availability, not as proof the model was deleted or corrupted. Identify the exact path and volume that holds the artifact, query the platform state for that path, and separate “not currently accessible” from “file missing,” “integrity failure,” and “runtime failure.” If the active engine has a file mapped from that volume, stop or release it through the runtime owner before retrying file access. Keep the artifact identity and user state, then decide whether to wait for the volume to return, use an app-specific copy, or ask the user to select a recovery source. The project ModelManager uses a shared directory beneath the primary external-storage directory and an app-specific model directory as fallback. It searches both locations for the selected model filename, and its downloader chooses a directory based on current storage-access state. This is evidence of multiple storage paths in the code; it does not establish that Cove supports a removable SD card or that any named volume is safe for model execution. Android’s “external” storage can be emulated and backed by internal data. Describe the exact configured location and its observed state, not a hardware assumption. Use platform volume state APIs for the path actually in question. Environment.getExternalStorageState(File) can report states such as mounted, unmounted, removed, read-only, or unknown; StorageManager can enumerate currently available shared/external volumes and, on supported API levels, notify about state changes. These APIs describe availability at a moment or event; a successful state check can race a later removal. File operations can still fail, so handle FileNotFoundException, SecurityException, and I/O errors at the operation boundary and re-check state before a retry. Do not hardcode a removable-volume name or assume a path remains constant across mounts. Separate model storage from user-selected source documents. A model in app-specific storage, a model in shared storage, and a document picked through the Storage Access Framework have different permission and lifecycle rules. Persist a URI grant only when the picker returned one and the app needs later access; a path string alone does not preserve provider permission. If a provider or volume disappears, retain the user’s selection and explain that access is unavailable rather than silently copying or deleting data. Avoid requesting broad storage access just to make fallback easier. Recovery needs an ownership state machine. Track artifact id/revision, expected metadata, source path or URI identity, whether an engine is active, active download state, and last successful verification. On volume loss during download, stop writes and keep only a clearly identified partial candidate; do not mark it complete. On loss during inference, notify the engine owner and transition to a recoverable unavailable state. When storage returns, revalidate actual file identity and integrity before loading. If a verified app-specific copy exists, use it only if the release policy allows that exact identity; do not treat a similarly named file as interchangeable. Test unavailable volume cases without relying on one emulator assumption: unmount before launch, unmount during download, unmount while a model is loaded, switch to read-only state, deny or revoke shared-storage access, reconnect the same volume, reconnect a different volume at a similar path, and corrupt or remove the expected file. Verify user history remains untouched. ModelManager’s fallback search order should be tested alongside the actual path policy. A recovery message should explain whether the app is waiting, searching another owned path, requesting access, or needs a verified re-download. It must not say “model deleted” when the volume is simply unavailable. ### Procedure 1. Inventory each model location: app-private/app-specific, shared external path, and user-selected URI. Record artifact identity, owner, permission source, and whether the path can change. 2. Observe volume state for the relevant path and handle file errors at each operation. Distinguish unavailable, read-only, absent, permission denied, and integrity-failed states. 3. Coordinate the runtime and transfer owner. Release a mapped engine before moving or reopening paths; stop active writes and preserve the transfer record and partial-file identity. 4. Reconcile after remount. Check the same artifact revision, file length and trusted digest when available before loading. Use fallback copies only when identity and policy match. 5. Test loss and recovery at launch, transfer, load, and inference boundaries. Confirm user records survive and UI copy distinguishes unavailable storage from deleted or corrupted data. ### Acceptance criteria - The app identifies the configured path and reports current volume/access state without assuming physical removability. - Volume loss cannot be mistaken for corruption or successful deletion; active engine and writer ownership are resolved safely. - On return, only a matching and verified artifact can load; a similarly named file on another volume is not automatically accepted. - User history and unrelated files remain intact, with a clear wait, access, fallback, or re-download action. ### Comparison | State | Correct interpretation | Unsafe inference | |---|---|---| | Volume unmounted or removed | File path is temporarily unavailable | The artifact is corrupt or erased | | File absent on an accessible volume | Expected path does not contain the artifact | A same-name file elsewhere is equivalent | | Digest or load failure | Candidate failed a content or runtime check | Any storage error is a model-integrity failure | ### FAQ **Does Android external storage always mean a removable SD card?** No. Primary external storage can be emulated and backed by internal data. Identify the specific path and platform state instead of inferring hardware from the word “external.” **Should the app delete a model when its volume disappears?** No. Unavailability is not deletion. Preserve identity and user state, release any active engine safely, and wait, find an authorized fallback, or ask for a recovery action. **Can a same-name file from another volume be used automatically?** Not safely. Compare artifact revision and trusted metadata, and ensure the alternative path is permitted. Filename equality alone does not establish content or provenance. **Does a stored document URI remain accessible after a device change?** Not always. Access depends on the provider grant and whether the provider is available. Re-check the grant and resource, then ask the user to reselect if access cannot be restored.

The model’s configured shared-storage path becomes unavailable

A model is selected and its engine may be loaded from a shared-storage path. The volume changes state while the user is downloading or running a task. The app must distinguish path unavailability from a missing or corrupt model and preserve user records.

Decision

Check the state for the exact path, coordinate the engine/download owner, and only use a fallback that matches the artifact identity and storage policy.

Expected outcome

The app waits, uses a verified permitted copy, or asks for recovery without falsely claiming deletion or losing history.

Evidence to collect

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

• Storage-volume and artifact identity
• Removal at each lifecycle phase
• Fallback, repair, and user notification results

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

Implementation workflow

1. Resolve the storage owner and path. Record whether the configured artifact is in app-specific storage, shared external storage, or a user-picked document URI. Do not label a path removable unless platform state and volume identity support it.
2. Classify the current failure. Observe volume state and the actual file operation result. Keep unmounted, removed, read-only, permission denied, absent file, and digest failure as distinct cases.
3. Stop active use safely. Notify the engine owner and release any mapped file before retrying access. Stop writes from the downloader, preserve its revision and offset record, and avoid deleting the partial file during a transient unmount.
4. Reconcile on remount or fallback. When the volume returns, verify artifact identity and integrity before loading. Search app-specific fallback only if policy permits the same exact artifact, not merely a same-name file.
5. Exercise storage-state fixtures. Test unavailable-at-launch, removal during write, removal during inference, read-only state, permission revocation, same-volume return, and different-volume return. Assert user files remain unchanged.

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

Acceptance criteria

• The UI reports the path and current access state without inferring a removable device.
• Volume unavailability is distinct from model corruption, missing file, permission loss, and successful deletion.
• Remounted or fallback files are checked against exact artifact identity before runtime load.
• The active model and user history are preserved or a clear recovery choice is shown.

Decision table

Failure patterns to prevent

• Assuming external volume remains mounted
• Deleting unrelated application data

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 Environment external-storage state
• Android StorageManager and storage-volume callbacks
• Android app-specific storage

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

Frequently asked questions