That's the intents system. You just declare that you want a file. A picker then opens up with every app that has files available, the user selects one, and you get a handle to it.
* Apps are only allowed to access only files that the user explicitly allows them access to. (No more Epic games launcher slurping up your Steam library information)
* Apps can present file-like objects to the file picker and have them work transparently. (No more one-off filesystems to just forward an API call)
* Apps don't have to know anything about permissions. You just get a blob of data.
> * Apps are only allowed to access only files that the user explicitly allows them access to. (No more Epic games launcher slurping up your Steam library information)
This assumes that all content you possibly want to open in a different app always consists of a single atomic file.
Unfortunately that's not always the case, though. If you open a HTML file from your storage, you'll likely want your browser to be able to access the accompanying images, style sheets, other locally linked files, etc., too, but under Google's file access model that's not possible. Or say you open a video file where you've also thrown some subtitles into the same directory - unfortunately your video player will only be able to open the video itself and never even learns about the subtitles.
For a small demonstration, just copy some archived web pages to your storage and then try using the built-in file explorer (which uses the officially sanctioned way of content://-URIs for launching apps) to view one of those HTML files in either Android's mini HTML viewer app or else Chrome and marvel at the missing images, broken styles, non-working links...
> * Apps can present file-like objects to the file picker and have them work transparently. (No more one-off filesystems to just forward an API call)
> * Apps don't have to know anything about permissions. You just get a blob of data.
Unfortunately it also completely hides the underlying file system, so even if the file in question is one that a) is actually sitting on the local storage and b) is stored somewhere where the receiving app would have access permissions itself anyway (because you've explicitly allowed that app to access that part of the storage), you still have no official way to get a reference to the original file. This is a problem because if the receiving app could open the file (and accordingly also its companion files) using its own permissions, it could in fact avoid the issues resulting from the first point. As it is, you're somewhat stuck, though.