Bump android api level to 30

[imsodin]

I want to collect all requirements to release with android api level 30. I half ignored half forgot that the google play deadline to do the switch is November, i.e. next week. The scary change is the scoped storage one. Which is partially good (SD card support #29), partially bad (performance) and also scary (some reports in the fork app that did the switch of disappearing data).

1. Investigate if accessing now restricted paths (e.g. Android/data and Android/obb) generates an error such that !os.IsNotExist(err). If not, add some smartness or at least pause folders and make them receive-only together with a wizzard to make users aware, to make sure that previously scanned files do not get detected as deleted on scan.
   https://developer.android.com/training/data-storage/manage-all-files
   https://developer.android.com/training/data-storage
   Catfriend1/syncthing-android@d0af150
   https://forum.syncthing.net/t/android-11-all-files-access-for-the-syncthing-app/14651
   Android 11: SDcard rw support using all files access Catfriend1/syncthing-android#568
   https://github.com/Catfriend1/syncthing-android/pull/618/files

2. Add wizzard page to request all file access (respectively adapt existing one).

3. Investigate and fix networking restriction issues.
   Fix local announcements on android 11 #1663
   Android API level 30 breaks interface address discovery #1628
   Acquire MulticastLock for local discovery to work on Android 11 (fixes #735) Catfriend1/syncthing-android#800
   Probably more a curiosity due to lack of time: A go app running on android, which had some of this problems, and uses java bindings to fix them: android: move to targetSdkVersion 30 tailscale/tailscale#2293

4. Get all file access approved in google play
   https://developer.android.com/training/data-storage/manage-all-files#all-files-access-google-play

5. Find out if there's more things that need fixing - @Catfriend1 ? :)

While I want to keep publishing syncthing-android, I cannot guarantee anything here due to time constraints (I can guarantee I won't be able to do it any time close to the deadline :) ).

Please if you like syncthing-android and have a bit of time to spare, help out. I am very happy to collaborate and guide!

[tomasz1986]

I can try to help if we yet again need to write some legalese regarding all file access in the privacy policy. Others would have to join in when it comes to the other points though 😔.

[Catfriend1]

@imsodin Your list of todo's looks fine to me. I think somewhere there was a problem with the wifi ssid filter feature. After raising the api level it won't get ssid info in the background and I remember lint warnings which lead me to change the code. This can only be work around by acquiring the location "always in background" permission by filling the gplay form or omitting the feature.

[imsodin]

Thanks for looking over it. We already have the location in background permission now.

[imsodin]

I did some manual testing to see how it behaves on upgrade on my android 10 and 11 device. And indeed files in Android/data are hidden, i.e. get deleted on 10. On 11 it couldn't access Android/data even before the target bump, so it seems to be a non-issue there.

I was toying with the idea of adding ignores for the affected, hidden paths. However it's not entirely clear which paths are affected apart from Android/data (and is e.g. Android/data/com.nutomic.syncthingandroid accessible?). I don't want to go down that route, catching some and missing other scenarios in the process.

My proposition is to add a wizard page on upgrade with explanations, and either:

1. Do nothing in the app, tell users that any existing data in Android/data will get marked as deleted (kept locally, deleted on remotes).
2. Reset the database for android < 11: Explain why on the page, and make the user click a button to reset the db and proceed.
   I'd tend to 2: Sure, hashing everything again is annoying, but it makes sure the db representation conforms to what android presents and no files get deleted (there will be access denied or smilar errors, which is good).

@AudriusButkevicius @calmh What are your thoughts on this?

[calmh]

Deleting would be ungood. Being explicit with a warning/notice and reset seems better.

[AudriusButkevicius]

I'd just yank all the folders and ask users to set it up from scratch?

[locuturus]

I believe only Android/data and Android/obb are restricted. Other sub folders are available i.e. Android/media or user created folders.

There is a way to use the SAF file picker to grant access to Android/data & obb but I don't know the method. The cloud sync app FolderSync is using this to access these restricted directories:

But this might be unsanctioned and could stop working later for all I know.

[imsodin]

The PR taking care of filesystem business is ready to review: #1724

[imsodin]

3. Isn't an issue, respectively not related to the multicast lock. There are new restrictions in android 11 which prevent sending casts, but the multicast lock doesn't change anything about it and receiving still works.

This issue is thus done. I'll do a regular release with the next Syncthing release.