Android Q lets users manage location permissions elegantly

[[262144]]

Apps can use location data to bring Android users a wonderful and rich mobile experience, such as searching for nearby food, tracking running distance, driving navigation, etc. However, location data is also a highly sensitive personal information. We want to provide users with a simple and easy-to-understand control mode to facilitate them to manage the location data shared with applications. Therefore, with the release of Android Q, we give users more location control and hand these controls over to users. We are very happy to see developers use their creativity in their applications to create excellent location experiences. At the same time, we also hope to do our best to help you smoothly transition to the new location management mode. This article will conduct an in-depth discussion on the following three issues:

• What location permission changes does Android Q introduce?
• How will your application be affected?
• Where should you start to make necessary updates?

In the past, users had only two options for location permissions, namely, allowing or denying apps to access device location, and once granted, the permission did not change with the change of app state (entering or exiting the use state). Android Q adds an option that allows users to choose to share location information with apps only while the app is in use, that is, when the app is running in the foreground. This means that Android Q users can manage location permissions in the following three ways:

• Always allow: The app can access location information at any time
• Allow only while in use: The app can only access location information while it is in use
• Deny: The app cannot obtain the device's location information

Some apps and features only need access to the device's location when they are being used. For example, if a user is trying to search for nearby restaurants, the app only needs to obtain the device's geographic location when the user opens the app and searches.

But other applications have slightly different scenarios, and they still need to be continuously located even when not in use. For example, some applications can automatically record mileage for users and help them file taxes without user involvement.

Under the new location management mode, users can decide the time period for the device to share location data, while preventing apps from obtaining unnecessary location information. When an app requests access permissions, a dialog box will pop up on the screen, showing the user the new permission options. Users can change the app's access permissions at any time by clicking Settings → Location Information → App Permissions.

Easy to get started

We understand that these changes may affect your apps. We respect the developer community and our goal is to treat all such changes with caution. Therefore, we will help developers deal with the new location management from the following two aspects:

Features that impact developers are released in the *** Q Beta version, giving you enough time to make necessary updates to your apps.

More learning resources, such as developer blogs, developer guides, and privacy checklists, will be released soon to provide you with more details.

If your app targets Android Q and includes features that require "always" access to the device's current location, add the new ACCESS_BACKGROUND_LOCATION permission to your manifest. If your app targets Android 9 (API level 28) or lower, the system automatically adds the ACCESS_BACKGROUND_LOCATION permission to your app when you request ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION. To maintain a good user experience, design your app carefully to ensure that it properly handles situations where the device's location cannot be accessed from the background or cannot be accessed at all.

If users know why the app needs the corresponding permissions, they will be more likely to accept permission requests. In addition, for features that require permissions to use, please be sure to choose the appropriate time to request based on the specific scenario: when the user enables the feature or interacts with it, such as searching for nearby content, then initiate the request. ***, you should avoid requesting too many permissions. In other words, if a feature in your app only requires "while in use" permissions, there is no need to request "always allow" permissions.