Posted by: Suchi Bansal

Android 12 is giving more control on location permission. Here I am going to talk about the privacy changes in Android 12 that may affect your app. Location changes apply exclusively to apps that are targeting Android 12 or higher. If your app is targeting Android 12, you should be aware of location related changes.

Approximate location:

In Android12 users will have a clear choice regarding the precision of location provided to the app by selecting approximate location. When an app targets Android 12, users can request that the app retrieve only approximate location information, even when the app requests the ACCESS_FINE_LOCATION runtime permission.

Figure shows the user-facing dialog that appears when your app targets Android 12 and requests only ACCESS_COARSE_LOCATION .To better respect user privacy, it’s recommended that you only request ACCESS_COARSE_LOCATION. You can fulfills most use cases even when you have access to only approximate location information.

If your app targets Android 12 and you request the ACCESS_FINE_LOCATIONpermission, you must also request the ACCESS_COARSE_LOCATIONpermission. You must include both permissions in a single runtime request. If you try to request only ACCESS_FINE_LOCATION, the system ignores the request and logs the following error message in LogCat: ACCESS_FINE_LOCATION must be requested with ACCESS_COARSE_LOCATION.

When your app requests both ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION, the system permissions dialog includes the following new options for the user:

• Precise: Provides the location accuracy that the ACCESS_FINE_LOCATIONpermission provides.
• Approximate: Provides the location accuracy that the ACCESS_COARSE_LOCATION permission provides.

Above figure shows that the dialog contains a visual cue for both new options, to help the user choose. After the user decides on a location accuracy, they tap one of three buttons to select the duration of the permission grant. These buttons are the same as the ones that appear in location permission dialogs on devices that run Android 11 (API level 30).

NOTE : On Android 12, users can navigate to system settings to set the preferred location accuracy for any app, regardless of that app’s target SDK version. This is true even when your app is installed on a device running Android 11 or lower, and then upgrades to Android 12. If the user downgrades your app’s location access from precise to approximate, either from the permission dialog or in system settings, the system restarts your app’s process. For these reasons, it’s especially important that you follow best practices for requesting runtime permissions.

The following table shows the permissions that the system grants your app, based on the options that the user chooses in the permissions runtime dialog:

Affects on background location permission on user choice:

If the system grants the ACCESS_BACKGROUND_LOCATION permission to your app, the user’s choices in the location permissions dialog also apply to background location. For example, if the user grants your app ACCESS_BACKGROUND_LOCATION permission but grants only approximate location access in the foreground, your app has only approximate location access in the background as well.

Upgrade to precise location:

Approximate location might affect your app if it currently relies on having access to precise location using the ACCESS_FINE_LOCATION permission.

Before you ask the user to upgrade your app’s access to precise location, consider whether your app’s use case absolutely requires this level of precision. If your app needs to pair a device with nearby devices over Bluetooth or Wi-Fi, consider using companion device pairing or the new Bluetooth permissions, instead of requesting the ACCESS_FINE_LOCATIONpermission.

To request that the user upgrade your app’s location access from approximate to precise, do the following:

1. If necessary, explain why your app needs the permission.
2. Request the ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATIONpermissions together again. Because the user has already allowed the system to grant approximate location to your app.

Handle approximate location downgrade from system settings:

To check how your app handles a user’s request to change your app’s location access from precise to approximate in system settings, do the following:

1. Request both ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION.
2. In the dialog that appears, select Precise and either While using the app or Only this time near the bottom.
3. Navigate to your app’s permissions screen in system settings.
4. On the location permission screen, turn off Precise location.
5. As with any permission downgrade, the system restarts your app’s process.
6. Check whether your app’s use cases still work as expected, even when your app only has approximate location access.

Handle precise location upgrade from system settings:

To check how your app handles a user’s request to change your app’s location access from approximate to precise in system settings, do the following:

1. Request both ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION.
2. In the dialog that appears select Approximate and either While using the app or Only this time near the bottom.
3. Navigate to your app’s permissions screen in system settings.
4. On the location permission screen, turn on Use precise location, as shown in figure above.
5. Because this permission change is an upgrade, the system doesn’t restart your app.
6. Check whether your app receives more accurate location data in its location-based use cases.

Check for location requirements in your app’s SDK dependencies:

Check whether your app uses any SDKs that depend on the ACCESS_FINE_LOCATION permission. Check this article on Medium about Getting to know the behaviors of your SDK dependencies.

Check which permissions the system has granted to your app:

To determine which permissions the system has granted to your app, check the return value of your permissions request. You can use Jetpack libraries in code that’s similar to the following, or you can use platform libraries, where you manage the permission request code yourself.