File access restrictions in Android 10/11

[mvglasow]

Android 10 introduced new restrictions on file access by apps (with an opt-out for existing apps, which was discontinued in 11). These are designed to prevent apps from accessing each other’s files, and reduce filesystem access to shared storage.

This becomes an issue when sharing a cell/wifi database between Radiobeacon and the location provider backend (as I do, so whenever I scan new wifis, I can immediately use them for georeferencing).

Rules for file access are as follows:

• Apps can still access their private and external private (/sdcard/Android/data/com.example.package/files) storage using filesystem paths. Caveat: /sdcard may have several aliases in the file system, but not all of them are created equal – some work, others don’t (which I had to learn from painful experience, as Google didn’t bother documenting that). To be safe, never hard-code this path but obtain it from the API.
• android.permission.WRITE_EXTERNAL_STORAGE no longer grants access to the whole filesystem, only to media files (music and pictures).
• Other file access must use the storage framework. IIRC this also means apps cannot access any of these files without user interaction.
• File manager apps can request a new permission, android.permission.MANAGE_EXTERNAL_STORAGE, which will restore full access to /sdcard (not sure about other apps in /sdcard/Android/data: they might still not be accessible), as was the case prior to Android 10. However, this feature is intended for apps with a valid use case (file managers etc.) – not an issue for apps which are not intended to hit the play store, but Google will reject apps from the play store if they request this permission without a use case that is satisfactory to Google.

On the other hand, sharing an SQLite database file between two processes has never been a good idea (afaik simultaneous access isn’t even supported), so this would be the time to sort this out. The Android way would be to use a content provider. If the backend is a SQLite database, this is fairly straightforward. The architecture then would be:

• The location provider backend would manage the file (in its own storage area) and expose a content provider. For simple lookup operations, everything works as before; the only addition is that there is a content provider for other apps to interact with the database.
• Radiobeacon would get an option to use the content provider instead of a file for the database. Operations would be the same as before (it could display wifis on the map, check if a newly scanned wifi is already in the DB, or sync the DB with newly scanned wifis). Internally, we’d have to see how much code can be reused – the content provider API is similar to the SQLite one. If Radiobeacon uses raw SQL somewhere, that might need reworking.
• In order to protect the DB from being accessed by any application, the location provider backend could implement a custom permission for access to the DB and enforce this; Radiobeacon would then request that permission. (We’d have to see if that is possible if Radiobeacon is installed on a device which does not have the UnifiedNLP backend.)

Those who use Radiobeacon and the location provider backend would then have the location provider backend manage the DB, and Radiobeacon would rely on the location provider backend for any DB operations. Those who use just one or the other could continue to do so, with no changes.