An Android app can open a file successfully today and fail to open the same file tomorrow even though the file still exists. This often looks like a storage bug, but the real issue is how Android grants access to user-selected documents. Modern Android does not always hand an app a permanent file path. Instead, it often gives the app a URI permission that can be temporary, persistable, or invalidated when the underlying document changes.
This matters most with document editors, PDF tools, backup utilities, note apps, media managers, cloud-storage clients, and any app that uses Android’s system file picker. If you understand the difference between a file path and a document URI, many “file disappeared” or “permission denied” problems make more sense.
Modern Android often gives apps a document URI instead of raw storage access
Android’s Storage Access Framework lets an app ask you to choose a document, folder, or save location using the system picker. The picker can show local storage, Downloads, SD cards, USB drives, and cloud providers that integrate with Android.
After you choose an item, the app receives a content:// URI representing that document. The URI is not just a disguised file path. It points to a document exposed by a storage provider, and the app needs Android’s permission grant to read or modify it.
This design improves privacy because an app can work with the document you selected without receiving blanket access to all storage.
Why a file can work once and fail after the phone restarts
Android can grant temporary read or write access to a selected document. The Android developer documentation notes that a normal URI grant can last only until the device restarts unless the app explicitly takes a persistable URI permission.
That is why some poorly designed apps behave like this:
- You choose a PDF from the system picker.
- The app opens and edits it normally.
- You reboot the phone.
- The app’s “Recent files” list still shows the PDF.
- Tapping the item now produces “permission denied,” “file unavailable,” or another error.
The app may have remembered the URI string but failed to preserve the permission needed to use that URI after reboot.
A persistable URI grant is the mechanism for long-term access
When an app uses the right file-picker action, Android can offer a persistable URI grant. The app must then explicitly call Android’s persist-permission API to keep that access across device reboots.
This is not automatic. The picker can offer persistent access, but the receiving app has to take it. If the developer forgets, the app may behave correctly in testing and still break later after a restart.
This is one reason two apps can open the same file through the same system picker yet behave differently days later.
Persistent does not mean permanent under every circumstance
Even after an app properly takes persistable access, Android’s documentation warns that access can still fail if the associated document is moved or deleted.
The reason is that the permission applies to the document represented by that URI. If the storage provider can no longer resolve that document at the same identity, the old permission does not magically follow the file wherever it goes.
This can happen with:
- a file moved to another folder by a file manager;
- a cloud document renamed or reorganized in a way the provider treats as a new item;
- a document deleted and recreated with the same visible filename;
- a USB drive removed or a cloud account signed out;
- a provider app clearing or changing its document database.
The filename is not the identity Android is relying on
A common mistake is to assume that if notes.pdf still exists somewhere, the old app permission should work. Android’s Storage Access Framework is not based on matching filenames.
Document providers expose document IDs and URIs. Two files with the same name can be different documents, and one document can sometimes appear in different locations without changing its underlying identity. The provider controls that relationship.
That is why copying a file, deleting the original, and giving the copy the same name can still break the app’s saved reference.
Why reinstalling an app can break previously selected files
A reinstall creates a fresh app installation state. Even when the documents themselves remain in shared storage, the new installation should not be assumed to retain the old app’s previously granted URI permissions.
This explains a frustrating pattern: your files survive the uninstall, you reinstall the same app, and the app can no longer reopen them until you choose them again in the system picker.
The important distinction is between the document surviving and the app’s authorization to use it. Shared-storage files can remain after an app is uninstalled, while the app’s local state and prior grants do not necessarily carry over as a usable authorization context.
If you are migrating or reinstalling an app, do not assume the APK plus the visible documents are a complete backup. APKApps Cloud’s article Copying an APK Is Not Backing Up the App explains why app state and access relationships can be lost even when the installer file is preserved.
A saved “recent file” entry may point to a dead URI
Many apps store a list of recently opened documents in their own database. That entry may include the display name, a timestamp, and the URI used to open the file.
If the URI grant has expired or become invalid, the recent-files screen can still show the document because the app saved the text label locally. The UI is remembering the file; Android is no longer authorizing access to it.
This is why deleting the recent-files entry and selecting the document again can sometimes fix the problem without touching the actual file.
ACTION_OPEN_DOCUMENT and ACTION_GET_CONTENT are not identical
Android provides several ways for an app to ask the user for content. For long-term document workflows, ACTION_OPEN_DOCUMENT is designed around a document that the app may continue to use. Android’s documentation describes the returned access as capable of being made persistable.
By contrast, content-selection flows intended for importing or consuming a copy of something may be more temporary in nature. An app that only needs to import a photo once may not need long-term access at all.
The correct API depends on the app’s job. A photo uploader and a document editor should not necessarily handle selected files the same way.
Folder access uses the same principle, but at directory-tree scope
Android’s ACTION_OPEN_DOCUMENT_TREE lets you choose a directory and grant an app access to that directory tree, subject to Android’s restrictions. This is useful for file managers, backup tools, editors, and apps that need to work with a user-selected folder rather than one file.
Again, the app must preserve the permission properly if it expects access to survive restarts.
Android 11 and later also restrict which directories can be granted through the tree picker. For example, apps cannot use the picker to gain unrestricted access to the root of internal storage or to other apps’ protected app-specific directories.
This is related to why Android/data can look empty in ordinary file managers even while apps are using gigabytes of storage.
Cloud files add another layer of failure
The Storage Access Framework can expose documents from cloud providers, not just local storage. That is convenient, but it means file access also depends on the provider being available.
A previously valid URI may stop working if:
- you sign out of the cloud account;
- the provider app is removed or disabled;
- the provider changes how it identifies a document;
- the file is moved or deleted in the cloud;
- the provider temporarily cannot reach the network.
The app receiving the URI cannot guarantee that the remote provider will always keep that document available.
Why “Storage permission is allowed” may not fix the problem
Users often respond to a file-access error by opening Android’s ordinary Permissions screen and enabling Photos, Videos, Music, or Files access. That may be irrelevant.
Storage Access Framework grants are user-selected URI permissions. The app can access a specific selected document without receiving broad storage permission. Conversely, broad media permission does not automatically restore a lost document URI grant.
This distinction is important because modern Android intentionally separates broad media access from user-selected document access.
Do not clear app data as your first troubleshooting step
Clearing app storage can delete the app’s database, saved recent-file list, account state, settings, and other local information. If your problem is simply a stale or expired document URI, clearing everything is a large and unnecessary step.
First try reopening the document through the system picker. If the app then works, the problem was likely access state rather than a corrupt file.
APKApps Cloud’s App Cache vs App Data guide explains why clearing storage is much more destructive than clearing temporary cache.
What to do when one file suddenly becomes inaccessible
- Check whether the file still exists. Open it in the system Files app or another trusted app.
- Check whether the file was moved or recreated. Same filename does not guarantee same document identity.
- Use the original app’s Open or Browse command. Select the file again through Android’s picker.
- If the file is cloud-hosted, confirm the provider account is signed in and online.
- If access disappears after every reboot, suspect that the app is not persisting the URI grant correctly.
- Avoid clearing app data until you have backed up any local-only information.
What to do when an entire selected folder stops working
If an app used to manage a whole folder, first confirm the folder still exists and has not been moved. Then check whether the app has a setting to reconnect or choose the folder again.
Re-selecting the same directory through the system picker can establish a fresh grant without requiring a reinstall.
If the failure happens after a reboot every time, that points more strongly to an app implementation issue around persistent URI permissions.
Why backup and restore may not recreate every document relationship
Android backup can restore supported app data, but a backed-up database entry containing a URI is not the same thing as a guaranteed restored authorization grant. Even if the app remembers “which file” it used before migration, the new device may require you to select the document or folder again.
This is especially common when the file lives on a different storage volume, cloud provider, SD card, or directory structure after migration.
For the broader limits of Android restore, see How to Back Up Android Apps—and What the Backup Does Not Save.
Moving a file can be more disruptive than renaming it looks
Some storage providers can preserve a document’s identity through certain changes; others may effectively create a new document when content is moved. You cannot reliably predict this from the filename alone.
If an app is maintaining a long-term working library—PDF annotations, music projects, design files, encrypted vaults—use the app’s own move or relink function when available instead of reorganizing the files externally and hoping the saved references continue to work.
What a well-designed app should do
An app that expects long-term document access should request the right picker action, take persistable URI permissions where appropriate, detect when a saved URI is no longer usable, and ask the user to reconnect the document instead of crashing or silently losing work.
It should also avoid pretending a stale recent-file record means the file is still authorized. Good error messages distinguish “file missing” from “permission lost” from “storage provider unavailable.”
The safest mental model
When Android gives an app access through the system picker, think of it as a permission-backed reference to a document, not a permanent ownership transfer.
The document may survive an uninstall. The app’s saved list may survive a backup. The visible filename may remain unchanged. None of those facts alone prove the current app installation still has a valid grant to read or edit the document.
If access fails, reselect the item first. That simple step often tells you whether the problem is the file or the permission relationship around it.