However, when implementing features downstream, they have to be implemented in a way that retains app compatibility. I'm not in a position to force apps to make substantial changes like using a foreground service or totally moving to the Storage Access Framework for user consent.
Conversation
Replying to
As it exists right now, Android Q almost completely removes old style shared storage access from apps. The user can still fully access it all via the system file manager, but other apps cannot. They need to be given access to files/directories case by case via user consent (SAF).
1
Replying to
Old style access will only provide access to a private directory. The difference from the internal app storage is that the user can access it via a file manager. It will no longer be possible for apps to access the dedicated external storage of another app, just like internal.
1
Replying to
I had planned to make an isolated shared storage feature, but it was going to be optional via a toggle and it would have needed to create a directory tree with a sub-directory for each app emulating the top level shared storage, with that forced as their top level by default.
1
Replying to
Essentially, it would have been a lot messier, and I was going to have a toggle to preserve the ability to avoid this messier way of handling it where the user would have had to do more work moving around files with the file manager. Forcing apps to use SAF is a far better way.
1
Replying to
SAF lets them access anything like before, but the user has to grant access on a case-by-case basis. When the user wants to load or store a file, they press the button in the app, and it can use SAF which opens the system file manager UI, allowing them to choose anything.
1
Replying to
The app cannot load or store arbitrary data to shared storage though. It can only access what the user has granted to it, including directories. It's a far better way of doing things. Most apps should have been using SAF, like my PDF Viewer (no storage permissions needed).
1
Replying to
However, app devs are always going to take the path of least resistance, which is demanding bulk access permissions from the user and doing whatever they want without explicit user consent forever, since users aren't in a position to deny it, when app devs made no alternative.
1
Replying to
Permission toggles are not a model that works well. The app coerces users into granting permissions by not providing alternatives. Apps have been able to store / load files, take pictures, pick contacts, etc. without permissions for years but they rarely ever take that approach.
1
Replying to
Since they don't want to present the user with a system UI to pick a contact. They want direct bulk access via the Contacts permission and their own UI. Ideally, they'd provide the alternative way of doing it when the user rejects the permission, but right now no one does that.
1
Replying to
For example, many apps want the Camera permission so they can implement real-time display of filters, etc. and they can show it below the chat rather than having it take up the full screen. However, when the user rejects the permission they could still use the standard camera UI.
Replying to
Do they? No, they'll spam the request for the permission when you try to do it, or even worse they'll demand it upon opening the app and will refuse to have it work at all without it. They are supposed to implement alternatives, but they don't. The future is removing permissions.
1
Replying to
Even if only most popular apps acted decently, users would be in a position to handle this better, but it's not what happens. The model doesn't work, and instead the OS will need to keep removing access with the only way of doing things being asking for user consent each time.
1
Show replies