File managers still work. Apps are forced to use the Storage Access Framework for accessing shared storage, which means that users can choose the scope for their access. The app can provide a suggestion, but the API is designed to avoid apps from forcing all or nothing access.
Conversation
The built-in file manager will also still be there, and that's the interface used for selecting file and directories when apps use the Storage Access Framework. It finally gives users control rather than apps requesting full shared storage access and refusing to work otherwise.
2
18
SAF is just Google's file manager. That doesn't count.
Ground up implementations of feature rich file managers are being crippled, right? Maybe in R?
1
8
That's not an accurate portrayal of SAF. You're misunderstanding what it implements and how it works. An app can request persistent access to a directory tree, which uses the system UI to ask the user to determine access scope. It's entirely usable for implementing file managers.
1
2
18
SAF is a generic file access API. Apps can use as both a client (like a word processor or a file manager) and as a provider (like an app providing access to cloud storage or a network file system). It's not a file manager. It uses the system file manager UI for choosing scope.
1
14
So, for example, a file manager will request persistent access to a directory tree. The user can select the root of the volume in the SAF system UI to grant full access to the volume. The file manager now has full, persistent access to that storage volume but it's up to the user.
1
20
It's covered in the official documentation on Scoped Storage:
developer.android.com/preview/privac
ACTION_OPEN_DOCUMENT_TREE has been supported since Android 5.0. File managers already had to use it to access external drives, since Android 4.4 removed access that wasn't via the SAF API.
1
1
16
Any file manager supporting external drives in Android 5.x and 6.x already supports the mechanism used to access shared storage / external drives in Android Q. The same thing applies to other apps. Android 7.x+ added a non-SAF option, but it was flawed and is likely obsolete now.
1
11
There are 2 actual complaints:
1) Developers dislike that users are in charge of choosing the scope. One argument is they aren't smart enough to select a volume root for a file manager. It's essentially an argument against user control.
2) The indirection has a performance cost.
1
11
The performance cost is mostly for metadata access and opening files. It can provide more direct access for reads / writes to a specific file. The implementation could get faster. The cost comes from cross-process communication needed for access control and different backends.
1
9
It's not something that matters much for a use case like a file manager. In fact, most real use cases of shared storage aren't impacted. Shared storage was already slower than the app internal storage anyway, especially on devices with the traditional FUSE-based implementation.
A 3rd complaint is the backwards incompatibility, but the API has been around since 4.4 and apps should have been using it to respect user consent. At the very least, they should have been using it as a fallback if the user rejected unrestricted global shared storage access...
1
8
I think it's very telling that even power users are not aware that apps have been abusing permissions by requesting far more than they need. It reminds me of app developers lying to users by claiming they need READ_PHONE_STATE to mute their app's audio when there's a voice call.
1
11
Show replies