> SAF cannot be used, as it is for sharing/exposing our files to other apps
SAF can be used. There are reasons why this wouldn't be a good fit for NextCloud (you can't share your entire internal storage, your download folder, or the root of an SD card, for instance), but I don't think NextCloud's statement makes sense.
The point of their app is to backup an entire folder. Sharing from one app to Nextcloud doesn't provide ongoing access to backup later versions of the file.
"they", in my case it's me. With on my own Nextcloud server, on my own LAN.
It's me that want "access to everything everywhere".
Difficult for me to think that is not about gate keeping from Google.
Users can access almost everything everywhere with file manager apps. On the Play Store, file manager apps are one of the exceptions that are allowed to access all files.
Usually the answer is that it creates more problems for more people than it solves. The work involved to add options to allow full access is substantial and could increase the attack surface.
Features that are expensive but only useful to a small portion of the userbase often don't get prioritized.
Just to make sure: Google software has the same exact permission structure across the board? e.g. No Google product uses the same permissions NextCloud is seeking, and instead, they are using SAF? Especially for things that do what NextCloud is doing here.
I just want to be sure that Google is playing by the same rules they they put out for NextCloud and other app developers.
Open the Drive app, tap the "New" button, and select "Upload". You get a file picker UI. This UI is provided by the Storage Access Framework that Nextcloud says they cannot use.
This is not the same functionality that Nextcloud provides though. This is one time upload of manually selected files, not ongoing passive sync of an entire directory tree.
Ongoing sync is still possible through ACTION_OPEN_DOCUMENT_TREE [0], and using ContentResolver.takePersistableUriPermission [1] to maintain long-lived access to that directory. Enumerating files is slow but that is not a major concern when the use-case is a background sync, and you can drop down to ContentResolver APIs to reduce the number of IPC calls when enumerating.
No, the call is going through ContentProvider, which happens over Binder IPC, which entails context switching and other I/O overhead. Compared to local file operations (java.io and friends) this is massive; compared to anything else your device does, it's not a big deal at all, and it's not CPU-bound.
Google is smart enough to not make things that obvious, but let's not get fooled.. the point is that if API changes would negatively impact Google products financially, they'd not go through. But if they impact a competitor, it's not an issue.
Locked down API means Google can innovate (because they can change the API), but you can't.
In the Play Store, find the Drive app, select "About this app", scroll down to "App permissions", and tap "See more". It does not have the "manage external storage" permission listed, which is the one Nextcloud says they need.
It's a lie in plain sight, because for most Google apps, including this one, a lot of background processing is not done by the app itself but by the Google play services app that is all powerful.
Right but it doesn't do the same thing Nextcloud does. If it did do you think Google would say to the drive team "sorry you can't do that"? Of course not. They'd invent a new permission or just whitelist Google apps (they've done it before).
SAF can be used. There are reasons why this wouldn't be a good fit for NextCloud (you can't share your entire internal storage, your download folder, or the root of an SD card, for instance), but I don't think NextCloud's statement makes sense.