> But in most situations involving External Storage, the SAF is really what you want to use anyway.

Or not. A File Picker does not work for playlists, linked MKV/MOV files, subtitles autodetection (subfolders and such), and so many other multimedia cases.

Also, it is a pain to use from the NDK... And incorrectly documented.

And then, the UI to allow people to give you access to the folders is extremely confusing, hard to explain to users, not customizable, and changes from version of Android to another, so very hard to document.

> Or not. A File Picker does not work for playlists, linked MKV/MOV files, subtitles autodetection (subfolders and such), and so many other multimedia cases.

Exactly. HTML files are another victim of this, as with content://-URIs there's no official way to properly resolve relative URIs for any subresources (images, style sheets, scripts and whatnot) or local links, and even if you could, you wouldn't have the permission to access those files anyway. Even Android's included mini HTML-viewer app (or Chrome for that matter) are broken if you try viewing a HTML file using a content://-URI, e.g. from the file explorer that's built-in since Marshmallow.

I opened https://issuetracker.google.com/issues/77406791 for that, but you can guess at the reply I received so far (none - I guess I should be glad they didn't close it outright...)

And another problem is that even if your app has the appropriate storage permissions itself (whether through READ_EXTERNAL_STORAGE or the new-fangled way, even if that means dealing with the SAF) and could therefore open both that file and its companion resources without relying on the permissions attached to the content://-URI intent, in practice that's rather difficult because even for local files there's no official link between the content://-URI and the file system location. In practice at least some ContentProviders will leak the path through the URI, allowing you to reconstruct the original file path with a little luck, but that's of course not really a reliable method.

Agreed that the UI could be WAY more intuitive. There are issues with it default-opening for saving to an unwritable directory (confusing people), not being clear about why you're there (no way to instruct the user what purpose they're selecting a file for except the "open"/"save" button), the side drawer is not intuitive for new Android users who might not know there are more services beyond the Download folder, etc. There are too-limited sorting options, the MIME filtering could be extended, etc. Older versions of the framework didn't even let you suggest what saved files should be called...

In the case of a sophisticated media player like VLC I totally get your point. The solution before Q was just to ask for the READ/WRITE storage permissions and have full access. I guess they figure that's too broad access for one app to have.

Upsides-- it works great on Chromebooks, integrating with ChromeOS well, and the convenience of seamlessly integrating a single UI with numerous cloud services with no extra SDKs to include or APIs to learn is also a big plus.

So how would a file manager work then? I have used several file managers over the years that allowed me to conveniently manage files locally and remotely. E.g. extract the downloaded zip file locally, edit ome of them, copy these 20 selected extracted files via SCP and delete these three folders.

Granted, I only do that on a phome in a pinch but having these features saved me more than once. I dom't want Android to become as restrictive and underpowered as iOS feels to me.

The Framework lets you ask for access to a whole directory, not just individual files.

How is that solving the issue? How can that result in a local and remote file manager with a consistent GUI?

The file manager would ask you to pick (using the Android UI, via SAF) the directory where you had downloaded the zip, then everything would work the same.

Alternatively, the app can register itself as opener of zip files, then it could extract them freely to its own private directory (without asking for permissions) and let you list and upload them.

This is all a load of crappy workarounds leading to a convoluted and cumbersome user experience. From a usability perspective, I would not consider such a behavior a solution.

That's because you like general purpose file managers. But most people would much rather that their calculator app didn't have access to their photos.

The alternative is malware having free reign over the entire filesystem. This is a real problem which is happening today. With your all-or-nothing solution the user has no ability to limit what files an app can access, which is totally unacceptable.

Apps need my permission to access external storage even today. I don't see how a convoluted UI helps here.

Although it may not be international (I think intentions are good), this change will devalue internal device storage to such an extent that people will see themselves forced to store even more data in cloud services of dubious reputation. Technically, they don't have to, but it will likely be easier for the masses.

> Apps need my permission to access external storage even today. I don't see how a convoluted UI helps here.

Consumers tend to just click past permission prompts, hence granting malware permission to everything. Power users can take care of themselves, of course, but most consumers don't have the technical knowledge to safely deal with this kind of permission prompt.

The major problem isn't replacing the blanket READ_EXTERNAL_STORAGE permission with something a little more fine-grained, but the fact that after requesting access to some user-picked directory tree, apps still have to go through the Storage Access Framework with all its warts and deficiencies instead of being able to use normal file system access if the picked directory is part of the local storage.

If it had been implemented that way, there still would have been some usability problems (some users will likely always manage to pick the wrong directory and then wonder why the app doesn't work), but other than that it would have caused much less trouble.

I've seen it as "use the file picker to select the parent folder" which works fine

The SAF APIs are cumbersome garbage up there with Account Manager and ContentProviders. Its missing important providers like DropBox, and even Google Drive doesn't implement it completely.

If a provider is missing it's because the developer of that app didn't create one.

Exactly. DropBox for example used to support the SAF and then for some reason pulled it, whereas Box.com's app supports it...

> Reading from the content:// URI is a little different than from a file://

I haven't found the reading part to be different, but getting the uri has changed from Uri.fromFile() to their FileProvider package. Which, requires quite a bit of setup in comparison.

To be fair, it's documented well on the Android developer site.

But there are some APIs that don't work, e.g. ExifInterface (that you need to properly process image orientation) can only read from InputStream starting with r24, and you need access to the raw File before that [0].

[0] https://developer.android.com/reference/android/media/ExifIn...

> then Android's built-in file picker starts up

This is not a good thing for VR apps. Unless there's a VR system file picker in the works that I'm unaware of..

I'm curious.

Suppose you're a VR app and you invoke a picker to open a... I don't know... you want to open a sound file. How should the picker's UI be to fit into your general VR interface?

If a sound file is particularly badly suited, then some other kind of file (but in that case I'm interested in why that's easier/better than sound).

Not sure I understand the question exactly. Generally, a file picker UI could look exactly the same in VR as it does out of VR, just projected on a flat surface.

The crucial point is to remain inside the stereoscopic VR view since exiting VR is very disruptive.

Boxes and drawers. A sound file could be in a collection of records or CDs or tapes. Making it just like real life is like having your users start off with the manual already read.

I’m afraid a general Android VR item picker will be a lot more boring though.

And thus was born Microsoft Bob.

Rather older versions of Macs! With binders where you put files into, and dragging items around, and most of the applications being items on an office desk.

Nowadays I guess the surface studio is a good example. Being laid out like a drawing table and interacting with it like a drawing table.

On new devices, this often opens an empty file picker. That's so helpful to a user...