Conversation

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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

Replying to

and

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.

1

8

Replying to

and

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

8:56 PM · Jun 3, 2019Twitter Web Client

Replying to

and

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

Replying to

and

When really the reality is that they want the IMEI (no longer available via READ_PHONE_STATE in Android Q) or other personal information. The only alternative is that they're totally incompetent and don't realize there's AudioManager and an audio focus system. Hard to believe.

11