WIP: Adapt to API 30

[mvglasow]

Work in progress, do not merge until this notice is removed

This adapts the location provider to work with API 30:

• Request background location access when running on API 29+ (Android 10+)
• Request READ_PHONE_STATE (required for getNetworkType(), else a security exception will be thrown)
• Request full file access on API 29/30+ (currently needs to be granted manually in system preferences, interactive permission request not yet implemented)
• TBD: Deal with WiFi scan limits for background services

[mvglasow]

Currently I am wondering whether (and when) we should request filesystem permissions.

Should we request permissions when the user sets a database folder?

Pros: Familiar workflow; if users cannot see their database file in a shared folder, they know why.

Cons: Might confuse users who do not need to use a database in a shared folder. If users remove the permission in System settings, offline lookups will silently fail or even lead to crashes, unless we also check and request the permission on each lookup as well as prior to database selection if the database is not in private shared storage.

Should we never request the permission at all, and have the user grant it manually in System settings to use a database in a shared location?

That would make this setting a kind of a developer setting. Of course, we would need to check for the permission before each access, and silently fail with a log message if it’s not granted. We might also want to ensure we start browsing for the database folder in a location the app can reach with the permissions it currently holds (i.e. reset the selection to the default if the currently set folder is unreachable).

Pros: Easy to implement, and users are unlikely to grant this permission without actually needing it.

Cons: Users would need to know where to reach in order to continue using databases on shared storage.

I’m currently leaning towards the second option.