Android 11 background permission

Understanding permissions for background location on Android 11 and below

Oct 29, 2020 · 5 min read

Getting the permission to access location in the background is more complicated now compared to the days of Android Pie. How permissions behaves on Android 9 (and below), 10 and 11(and above) for background location are all different. How the permissions show up for the end user not only depends on the Android version but also on the app’s targetSdkVersion .

Android 9 and below

On Android Pie, accessing location in th e background is not treated any differently than regular location permission and being granted location permission to an app makes it eligible to access the location in the background as well. The location permission is a simple ON or OFF switch. Just 2 options. Simple.

targetSdkVersion = 28 (or less)

For Android 10 and above, two situations arise, apps built with targetSdkVersion = 29. Lets talk about 28 (or less) first. If app’s targetSdkVersion = 28 (or less) means the code is still requesting the regular location permissions.

Android 10 onwards user will be shown 3 options when requesting permission for location. If user selects “ allow all the time”, then the app will be able to access location in the background.

When requesting location permission on Android 11, it will show 3 options with an additional message. The message tells the user that if she wishes to allow the app access to location all the time, then enable it in settings. So the “ allow all the time” option isn’t shown via pop-up dialog anymore but accessible only in the app’s location permissions settings.

targetSdkVersion = 29 (and above)

To be able to access background location if your app targets API 29 and above, you need to add this permission to the manifest

Now that this is a separate permission, on requesting regular location permission, “ Allow all the time” option does not even show up. This (Left) is what is shown when you request a Manifest.permission.ACCESS_FINE_LOCATION permission. But since you’ve mentioned background location permission in the manifest, “ Allow all the time” option is available in the settings though —

For Android 10 and up, you have to explicitly request for background location. So just like you requested for Manifest.permission.ACCESS_FINE_LOCATION , you now do so for Manifest.permission.ACCESS_BACKGROUND_LOCATION . But there’s a big gotcha here.

On Android 10 and up, if an app has not been granted access to regular location permission, then background location permission dialog doesn’t even show up. In this situation, shouldShowRequestPermissionRationale() returns true . So to get access to background location you need to first get access to foreground location permission.

After a user has granted access to foreground location, this is what a user will see when requesting for background location —

This is basically saying that you’ve given the app access to it while you you are using it, do you wanna extend that and give it access to location all the time?

So thats Android 10. Moving on to Android 11 and up.

The code for background location permission for targetSdkVersion ≥29 remains same, but the behaviour on Android 11 changes. If you request a regular location permission this is what shows up —

Источник

Android 11 requires visiting Settings to grant apps background location access

— Jun. 29th 2020 9:59 am PT

For its third edition, the 11 Weeks of Android series is diving into “privacy and security,” which is the upcoming operating systems’s third major tentpole alongside People and Controls. Most of the major features have been announced, but this week provides a deeper dive with some highlights.

One of the more significant privacy changes in Android 11 deals with further restricting background location. The OS already reminds users about such app access, and Google has found that this results in people downgrading or outright denying the location permission over 75% of the time.

The company believes that most developers can “provide the same user experience by only accessing location when the app is visible to the user.” As a result, Google is reviewing all Android apps requesting location access. Applied at the Play Store-level, there are very few exceptions, though Google is now giving existing apps until 2021 — instead of November 2 — to comply and remove unnecessary background location usage.

Apps — location sharing, emergency/safety — that need the background permission will have to direct users to the full Settings app. An application will first need to ask for foreground location, and can then direct users via a prompt to open system preferences. This makes the entire process a “more deliberate action.”

Building off the ability to limit location to “While app is in use,” Android 11 adds one-time permissions for microphone, camera, and location. Google notes that when Android 10 introduced that granular permission option last year, users selected it over half the time. Meanwhile, the new option does not require any work on the part of developers.

Apps targeting Android 11 that haven’t been opened for an “extended period of time” by a user will have its permissions auto-reset. You’ll be notified when this occurs, and there is a new “Unused apps” page in Settings to manage and quickly delete.

If you have an app that has a legitimate use case to retain permissions even if a user doesn’t frequently interact with your app, you can prompt users to turn this feature OFF for your app in Settings.

Google is also helping developers audit apps to limit access to sensitive data. New APIs “identify code that is accessing gated permissions even within 3rd party SDKs.”

Scoped Storage was a contentious change introduced in Android 10 designed to limit broad access to files on a device. Developers were able to opt out, but it’s now mandatory for apps targeting Android 11. Another change Google has made is creating a special permission for file managers and backup apps that do need to manage all files in shared storage. Google Play will manually review all these requests.

Other changes include more Project Mainline modules, with Google highlighting how these Play system updates helped “quickly fix a critical vulnerability in the media decoding subsystem” earlier this year. It also continues work on an Identity Credential API that will allow drivers licenses and other IDs to be stored digitally. Google says it is “working with various government agencies and industry partners to make sure that Android 11 is ready for such digital-first identity experiences.”

FTC: We use income earning auto affiliate links. More.

Источник

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.

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:

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.

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:

Источник