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.
1 Like
Did you do any more testing with this?
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?
To answer it from my experience:
It’s the Android framework which reads the targetSdk and then decides which policies apply. Bumping targetSdk from 9 to 10 you’re right. I expect it to apply scoped storage restrictions and making the app unusable. We would then need to opt out of scoped storage to make it work again.
My problem where I last stopped researching is how I could build the app with Android <=9 + 11 and also 10 support. From trying it out I expect <=9 + 11 to behave okay with the existing code and manifest with the plus that 11 gets all files access. Android 10 is a problem I didn’t resolve yet because I need to opt out of scoped storage. See my table:
- Android <= 9: requires EXTERNAL_WRITE_PERMISSION + SAF, behave neutral to scoped storage opt/in or opt/out.
- Android 10: We need to opt out of scoped storage (which could be punished by GPlay Store but currently isn’t) and use SAF.
- Android 11: We need to opt in scoped storage and on top request all files access (see link above on scoped storage and all files access, it’s also mentioned there). ToDo as I expect it is reworking the SAF code in the app where incompatible with the scopes. Then find a way how this still works on Android 10 where all files access doesn’t exist. I somehow fear we’d have to build two apps with just one difference in the manifest which I hope doesn’t come true. That’s why I stopped my first draft of the Android 11 app waiting for the final beta to come up and then retrying things with hands on.
I’m not expecting too much from reading the docs because Google often “last minute” changes API’s to behave and their restrictions before the final version appears in the release channel. It was e.g. the case when I early adopted the “Access location everytime” API in the fork, tested and then it didn’t work in the Android 10 final and still had to be reworked. I’ll post documentation links when I’m working on this next time and find something useful. You’ll also find useful code and manifest info on my fork draft PR. When I feel like being ready for Android 11, I’ll likely file a “minimal” PR upstream to help the app, so no worries.
4 Likes
With the release of beta 1 the api freeze has happened and it still looks good: https://developer.android.com/preview/privacy/storage#all-files-access
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.
1 Like
@imsodin Yippie! I’ve tried the beta 1 on an emulator and can sync to SDcard 
And I cannot select the SDCARD root folder for syncing at all. (Need to try later if it works without the SAF dialog.)
First glance with manually adding the folder through the web UI at /storage/emulated/0 —> it works to write.
1 Like
Again, emulator != real device in my experience.
I know, but sorry, I don’t have a real Android 11 “R” device yet. 
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.
2 Likes
I’m looking forward to test this on my phone. Let’s see when it receives Android 11…
Do you have Android 11 beta already? I have an apk…
No. But it would indeed be useful to have an APK for testing at some point.
@Martchus In case you neee it, the test APK can be found here: https://github.com/Catfriend1/syncthing-android/releases/tag/v1.7.0.1
Some more work is needed to get this compliant. Contacted Google and they said it may not be published on play at that time but maybe later.
How does it work? Meaning compatibility with pre 11?
@imsodin I’m already using this build on 9 and 10 phones as well.
P.s. from today: https://support.google.com/googleplay/android-developer/answer/9956427
My question was still about that:
To my understanding when you switch to 11/level30 you need to drop the legacystorage flag and request a permissions that exists at 11/level30 only to access any files outside of the apps private data dir. At first I thought to request a new permission, you need to drop support for <=10 - apparently that’s not the case (I don’t understand yet how it works though, as <= don’t know about that flag - do google play frameworks add a shim between the OS and a new app there?). And even then, you need to opt into scoped storage, which to my understanding will allow the app to access everything on 11, but restrict it to the private dir on <=10. To get around parts of that I read about using abstract classes to effectively run different code on different android versions (that’s the part where it gets ugly).
Now it looks I am pretty much mistaken about how this works and it isn’t actually a problem at all!? That’s nice, I just still don’t get how xD
And now the timeline is clear:
Warning
Your app currently targets API level 28 and must target at least API level29 to ensure that it is built on the latest APIs optimised for security and performance.
From August 2020, new apps must target at least Android 10 (API level 29).
From November 2020, app updates must target Android 10 (API level 29).
Where do you stand with Android 11/API lvl 30? Do you already target it? If so, could you please point me at the relevant commits so I can try to educate myself on how it’s supposed to work (one might notice from my last point that I do not (yet) get how android api lvl backwards compatibilty works).
@imsodin The fork already has Android 11 compatibility, using sdk 30.0.1 build tools and targeting api 30 level. The main change was in the AppManifest.xml (added all files access permission and legacyStorage = true). Then the intro dialogs were extended to prompt for all files access on 11+. I recall looking at AppManifest and FirstStartActivity did solve it so the SyncthingNative has access to the files as before plus sd card support on 11+ only.
Ref.: https://github.com/Catfriend1/syncthing-android/commit/545a9ffb1dd419d662ebc280eb05bd9352a56a56
1 Like
Thanks for the pointer. I think I am beginning to understand how it works. And googles wording in the docs is just terrible:
[…] After you update your app to target Android 11, the system ignores the
requestLegacyExternalStorageflag.Maintain compatibility with Android 10
If your app opts out of scoped storage when running on Android 10 devices, it’s recommended that you continue to set
requestLegacyExternalStoragetotruein your app’s manifest file. That way, your app can continue to behave as expected on devices that run Android 10.
The former sounds like no matter what you do, as soon as you target lvl 30, requestLegacyExternalStorage becomes ignored (on all android versions). What you say and the second paragraph implies, is that this is incorrect and the system only ignores this flag if you both target 30 and the device is on Android 11, it still applies on <=29 (which is good 
).
1 Like
I have been an avid user of Syncthing/Syncthing-fork for a bit now. Though ever since my Samsung phone started pestering me about updating to Android 11 I have been reading up on potential issues, particularly those related a few of my favorite apps. I kept delaying the update and always made sure to deselect the Auto Install check box.
Well, I wasnt looking at my phone this last time when it rebooted and although I have repeatedly told it NOT to auto install the update, the genius developers of Samsung’s updater app apparently have made the default behavior to auto apply updates if you don’t catch the Install System update prompt message (irrespective of whether you have previously indicated your desire NOT to auto install when setting a delayed install time)…
Now I’m stuck with Android 11 and Syncthing(-fork) will not run as I am unable to enable ‘Allow access to all files’. However, if I go to Permission Manager → Storage I see that at the top there is a section titled ‘Allowed to Manage All Files’. There are apps such as Firefox, AnkiDroid, and Ring that are in this first section that have full access. So why is Syncthing forced into the “Allowed Access to Media Only” section (farther down the Storage permissions page)? Even an old legacy app - Virtual Recorder Donate - that has not had updates since 2018 has All files access enabled.
So now that I’ve updated to android 11 attempting to run Syncthing for first time after first reboot directs me to grant access but on that permission screen the enable button for “Allow access to all files” is disabled and unselectable. So I am prevented from moving forward and forced to close the Syncthing initialization screen…
ST is listed under access all for me.
Have you investigated resetting its permissions?