Hacker News Reader

Comment by deng | Hacker News Reader

I think TFA is wrong.

It is correct that you cannot access private app folders, meaning stuff like /data/data, /Android/data, /Android/obb. But this is nothing new and you basically need a rooted device to access them. You can however access anything on external storage, which is typically where apps would store data you would want to sync and which would cover by far most use cases from users. At the moment, users are mostly complaining that only media files are synced, but not documents. SAF would solve this.

> I'm sure they would happily allow you to select the folders you want to give permissions to, but I think that's not possible anymore.

That is absolutely possible:

https://developer.android.com/training/data-storage/shared/d...

View on HN

Well, it used to be possible before Android 11, that's the thing.

So, following a bit the example I was giving, if you want to sync data from another app to backup it (or whatever), and that App stores its data in the default data folder assigned by Android, since Android 11 it's going to be very difficult to do it.

I used to sync some of those folders with Syncthing in Android, and since Android 11 things have gotten complicated (meaning, you need 'all files' access, and even then, some things might not be accessible). [0]

  0: https://forum.syncthing.net/t/android-11-and-syncthing-what-can-be-synchronised/17100/2

Hello, we and TFA are talking about the new API where the user picks what directory an app has access to vs. the old API where the app has access to almost everything as you pointed out.

The Google Play store (not Android the OS) is now limiting access to the old API, it has nothing to do with Android 11.

The new API does not work with Linux open(). Some projects (like Syncthing) don't want to put in the work to switch to the new API.

I hope that clears things up.

Yeah, I'm not saying that you're in the wrong, I'm saying that they might want to access further than the new `ACTION_OPEN_DOCUMENT_TREE` API call allows. For example, the Downloads folder (you can only open individual files with ACTION_OPEN_DOCUMENT, not the whole folder). And that can be reached with the `MANAGE_EXTERNAL_STORAGE` (all files) API. Is that OK? Well, it's not intrinsically bad, but it clashes with Google's Android hardening directives.

Not very familiar with the NextCloud client, as I haven't used it much, but in the case of Syncthing (and this is totally guessing from what I remember from reading the forums back when the Android 11 upgrade happened): I don't think they don't want to put the work to switch to the new API, I think they want to access places they won't be able to access with the new API, so that's why they won't change the calls.

It's doesn't work with native code.

Yes, you'll need a little bridge to get a ParcelFileDescriptor. Lots of stuff in Android does not work directly with native code (Permissions, Camera/Media recording, HttpURLConnection, sensors/location services, ...), and storage access is now sandboxed in a similar way and needs a few lines of Java/Kotlin. I fully see that this is annoying, and Android is tiring developers with constant changes like these, but on the other hand, I guess most people would agree that securing storage access is a good thing.

It would not be much effort at all for google to make native hooks into these APIs. Certainly less effort than dealing with constant complaints from developers. It feels like they're trying to force lock-in.

With file access, the sensible solution would have been of course to just overlay the permissions onto the regular files API (like I think every other sandboxing solution does), so everything that uses files could keep working as usual and you'd just have to add some limited code to request the appropriate permissions [1], but I guess that would have been too sensible, and when all you've got is a SAF, everything looks like a nail or something…

From what I've gathered, getting access to a single user-picked file via SAF isn't too painful, but for browsing a whole directory tree it's more annoying having to use a completely new API for that, doubly so when you're using a library that expects regular files, plus performance is somewhat lacking, too (judging from complaints and bug reports I've seen, both in that it is easy to run into performance pitfalls, but also that even best-case performance is still worse than classic file access).

[1] I think something like that was actually implemented for Android 11 onwards, judging from https://source.android.com/docs/core/storage/scoped#using-sc...? Although possibly still at some noticeable performance cost.

> From what I've gathered, getting access to a single user-picked file via SAF isn't too painful, but for browsing a whole directory tree it's more annoying having to use a completely new API for that

That pretty much matches my experience. Single file picker flows can often be implemented with a simple callback.

But for folders it falls apart.

Thanks for mentioning scoped storage. Maybe that provides some sort of solution. I vaguely remember when I was first dealing with this circa 2021 that they had some sort of a low-performance solution that was supposed to work for NDK code.

Reply on news.ycombinator.com