Exploring the Android 11 Developer Preview: Permission Changes
That time of the year has come, a new Android version is on the horizon! As announced in a blog post earlier this week, the first developer preview of Android 11 is now available — along with details on some of the changes that are happening. With this announcement come some changes to how the system operates when it comes to permissions and how this will affect applications — I wanted to take this chances to flesh out some of these changes and share some thoughts around them.
This was originally posted on joebirch.co
One-time permissions
Currently when we grant an application some permission to access certain data (or perform a certain task) we get several options on the scope of that access. For example, if an application wants to access my location then I can either grant access whilst the app is being used, or deny access. I’ve always felt a bit skeptical about this — whilst the feature I am using at that time might require my location, I don’t really want the app having access to my location whenever it pleases (whilst the app is open). Whilst we can go into an application settings through the system and revoke access, some users may not be aware of this. With this in mind, having the option to only grant access (meaning, grant it all the time) feels like a big commitment.
In Android 11 a new option is being added which will grant permission for only the current session. This means that if access is required again at another time, then the permission will need to be requested again.
But what defines the current session for that permission? For the current activity, that permission will be accessible whilst the activity is visible to the user — if visibility changes and then the activity is returned to, the permission will need to be requested again. Because of this, it would be worth checking when you are requesting these permission within your screens. If you leave and come back to your permission requiring feature, you may need to move permission checks to ensure that the feature is still accessible.
There is one condition where the above does not hold true — if you are running a foreground service since granting the permission and the user leaves/returns to the app before the foreground service has finished, then the granted permission will remain accessible. The below diagram outlines these cases:
With the above changes in place, it not only helps to ensure that application are only gaining access to this permission for what it is required, but it also greatly reduces the decision for the user and removes that feeling of making that big commitment to all the time access.
Denying permissions
Currently in Android we can display permissions dialogs to users when we want to access media, location and so on. These dialogs are a great way to protect users from unwanted access to certain content / activities on their device. Unfortunately, it’s easy for applications to abuse this dialog — whilst the user can explicitly selected “Don’t ask again“, this personally feels like a bold move. Maybe it is psychological but I never select this option, even though I’m never likely to grant that specific permission for the given app — funny, eh? At the same time though — I also find it annoying when an application will ask for that permission again — I can’t win!
One of the neat things about Android 11 is that if a user selects “Deny” within a specific permission dialog more than once, then that will be treated as “Don’t ask again“. This means that applications that frequently ask for permissions that users do not accept will be defaulted to not being able to ask for those permissions again, which is a huge win for user privacy.
There are a couple of cases where these rules might behave differently. For example, if the user presses the back button to dismiss the permissions dialog, then this will not count as a Deny action. However, if requestPermission() is used to take the user to the system settings screen, this will count as a Deny action if the back button is pressed. The below diagram outlines these cases:
These changes will help to reduce any abuses of permission requests, also promoting that applications be more descriptive upfront about why permissions are being requested, along with requesting them as and when they are required to help reduce the chance of being granted access.
Background location permission
Location access has always been an important privacy point in my mind — I’ve never really wanted applications having access to my location all of the time. However, it was provided as an option in permission requests for location. When targeting Android 11, applications will no longer have the ability to request access to location data all of the time from within your application — this option has been removed from the in-app permissions dialog. If an application wants permission to access the users location all the time when in the background, the permission will need to be granted from within the system settings screen for your application.
When it comes to accounting for this change, there are a few steps that need to take place. We need to begin by adding the ACCESS_BACKGROUND_LOCATION and either the ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION permissions to our manifest file. Then, when we need to access the users location, we can begin by requesting permission for either the FINE or COARSE location:
requestPermissions(arrayOf(ACCESS_COARSE_LOCATION),
REQUEST_CODE_COARSE_LOCATION)
We must do this before requesting access to the BACKGROUND location, doing so without the above permissions will not show any permission dialogs in the UI. Once the above permission has been granted, we need to go ahead and display some form of explanation to the user as to why we need access to their location in the background, along with an action (such as a button) which can be used to trigger the permission flow. It’s important to note that this is not a system provided UI and must be provided by your application. When the user clicks the action that you provide, you can either:
- Use requestPermissions() to request the ACCESS_BACKGROUND_LOCATION permission
- Launch the app info page within the system settings
When providing this above context to the user, it’s important to make it super clear as to why you need this permission — if the user does not grant the permission after it has been requested two times, subsequent permission requests will be ignored. It is at this point you will have to resort to manually launching the app info page — this isn’t ideal as you can’t take the user directly to the location permissions screen, so some context will be lost. However, if your application hasn’t reached the permission dialog limit, then the first option of the above should be the desired route.
requestPermissions(arrayOf(ACCESS_BACKGROUND_LOCATION),
REQUEST_BACKGROUND_LOCATION)
When this is triggered, our user will be taken directly to the location permission system settings screen for our application. From here the user grant our application the permission that they desire — when returning to our app we can then check that the permission we require has been granted.
The below image shows an outline of the above background location permissions flow:
With these background permission changes in place, applications will again need to be sure to be descriptive about the permission that is being requested and make subsequent changes to the permission flow to ensure that the above is handled correctly.
In this post we’ve taken a look at some of the permission related changes that are coming in Android 11. Whilst these may seem like a big change for developers, they will make our users experience feel both safer and more pleasant. If handled correctly within our applications we shouldn’t see a negative impact in the user experience. Remember, only request permissions as they are needed (along with if they are needed) and give enough context as to why that permission is needed.
Stay tuned for the next post on upcoming Android 11 changes!