Android App Permissions: What’s new with user privacy and location in Android 10?
Google released the latest major update to Android on September 3, ditching the alphabetical desserts and naming this version Android 10. While losing the sweet tooth appeal, Android 10 has provided a lovely assortment of goodies, such as dark theme, gesture navigation and, most significantly for a geofencing solution like ours, granting the user greater visibility and control over their data, especially location data with new app permissions.
These changes are very positive and in line with the continuing industry trend toward user privacy and data control for online services. Bluedot has always advocated for the user’s right to privacy and control over their data.
We have been testing our SDK with Android 10 since the release of the first Q beta, and coinciding with the release of Android 10, we are releasing version 14.0.0 of the Android Bluedot SDK. We’ve bundled in many improvements and some functionality changes in response to the evolution of the Android operating system.
Here’s a round-up of the most pertinent changes to the Android app permissions and how they affect the new release of the Bluedot SDK.
New location permission
Android 10 gives users more control in how they grant location permission to an app.
Part of this control comes from a new location prompt to access the device location while an app is running in the background.
In this prompt, users will have a choice of three options for granting an app access to location data:
- "All the time" - this means an app can access location at any time, including in the background
- "While in use" - this means an app can access location only while the user is using the app
- "Deny" - this means an app cannot access location
If the user has granted “Allow all the time” location permission and the app is accessing the device location frequently from the background, then the operating system might ask if the user wants to degrade the permission from “Allow all the time” to “Allow only while using the app” as continuous location updates on device leads to higher battery consumption.
Changes to the Bluedot SDK
We have added the new background location permission
ACCESS_BACKGROUND_LOCATION to the SDK’s Android Manifest. The app has the option of requesting this "Allow all the time" permission (see Prompt 1 below) to deliver valuable experiences to the app user that wouldn't otherwise be possible with "Allow only while using" permission.
If the specific
ACCESS_BACKGROUND_LOCATION permission is not requested, the user will be prompted to "Allow only while using the app" (see prompt 2 below).
If the user previously selected "Allow only while using the app," the app has the option of later requesting
ACCESS_BACKGROUND_LOCATION permission - i.e. "Allow all the time."
Notice that users have the option to "Keep [while using permission] and don't ask again." It's important for the data apps request to match the value the end-user receives. Make sure you provide a clear and compelling explanation of why the app needs "Allow all the time" access to deliver the value promised.
The level of permission the user permits will affect whether the OS will provide the SDK and application with updates when the app is in the background.
If your app is using the foreground service implementation of the Bluedot SDK:
If your app is not using the foreground service implementation of the Bluedot SDK:
So, if your app is not using the foreground service implementation of Bluedot service and the user selects “Allow only while using the app” permission, then the Bluedot SDK cannot guarantee to generate triggers if your app is moved to the background as the application and SDK will not be getting location updates from the operating system.
If receiving triggers from the background is vital, we suggest either using the foreground service or communicating to the user the value of allowing access to location data from the background.
To give users more control over their files and to limit file clutter, Android 10 changes how apps can access files on the device's external storage, such as the files stored at the path
By default, apps can now only access the files they create and can do so without requesting permission. User permission is only required for accessing files and media created by other apps.
Changes to the Bluedot SDK
The Bluedot SDK will no longer require the
WRITE_EXTERNAL_STORAGE permission to be shown (and granted) since internal logging by the SDK will use scoped storage.
Android app permissions for network scans
Android 10 OS is restricting the functionality to enable and disable Wi-Fi from apps. To protect user privacy, manual configuration of the list of Wi-Fi networks is now restricted to system apps. Now the app will request
ACCESS_FINE_LOCATION (precise location permission) from the user if the app is using Wi-Fi, Wi-Fi Aware, or Bluetooth scanning API’s.
Changes to the Bluedot SDK
The Bluetooth scanning API is used in the Bluedot SDK and requires the user to allow
ACCESS_FINE_LOCATION. However, since the Bluedot SDK already requests
ACCESS_FINE_LOCATION for normal location tracking operation, there are no changes to the permissions required, and no effects on any applications.
The Bottom Line for Android 10
The Android app permissions in this latest OS version reflect an industry trend toward greater user privacy and data control. Now more than ever, requesting location is all about the value exchange. Is it valuable to the end-user? They need to clearly see and experience the benefit(s).
Once you’ve identified the value, consider whether it’s proportional to the permission level requested. Just because you can ask for "Allow all the time" doesn’t mean you should.
Engage app users on their terms and deliver the value they crave.
Need a fresh idea for how your app can deliver this location-based value?