[moonshot5]

AOSP platform dev here. (Filesystem) Opinions my own, I don't speak for Google.

Disclaimer: I don't use nextcloud, and have not looked at their app specifically, this is just a surface level observation from my relatively informed perspective.

My take: SAF would work for this use case, as others have already mentioned.

Google Drive does not have the permissions that next cloud claims Google is giving preferential treatment to, and is delivered via the Play store in the same way nextcloud's app is.

As others have also observed, permissions such as MANAGE_EXTERNAL_STORAGE have been rampantly abused in the past, often in horrific ways.

[noname120]

SAF is not an option because it is HORRIBLY slow[1][2][3][4][5], which makes it an absolute no-go for any decent cloud synchronization app.

Excerpt from [1]:

> SAF is slow. Every SAF file IO operation takes like 20-30ms because it uses an IPC call. And sometimes you may want to check whether a lot of files exist on the disk and if they do not then create them (or something similar that requires a lot of file operations). It's so slow that even in google example they use hacks to make it faster.

Excerpt from [3]:

> Just to add a new sample for the performance of SAF vs standard File operations:

> […]

> 15 seconds with SAF, 6 milliseconds with native ls ! And there's only 128 files LOL

————————

[1] https://github.com/K1rakishou/Fuck-Storage-Access-Framework#...

[2] https://www.reddit.com/r/androiddev/comments/ga5u72/saf_is_s...

[3] https://issuetracker.google.com/issues/73044953#comment5

[4] https://magicbox.imejl.sk/forums/topic/storage-access-framew...

[5] https://issuetracker.google.com/issues/130261278#comment52

[probably_wrong]

Wow the resolution to your link [3] is infuriating:

> We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue (...)

It's all possible excuses all at once: "Thank you for your issue, we are working on it. Also we have no intention to work on it and we are closing it, the problem probably doesn't exist anymore anyways, and if you think it does make sure to open a new issue for us to treat it with the same amount of respect".

[spookie]

Reminds me of some bug reports I was looking at for Chromium regarding SVG rendering the other day.

Some of them are almost a decade old and require constant bumps to keep them alive, or filling new issues. Somehow their bot system considers anything more than a year old "probably patched". Their messages read much the same way as that.

[urbandw311er]

Good catch - that’s horrendous and feels like absolute fobbing off with “type a bunch of cliches”

[pigeons]

Yeah google issues are great.

https://issuetracker.google.com/u/1/issues/80379228

[tadfisher]

This may be true, may have workarounds, and may be solved on later Android versions, but it also is not why Nextcloud says they are avoiding the framework. And Google Drive provides the same functionality using SAF, so I'm not sure it's a problem for this use case.

[noname120]

There are no good workarounds unfortunately and it's definitely not solved on later Android versions. I agree though that the reason that Nextcloud gives is factually incorrect (they say that SAF is for providing files rather than accessing them, which is plain wrong).

[tadfisher]

From what I understand, you can resolve most issues by making ContentResolver queries yourself once you have URI permissions for a folder, including data like filename, mime type and file size in the query projection. This reduces an NxM number of queries to N, where N is the number of nested directories in the tree and M is the number of files in the directory.

Obviously this should be solved with a better API at the SAF layer.

[izacus]

You're linking articles that are 3-6 years old and the performance has significantly improved since then.

[noname120]

Not true. I had first-hand experience a few months ago and the performance is still abysmal.

[coded_monkey]

> As others have also observed, permissions such as MANAGE_EXTERNAL_STORAGE have been rampantly abused in the past, often in horrific ways.

The lack of consideration for this point in this thread scares me. The amount of data that can be taken from a device through a permission like this is likely huge and it’s not just about “protecting users from themselves”. I wouldn’t feel safe enabling it for any app, and while syncing all data on the device sounds very useful, it’s a damned if they do, damned if they don’t scenario for Google.

[greatgib]

So scary that I don't know how billions of people in the world manage to have the right to use whatever software they want to access "all" the files in the file system of their computers (PC/mac) and that the civilisations have still not yet collapsed...

[apitman]

Then give me a big fat warning then let me choose.

[mvdtnz]

Google simply needs to add "I'm an adult" functionality to their phones. I know the author of this app and trust them, I know the functionality I want and I accept the risk because I'm a grown adult and can make my own choices.

[izacus]

The next API Nextcloud is asked to use it literally that - it asks you, as the user, what files you want Nextcloud to read.

[nolist_policy]

But why? Just for the odd app that can't be bothered to use the new API?

Even if you trust the app, if there is a vulnerability in there, the Android sandbox provides an additional line of defense. Most apps don't have defenses of their own, the only apps that self-sandbox are web browsers.

[zb3]

> I wouldn’t feel safe enabling it for any app

Then don't enable it, no need to take away my ability to do so. Granular permissions are good (especially when the app can't reliably know they were refused), providing I have the ultimate control.

> it’s a damned if they do, damned if they don’t scenario for Google.

Did they consider my scenario above - where the app doesn't know it was not granted a permission?

[IshKebab]

> especially when the app can't reliably know they were refused

That's the problem. Android didn't do this even though it was obviously what is needed. Android apps can easily tell what permissions they have.

I think Google prioritised UX over power and security here. They were presumably scared about people accidentally clicking the "Silently deny" button and then getting confused when the app didn't work. Big missed opportunity.

[nolist_policy]

But the new API allows exactly this, the user can just give the app an empty directory. And Google even pushes apps to use it.

[tgsovlerkhgsel]

> often in horrific ways

Let me guess, loan shark apps, or is there something even worse that I wasn't aware of?

(Essentially ransomware that people "voluntarily" install in order to get a predatory loan, often without knowing how it actually operates. If they fail to pay, not only is their phone locked, but the data from it is used to threaten/extort them, from threatening to send their nudes to their contacts to death threats to relatives identified from the data - https://www.welivesecurity.com/en/eset-research/beware-preda...)

[izacus]

Pretty much every game and every social media app asked for full storage access under the guise of "downloading game files" or "allowing our photo picker to work".

Then they got free access to all your photos and their location data and all your documents and downloads. Yes, including those banking statements downloaded as PDFs. Forever. In background. Whenever.

That's the access Nextcloud demands instead of using the API where YOU choose what it can read.

[spookie]

Hell, you don't need to go that far.

Some apps suspiciously send data they have no business in about your phone, like Outlook. It's crazy.

[robotnikman]

Wow, that sounds dystopic as hell...

[dxuh]

> As others have also observed, permissions such as MANAGE_EXTERNAL_STORAGE have been rampantly abused in the past, often in horrific ways.

I understand that great care should be taken when this permission is granted to new apps, but NextCloud is well known and on top of that it is a file management app. If anything, apps like that should have this permission.

If you plan to phase it out completely, then the alternatives have to be good enough, which judging from some of the child comments, they are not. I have never developed for Android (and likely never will, because of stuff like this), so I cannot judge properly.

It's also my understanding that the Google Drive App is just some UI over cloud storage. All the interesting bits like Backup are not handled through it and Google Drive gets preferential treatment for this. Additional permissions are required to emulate such functionality.

[apitman]

> Google Drive does not have the permissions that next cloud claims Google is giving preferential treatment to

Drive specifically may not, but the system as a whole, which is controlled by Google, certainly does[0].

[0]: https://support.google.com/googleone/answer/9149304?hl=en&co...

[apitman]

SAF is a terrible solution for anyone trying to make a cross-platform app (and if you're not then why are you targeting Android as your one platform?), because it doesn't work with native code.

[pjmlp]

JNI exists, and poor fellows having to write a bit of Kotlin or Java.

[apitman]

The problem isn't the language, it's that the API completely changes the paradigm of how you access the filesystem.

[codethief]

Totally unrelated question but since we're talking filesystems on Android here, I have been incredibly annoyed that AOSP devs disabled "special" characters ":<>?|* in file names in Android 11[0], probably to achieve compatibility with NTFS/FAT. Unfortunately, not only does this make some (especially older) applications accidentally crash when I want to use, say, a question mark in a file name, I can also no longer sync all my files from my Linux machine to my phone.

Now, there is probably little chance for this to get rolled back entirely. But maybe one could make it an option in the developer settings to allow ext4 filenames like before? Do you see any chance your team could be convinced of such a move? And where would be the appropriate place for me to raise this issue and/or contribute a patch?

[0]: https://github.com/GrapheneOS/os-issue-tracker/issues/952