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.
Source: 9to5google
Source: 9to5google
What is background location permission Android?
When a feature in your app requests background location on a device that runs Android 10 (API level 29), the system permissions dialog includes an option named Allow all the time. If the user selects this option, the feature in your app gains background location access.
Android 10 features a background access location reminder, which increases transparency into how much access apps have to a device's location and helps users maintain control over such access. In Android 9 and lower, an app can track a device's location while running in the background without the user’s knowledge. Users can suppress this behavior in Android 10 by selecting either the Allow only while using the App or Deny location access permission.
On Android 11 (API level 30) and higher, however, the system dialog doesn't include the Allow all the time option. Instead, users must enable background location on a settings page, as shown in figure 7.
You can help users navigate to this settings page by following best practices when requesting the background location permission. The process for granting the permission depends on your app's target SDK version. Everything will be explained in the article.
Android 10 features a background access location reminder, which increases transparency into how much access apps have to a device's location and helps users maintain control over such access. In Android 9 and lower, an app can track a device's location while running in the background without the user’s knowledge. Users can suppress this behavior in Android 10 by selecting either the Allow only while using the App or Deny location access permission.
On Android 11 (API level 30) and higher, however, the system dialog doesn't include the Allow all the time option. Instead, users must enable background location on a settings page, as shown in figure 7.
You can help users navigate to this settings page by following best practices when requesting the background location permission. The process for granting the permission depends on your app's target SDK version. Everything will be explained in the article.
Why does your app need access to location in the background?
Background location may only be used to provide features beneficial to the user and relevant to the core functionality of the app. Apps designed specifically for children must comply with the Designed for Families policy.
Developing the app that includes Manifest.permission.ACCESS_BACKGROUND_LOCATION
Many Android application developers including me had a struggle with ACCESS_BACKGROUND_LOCATION implementation without being rejected from Google Play Store. The first try was like, meh I'll do it but after a second rejection I had to perform deep research to make this work. Well after 5th rejection I made it.
I'll be really happy to share the code including the whole process with you. In this guide, I will separate code into several methods for easier understanding. Code will be written in Kotlin.
I'll be really happy to share the code including the whole process with you. In this guide, I will separate code into several methods for easier understanding. Code will be written in Kotlin.
Step 1.
Defining permissions in AndroidManifest.xml is important, copy/paste code below
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
Step 2.
There are a few different approaches that we should cover with the code because there are changes in Android R that changed the behavior of giving the Manifest.permission.ACCESS_BACKGROUND_LOCATION.
My high recommendation is to use Material Dialog as a disclosure for any of the location permission requests.
My high recommendation is to use Material Dialog as a disclosure for any of the location permission requests.
Let's start with the first snippet of code. For the callback, we will use registerForActivityResult.
We should register the permissions callback, which handles the user's response to the system permissions dialog.
Save the return value, an instance of ActivityResultLauncher. You can use either a val, as shown in this snippet, or a lateinit var in your onAttach() or onCreate() method.
We should register the permissions callback, which handles the user's response to the system permissions dialog.
Save the return value, an instance of ActivityResultLauncher. You can use either a val, as shown in this snippet, or a lateinit var in your onAttach() or onCreate() method.
Targeting <= Android 9 (P)
Android app that targets SDK prior to Android P needs simply to ask for the permissions where the request should contain those two permissions, and this will also be the first case
Manifest.permission.ACCESS_COARSE_LOCATION
Manifest.permission.ACCESS_FINE_LOCATION
A simple method with Material Dialog is shown below. The title and message of the dialog should be an explanation of why you'll need such access. The strings below are just an explanation.
<string name="location_title_rationale">Request for location permission</string>
<string name="location_message_rationale">The APP NAME requires LOCATION PERMISSION to work as expected.</string>
<string name="location_message_rationale">The APP NAME requires LOCATION PERMISSION to work as expected.</string>
Targeting <= Android 10 (Q)
On the other hand, Android 10 is similar to its predecessors, the only difference is the prompt dialog that shows one more option Allow all the time.
The request should contain those three permissions. This is the second case.
The request should contain those three permissions. This is the second case.
Manifest.permission.ACCESS_COARSE_LOCATION
Manifest.permission.ACCESS_FINE_LOCATION
Manifest.permission.ACCESS_BACKGROUND_LOCATION
This code sample is nothing different than the previous one. The only difference is one more permission inside request and different strings for the dialog. Same as above strings below are just an explanation.
<string name="location_background_title_rationale">Request for background location permission</string>
<string name="location_background_message_rationale">The APP NAME need BACKGROUND LOCATION ACCESS PERMISSION to work as expected.\n\nTap \"Allow all time\" in the next screen</string>
<string name="location_background_message_rationale">The APP NAME need BACKGROUND LOCATION ACCESS PERMISSION to work as expected.\n\nTap \"Allow all time\" in the next screen</string>
Targeting >= Android 11 (R)
The third case is the most specific one where you should first ask for the location permission and after that point the user to the Location permission menu in application info. The differences between the dialogs are visible below.
The best example of the UI which I found and which will help you out in this journey is Google Fit App.
Image 1. Represent all needed elements, such as an explanation on why the app will need the background location permission
Image 2. After pressing Step 1, the dialog will appear to give a location access
Image 3. Step 1 is marked as finished and you are ready for Step 2
Image 4. After pressing on Step 2, you'll be forwarded to location access selection
Image 1. Represent all needed elements, such as an explanation on why the app will need the background location permission
Image 2. After pressing Step 1, the dialog will appear to give a location access
Image 3. Step 1 is marked as finished and you are ready for Step 2
Image 4. After pressing on Step 2, you'll be forwarded to location access selection
The code snippet below is using methods shown earlier in the topic.
We have finished the code side, let's move to the rest of the important things that should be done before sending the app to the review.
Step 3.
Before sending the form
If something is wrong you’ll get an answer from Google the same day (of course this can vary).
I think we don't need any more explanation here.
- Check if you need this permission. In my opinion, in most cases, you don’t need it. Setting GPS permission to “While app in use” should work for most apps.
- In my case, that permission was needed for one special feature in the app. Also, I needed to add it because of the change of using foreground services in Android 11
- Make sure you’ve added prominent disclosure and runtime permission (with user consent)
- Usage of the location should be clear for the user but we’ll stop here because in most cases your app can be rejected because of missing proper disclosure
- Prepare a video of your app showing the usage of that feature. Prominent disclosure should be also visible on your video.
If something is wrong you’ll get an answer from Google the same day (of course this can vary).
I think we don't need any more explanation here.
Step 4.
Adding a privacy policy to your app's store listing helps provide transparency about how you treat sensitive user and device data. The privacy policy must, together with any in-app disclosures, comprehensively disclose how your app collects, uses, and shares user data, including the types of parties with whom it’s shared. You should consult your legal representative to advise you of what is required.
- You must link to a privacy policy on your app's store listing page and within your app.
- Make sure your privacy policy is available on an active URL, references to your app, and specifically covers user privacy.
- If your app uses location in the background, your privacy policy must contain appropriate related disclosures, reference location data, and provide information about the app’s usage of location data.
- Ensure your privacy policy page is clearly labeled as such in the title or URL and within the body of the page.
Here is one example of the text snippet to add under Information Collection and Use
Location and Background Location access
Location access including background location access is required for the expected work of the [FEATURE NAME, FEATURE NAME...]. Location, including Location in the background, is used for GIVING EXPLANATION. APP NAME does not use either share or store your location. Once the app data is removed or uninstalled everything will be removed.
Location access including background location access is required for the expected work of the [FEATURE NAME, FEATURE NAME...]. Location, including Location in the background, is used for GIVING EXPLANATION. APP NAME does not use either share or store your location. Once the app data is removed or uninstalled everything will be removed.
In the case above application does not store any location info, if your app does the opposite, you'll need to define it that way.
Good Luck! :)
Good Luck! :)
RSS Feed