←back to thread

The recently lost file upload feature in the Nextcloud app for Android

(nextcloud.com)
410 points morsch | 4 comments | 14 May 25 05:38 UTC | HN request time: 0.576s | source
Show context
moonshot5 ◴[14 May 25 16:07 UTC] No.43986181[source]▶
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.

replies(7): >>43986712 #>>43987576 #>>43987745 #>>43989733 #>>43990209 #>>43991397 #>>43992185 #
noname120 ◴[14 May 25 18:32 UTC] No.43987745[source]▶
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

replies(3): >>43987999 #>>43988073 #>>43989372 #
1. probably_wrong ◴[14 May 25 19:01 UTC] No.43988073[source]▶
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".

replies(3): >>43988770 #>>43988880 #>>43990809 #
2. urbandw311er ◴[14 May 25 20:21 UTC] No.43988770[source]▶
Good catch - that’s horrendous and feels like absolute fobbing off with “type a bunch of cliches”
3. spookie ◴[14 May 25 20:35 UTC] No.43988880[source]▶
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.

4. pigeons ◴[15 May 25 01:04 UTC] No.43990809[source]▶
Yeah google issues are great.

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