[jbk]

> 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.

[iggldiggl]

> 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.

[fattire]

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.