That you can still do. The future notion is that that storage directory is yours, and apps don't have total access ("write anywhere, read anything, delete whatever"). FBReader cannot dump some more ebooks in that directory.
FBReader has a directory of its own, and can provide other apps with access to ebooks or other files in that directory, mediated by its own code, access-controlled as it pleases.
It doesn't sound bad to my ears, except that the APIs involved need love and attention, and their documentation even more so.
(Edit: Not picking on FBReader, just using it as an example.)
> The future notion is that that storage directory is yours
One problem is that unless I want to plug my phone into my computer each time I need to manage the storage or use the rather limited built-in file explorer, I'm going to have to use some third-party apps myself (that I have decided to be trustworthy enough) in order to manage "my" storage. From Google's point of view those apps remain third-party-apps though, and as such remain subject to some set of restrictions.
> FBReader has a directory of its own, and can provide other apps with access to ebooks or other files in that directory, mediated by its own code, access-controlled as it pleases.
I don't want my ebooks to "belong" to FBReader, though. Now yes, you can still do that as long as you only open the books from inside the respective reader apps (copy your ebooks into a general ebooks directory on the storage and then give each of your reader apps permission to access that directory), but
> can provide other apps with access to ebooks or other files in that directory, mediated by its own code, access-controlled as it pleases.
Google wants the above to be the only way to pass file references around between apps, which is stupid when
a) that file doesn't actually conceptually belong to the sending app, and
b) the receiving app would have had permission to access that file itself anyway.
As Google has currently implemented content://-URIs for example, even if FBReader has been explicitly granted access to my ebooks directory, if I happen to open a book from my file explorer instead, then because in that case the access is "mediated by" the file explorer, FBReader cannot reliably tell that the incoming file is actually one that is already part of its library, so I potentially end up with a duplicated LRU/history entry, my reading position might not properly remembered because FBReader doesn't know whether those two files are in fact one-and-the-same or not, and, and, and... And if I happen to switch my file explorer app and uninstall the old one, all references to files opened through the file explorer become invalid, even if FBReader had permission to directly access the file by itself, too.
FBReader has a directory of its own, and can provide other apps with access to ebooks or other files in that directory, mediated by its own code, access-controlled as it pleases.
It doesn't sound bad to my ears, except that the APIs involved need love and attention, and their documentation even more so.
(Edit: Not picking on FBReader, just using it as an example.)