But i encountered this when importing a backup in the applounge app named “simpan” (a notes app).
When I chose import, a list of apps that could be chosen as file source appeared. However the /e/os builtin app Files was not among it. Seeing that no other app on my phone could access the file, I needed to download an extra file manager (any probably would have worked). That one did show up in the apps list and I could proceed to import.
I am not fully sure if I should have filed a bug report at the maker of simpan.
But as I havent seen the Files app listed as app file source ever, I went here first.
Not sure if I grasp your point…
What file-type are we talking?
The file type for installation of an app in android is usually .apk (like eg .exe in windows)
In case you try to open an .apk the system will usually ask whether you want to allow the source of that file (source being a file manager or some alternative app-store or else) to execute (if not done already). Then you allow and then that source should be listed afterwards…
This is not about app installation.
This is about importing (probably any filetype, but in this case a .simpan file) into an app.
The simpan app lists apps that are file providers in order to retreive a .simpan file.
But apparently the system app “files” in /e/os is not registered as a file provider.
Only after installing a different files app from the applounge, that one will be registered as a file provider, and I can retreive the .simpan file from the file system using it
To add to my knowledge I asked chatgpt what may be the problem here and got this answer:
Chatgpt response
In Android, it’s quite common for apps with file import functionality to rely on other apps to provide the files. This is part of Android’s content provider and Intent system, which promotes inter-app communication and avoids duplicating file management functionality in every app.
Key Concepts:
File Provider Apps (or Document Providers)
Apps that allow file selection (e.g., file managers, cloud storage apps like Google Drive, Dropbox) implement the Storage Access Framework (SAF) and act as document providers.
They expose their files through a standardized Android interface (DocumentsProvider).
Examples:
System Files app (e.g., “Files by Google” or manufacturer-specific file managers)
Google Drive, Solid Explorer, FX File Manager, etc.
How File Import Works
When your app requests a file (e.g., via ACTION_OPEN_DOCUMENT or ACTION_GET_CONTENT Intent), the system shows a file picker dialog with all available document providers.
The user selects a file from any of these apps, and your app gets a content URI (content://) to access it (with permissions).
Should the System Files App Be a Provider?
Yes, the default system file manager should act as a document provider. Most Android devices include a built-in file manager that supports SAF.
If a device lacks one, Google Play Services often provides “Files by Google” as a fallback.
Why Don’t Some Apps Show Direct File System Access?
Security & Scoped Storage: Since Android 10 (API 29), direct access to arbitrary files (e.g., via File API) is restricted. Apps must use SAF or MediaStore for shared storage.
Simplicity: Relying on ACTION_GET_CONTENT or ACTION_OPEN_DOCUMENT lets users pick files from cloud services, downloads, etc., without the app handling filesystem paths.
Example Code to Request a File:
val intent = Intent(Intent.ACTION_OPEN_DOCUMENT).apply {
addCategory(Intent.CATEGORY_OPENABLE)
type = "*/*" // Any file type, or specify e.g., "image/*"
}
startActivityForResult(intent, REQUEST_CODE_FILE_PICK)
Key Takeaways:
File providers are apps implementing DocumentsProvider.
The system files app should be a provider (but some low-end devices might lack one).
Your app doesn’t need direct filesystem access—using Intents is the standard way.
Would you like help handling the received file URI in your app?
I’d love to debug this, but Simpan being commercial (and closed source) makes reproduction hard without buying it. Do you happen to know a FOSS app where you saw similar behaviour? the benefit is: you really see what action / intent the app developer uses.
What file browser App did you use eventually to get at the import file? if it works with MaterialFiles I can compare.
AOSP->Lineage->/e/ built-in documentsui for sure implements the GET_CONTENT action and one of its sub packages (/.archives.ArchivesProvider) is registered documents provider. It should be up to something else.
(I’m wary of full LLM answers in forums, even if in a detail wrapper. Agreed it’s good for context).
I agree it would be good to see this reproduced in a foss app with similar import functionality. I can’t come up with one yet however.
In the meantime i picked up my old phone which has google files as the system files app.
And: there it is also not listed as a file providing app when selecting import from simpan!
Ok, so this would turn my post more into a feature request than a bug report. (If you want to take a googled system as base level at all)
It was material files that i installed, which did show up in the list.
gpt, why didn’t you just say so?FileProvider is offered by androidx / jetpack and is a contentProvider subclass - this is what you want for documentsui to link against in its FilePicker to be helpful for Apps like Simpan.
That Google didn’t already port documentsui to use it seems like I’m either missing something or they’re busy with Google Files