New Beacon Permissions in Android 12
There’s a new Android version on the horizon, and with it comes a lot more nagging.
The Android 12 beta includes a new permission called BLUETOOTH_SCAN. Any app that wants to detect bluetooth beacons must ask the user for permission when the app runs. This new permission is in addition to the existing ACCESS_FINE_LOCATION permission and (if an app needs to detect beacons from the background) ACCESS_BACKGROUND_LOCATION, each of which also requires asking the user permission when the app is running.
The new permission appears to be designed to apps that use bluetooth for connectivity to not have to obtain location permission – they can obtain the new BLUETOOTH_SCAN permission instead of ACCESS_FINE_LOCATION, provided they do not infer location from the beacons. They may also need BLUETOOTH_CONNECT and BLUETOOTH_ADVERTISE if they want to connect to the other bluetooth devices or advertise themselves.
But apps needing to detect bluetooth beacons can’t switch to just the BLUETOOTH_SCAN permission because the Android team says it will filter out bluetooth beacons from the scan results if ACCESS_FINE_LOCATION is not also granted. For apps detecting beacons, yet another permission is now required.
Those who care about privacy might see this as a good thing. It’s always good to ask permission. But is it? Always?
Asking permission is generally a good thing, but asking has costs. Nobody wants to be badgered over and over for subtle variations in the same permission. “Mom, can I go outside?” “Mom, can I go in the back yards?” “Mom, can I play ball in the back yard?”
With Android it’s much worse, because the requests are much harder to understand. Who wants to read a paragraph explaining why a simple app feature requires an arcane Android permission? Who wants to read three paragraphs explaining why a single app feature requires three different arcane Android permissions? Installing a new app shouldn’t be like reading a contract from a lawyer.
The problem has been growing for years. Unfortunately, obtaining Android permissions has become such an onerous process that a significant part of an app’s codebase must be devoted to obtaining permissions. Many apps have resorted to an onboarding screen with a grid of all the permissions that must be obtained, color coded by which are required, which are optional, which have been granted, and which has been denied. Even users who want to grant permissions sometimes fail due to accidental screen taps, blocking further prompts. In the worst case, they find it impossible to hunt through Android’s permissions settings to find the missing permission that must be granted, abandoning the app entirely.
App developers who want to avoid this new permission can do so – for now. Apps not targeting Android 12 can continue working under the old permissions structure, even when running on phones running newer Android versions. But there are limits. As of August 2021, the Google Play Store requires all apps to target at least Android 10 for new submissions. Assuming Android bumps this requirement by one version per year, by two years from now all beacon apps will need to ask users for the new BLUETOOTH_SCAN permission.
Here’s a summary of how Android’s permission scheme relating to bluetooth beacons has changed over the years.
Android 4/5 (2014-2015)
- BLUETOOTH (install time)
- BLUETOOTH_ADMIN (install time)
Android 6-9 (2016-2018)
- BLUETOOTH (install time)
- BLUETOOTH_ADMIN (install time)
- ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION (runtime)
Android 10-11 (2019-2020)
- BLUETOOTH (install time)
- BLUETOOTH_ADMIN (install time)
- ACCESS_FINE_LOCATION (runtime)
- ACCESS_BACKGROUND_LOCATION (runtime – with options for one time, while using, always)
Android 12 (2021)
- BLUETOOTH (install time)
- BLUETOOTH_ADMIN (install time)
- BLUETOOTH_SCAN (runtime)
- ACCESS_FINE_LOCATION (runtime)
- ACCESS_BACKGROUND_LOCATION (runtime – with options for one time, while using, always)