I’m currently playing with Google’s new feature “all files access”. Going through Android settings and searching for “special app access”, then tapping on “all files access” and granting my test build this permission unfortunately does not allow SyncthingNative to write any single file to storage. Screenshots can be found in the references github issue.
I’ve also enabled STTRACE=fs model and was surprised SyncthingNative did not report anything like “failed to write file blabla, path is read-only”. It just shows 0/0 files synced and out of sync + revert. If I revert, the sendOnly side (PC) does show the override changes button. If I hit it on PC, the Android shows the revert button and so on.
I’m opening this topic to help preparing the compatibility with Android 11 enforced Scoped Storage feature and maintain file-write access by something still required to figure out.
If anyone reads this and has useful input or information to help me, please post. We still have a lot of time until Android 11 will hit - and hopefully - Google will make the all “files access” better during next betas.
Wow, thanks a lot for that link. This is a 180deg turn on google side, lets hope it stays that way (I even think this would include external SD storage o.O):
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.
Not sure if this is of any help, but I found this information in the article “Small steps and a big leap - First pre-release of Android 11 and new features for pixel phones released” on page 42 of issue 07/2020 of the German computer magazine c’t:
“The Scoped Storage introduced with Android 10 has been improved in terms of security and privacy. The sandbox principle of the internal memory is extended to the shared memory or SD card: apps can no longer access any data there either. The API innovations suggest that for extended access, an app must first request the necessary authorization from the user.”
We know that, that’s the problem making Syncthing on android much less useful. However the above (Android 11 "All files access" for the Syncthing App) sounds like android 11 will bring a new special permission to access files outside of scope storage directly, which would be a life-safer.
it’s not wrong, it’s exactly what the description says: via SAF, i.e. what the app is using scoped storage always applies, but the new permission allows native access to the filesystem.
and a general question (because i am too lazy to research before tapping into your knowledge, so rtfm is a valid response ):
how do Android version with with respect to what version an app targets save want version the phone it’s running on actually is? afaik when targeting a lower version than the phone runs it behaves as if it was that lower version. what happens the other way around? i guess a lower version phone doesn’t just get access to new policies (because how would it know how to handle that without an update). then again we target 9 on purpose to not get the storage restrictions added in 10, which contradicts that sentiment. is there a simple explanation or pointer to relevant docs?
Lets hope the google play restrictions on using that permission wont be unreasonable, however at least for f-droid users access to sd card etc will be a thing with android 11 if someone can integrate it into the app.
It’s consistent with the documentation, I don’t see much reason to doubt that it does work at this point. What looked awful, when I last looked for approaches to solve it, is how to use the new permission while keeping backwards compatibility respectively keep opting out of scoped storage on 9 and 10. Basically I think the question isn’t whether access to a lot of files, including on external storage, will be theoretically possible on 11, but if there will be a solution making use of that (aka someone taking the time to pick it up).
In the end I agree though to the comment on the github issue: Unless there’s a solution in the works, I wouldn’t go raising expectations - it too often happens that users don’t get the difference between “it’s possible” and “it’s done”, and dealing with that isn’t particularly pleasant.