Comment by david_allison
7 months ago
>> Android really needs to just allow direct file access to any file which is under a user selected folder.
> It does.
No it doesn't, `ACTION_OPEN_DOCUMENT_TREE` provides you with a `DocumentFile`, which isn't a `java.io.File`.
From their docs:
> It offers a simplified view of a tree of documents, but it has substantial overhead
https://developer.android.com/reference/androidx/documentfil...
----
Your fork uses `MANAGE_EXTERNAL_STORAGE` which Google Play heavily restricts:
https://github.com/Catfriend1/syncthing-android/blob/main/ap...
This is very likely the reason that your fork no longer wishes to be on the Play Store:
> Planning to close my Google Play Developer Account. Please say hi if you are interested in obtaining the latest gplay release files from me to help in publishing this app.
https://github.com/Catfriend1/syncthing-android?tab=readme-o...
EDIT: The dangerous permission for `MANAGE_EXTERNAL_STORAGE` doesn't appear in the "App Info", which may be what you're seeing.
> No it doesn't, `ACTION_OPEN_DOCUMENT_TREE` provides you with a `DocumentFile`, which isn't a `java.io.File`.
You can call `contentResolver.openFileDescriptor` on a a `content://` Uri from SAF, and get a `ParcelFileDescriptor`, which can be turned into a real unix fd by calling `detach()` on it. Passing this fd into native code just works.
That's not to say that, you know, SAF is actually sane, though. `DocumentFile` lazily IPCs to some StorageProvider process every time you retrieve a property of the file (mtime, size, whatever). There are ways to speed this up by retrieving everything via the lower level `DocumentContract` API, but it definitely feels like it was poorly thought out.
That's still a one file at a time operation, right? Unless there's a way to te7a native Unix reference to the folder itself(In a way that doesn make Google unhappy and block your app), then you still need to do some fairly deep platform compatibility work or use some kind of abstraction layer.