Android Model File Access and Permission Errors

Direct answer

When an Android app cannot read a local model file, first determine which storage boundary owns the file and which access mechanism granted permission. An app-owned file in internal or app-specific external storage is governed by the app’s lifecycle and sandbox; a user-selected document is usually accessed through a content URI with a grant that can be temporary, revoked, or restricted by its provider. A raw filesystem path does not prove that the file still exists or that the app may read it. Diagnose ownership, URI, grant, volume, and open result separately before retrying. Do not “fix” every failure by requesting broad storage permission. Android’s Storage Access Framework lets the user select a document and grant access to that item. The app should use the returned content URI through ContentResolver, not manufacture a file path from the URI string. If access must survive process recreation, determine whether the picker returned a persistable grant and retain it only when that is part of the product flow. Even a persisted grant can be revoked, and a cloud document provider may become unavailable. Handle those cases as unavailable access, not evidence that the model bytes are corrupt. Keep the import-access error distinct from content validation. A provider can deny or revoke access before any bytes are read; that differs from reading a document whose MIME type is generic, whose file contents are malformed, or whose model format is unsupported. A permission error should guide the user to reselect or restore access. A parser or digest error should follow the artifact-validation policy. Do not repeatedly retry a URI that consistently returns permission denied, and do not copy bytes into an active model location before access and validation complete. For app-owned files, verify that the path is derived from the current application context and storage location, that the directory exists, and that the volume is mounted. Internal app-specific files are private to the app and are normally removed when the app is uninstalled; external app-specific files can have different availability and lifecycle characteristics. A path remembered across migration, reinstall, package change, or removable-volume loss may be stale. Query current storage state and rebuild the expected path from the current configuration instead of assuming an old absolute string is valid. When reporting the error, state what was observed and what the user can do. “The selected document is no longer available to this app; choose it again” is appropriate for a revoked user grant. “The model file is corrupt” is not justified if the app never read its bytes. If the app’s own file is missing, explain that the model must be restored through a verified product route if one exists; do not invent a download. When the source and current model identity are unknown, ask the user to reselect or use the documented model-management action, while preserving the active model and user data. Log only safe diagnostics: app build, model configuration identity, storage category, redacted URI authority if policy permits, grant status, volume state, lifecycle stage, and error category. Avoid full URI strings that may contain identifiers or access tokens, file contents, prompts, account data, and raw stack traces in user-visible support bundles. Record whether permission was missing before open, revoked during use, or returned an I/O error after open; those states lead to different recovery paths.

A selected model document grant was revoked

A user selected a document in the system picker, later revoked access, and the app still has a URI in local preferences. The next open fails before any model bytes are read.

Decision

Identify a revoked document grant, request reselection or a supported model route, and keep the active model unchanged.

Expected outcome

The app reports an access problem rather than file corruption and does not request broad access to unrelated storage.

Evidence to collect

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

• Storage-location record
• Permission and import state
• Denied, revoked, and retry outcomes

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

Implementation workflow

1. Classify storage ownership. Identify whether the file is internal app storage, app-specific external storage, a removable volume, or a user-selected content URI. These locations have different access and lifecycle rules.
2. Check current access. Rebuild app-owned paths from current context and verify directory and volume state. For document URIs, check the saved grant and use the documented resolver rather than guessing a disk path.
3. Respect grant lifetime. Persist URI permission only if the returned flags and product flow permit it. Offer reselection after expiry or revocation and do not use broad storage access as a shortcut.
4. Separate opening from validation. If bytes cannot be read, report an access error. Run format, length, trusted-digest, and runtime checks only after a candidate stream has been opened.
5. Protect active state. Read and validate replacements in a separate candidate location, switching only after required checks. Access failure cannot delete the current working model or user data.
6. Test denial and storage loss. Cover picker cancellation, temporary grant loss, persisted-grant revocation, offline provider, volume removal, stale path after update, and successful reselection on a representative test device.

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

Acceptance criteria

• The error identifies storage boundary and observed access result; it does not claim corruption before bytes are read.
• User-selected documents use granted content URIs without guessed paths or unnecessary broad storage permission.
• Revoked or unavailable access offers reselection or documented recovery and leaves the active artifact unchanged.
• Diagnostics redact URI credentials, user content, prompts, account identifiers, and private model data.

Decision table

Failure patterns to prevent

• Requesting broad storage access
• Treating external files as trusted

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 privacy and security
• Android Storage Access Framework
• ContentResolver API
• Android app-specific storage

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

Frequently asked questions