I’ve read through #29 and most of the links in there. From what I gather, syncthing shouldn’t work with an SD card. But I started up an Android R AVD emulator with an SD card, and syncthing seems to be writing to the SD card ok. I set it up as a separate storage device, not combined with internal memory. I can see the files from both the Amaze File Manager and Files by Google apps.
I didn’t compile for my tests; just installed ST from the Play store. So I’m pretty certain it’s targeting a lower SDK.
FWIW, I also used Amaze File Explorer to test SD writability on APIs 27,28, and 29. None of them allow writing. I’m pretty sure Amaze does not use SAF. It pops up a UI to attempt to instruct the user on granting permissions, but the instructions seem out of date and didn’t work for me.
Es Explorer did automatically prompt for allowing access, and was writable, so I’m guessing it supports SAF.
@imsodin how do developers feel generally about “All files access”. It initially looked like a decent solution to me, but I’m pretty concerned about the play store whitelisting, and requirement for the user to be navigated to system settings (will that work across vendors?). I’m not an Android developer. Do they typical enforce things like that just by keeping it off the Play store, or can they refuse to sign it alltogether preventing side-loading?
It does, and that means you are most likely seeing a emulator deficiency, not a real change as suggested by Audrius above.
Not an Android dev either - I just do “release management” of syncthing-android. From how I understand it there will be an intent (or whatever that thing is called) that the app can send and then the user is sent to the right location in the system settings. Most likely vendors will be able to break that, but that’s nothing new. As to playstore whitelisting: Afaik they can only restrict what goes into the playstore, but given the tight integration of that into android and inability of most users to use alternative ways to install apps, that’s pretty authoritative already (personally I wouldn’t mind a shift to F-Droid and the like, but I am too realistic to hope for that).
Man, things are still looking pretty dire. They’re explicitly trying to prevent the use of SAF for broad filesystem access, and sounds like it won’t be easy at all to get approval for All files access: https://youtu.be/UnJ3amzJM94?t=1193
The linked video starts out with SAF, which is explicitly not what the new all file access/manage external storage (did they rename it?) permission is about: Accessing files natively, not through SAF: https://developer.android.com/preview/privacy/storage#all-files-access
I am not going to watch a more than half-year old video for it to maybe give some tangible information, if there is any, please enlighten me about it (and ideally link a text source) - thanks.
The video link should start at 19:50, and you only need to watch for about 3 minutes to see everything I’m talking about.
What gives you the impression that the intent of “All access files” is for native apps? It explicitly says in the section you linked that the intent is to provide exceptions for apps that do things like backup or file management.
EDIT: They address file path access for native apps earlier in the video: https://youtu.be/UnJ3amzJM94?t=876. It’s rather ambiguous, but seems like they’re saying it may only work for files provided through the MediaStore API, with all the limitations that go along with it, including non-media files must be put in the Downloads directory, and accessing non-media files created by other apps requires SAF. In any case they don’t mention “All files access” at all in that context.
[quote=“anderspitman, post:10, topic:14983”]
What gives you the impression that the intent of “All access files” is for native apps? […]
Native probably isn’t a good choice of words: What I mean is code/libraries using direct filesystem interaction, not the Android apis. From said link (“raw file paths” being the most relevant bit):
Apps can access these files using either the MediaStore API or raw file paths. If your app uses the Storage Access Framework, you cannot use it to access the additional files and directories that the all files access permission makes available.
Well, file management is what Syncthing does, right?
That was interesting indeed, especially I didn’t yet get that file path access will be translated to android apis internally - that’s likely going to be fun