Said to the geographical location, you should be very familiar with, whether you need the most simple application, or through some user’s location information to do some more advanced features, for example recommend restaurant near to the user, or to help users find nearby friends, and attractions, and so on these functions, you will inevitably need to use the location permissions.

Android Q location permission changed

Before Android Q, which is Android P or earlier, if your APP required a location permission, the user would see a popup like this, and then the user would basically have two options: allow or deny. If the user clicks permit, then your APP can get both foreground and background location permissions. This means that at any time, the authorized API can obtain the location of the phone.

In Android Q, the biggest change is the addition of a new state in the area of location permissions, which is called Allow only when using the application.

Prior to Android Q, if you needed to use location permissions, you needed to add a uses-Permission request to the Android manifest file. Before, there were two types, coarse-location and fine-location. There is no difference between them. The only difference is in accuracy. Coarse-location will only be roughly accurate to the city level, while fine-location will be accurate to the LOCATION provided by the phone.

Android Q Benefits of location permission changes

One of the great things about the Android Q SDK is that you can apply for location permissions based on how your app is being used and what scope you need. For example, if your APP only needs to use location information in the foreground, you can display a pop-up box to the user, and the user can clearly see the small print below that says “the user has access to location information only when you use the APP.” And then it feels safer for the user, because he didn’t have that option before, and now that he has the assurance of use, he might be more willing to give that location permission to the corresponding application.

Then you can also consider applying for location permission incrementally. For example, the pop-up box you see now is applying for location permission at the front desk, and then the user can choose to allow or reject it. And then when you have a particular use case, or a further use case, where you need to use the location in the background, you can pop up a new box and ask the user if they want to give you more location permissions, and you can see that the user’s choice now is either to allow it all or to keep it as it is.

Map APP Example

Take map App as an example: For example, the main function of my map App is to display the geographical status of the surrounding area to users when they open my App. I can actually think about, I’ll only ask the user when the App is open, get the foreground location permission. When a user needs a more advanced function, for example, the map App can give him real-time traffic updates when he needs to be in the background, or help him predict how long it will take to get home. In fact, these functions do not run in the foreground, but in the background. For example, at 6 p.m., pick up the user’s location and help him calculate when he’ll be home. If the user needs to enable these functions, or is recommended to enable this function by a certain App, it will be more reasonable for the Mymap application to ask the user for the permission of the background location information, and then the user will be more willing to give the application more advanced location permission according to the use case.

Starting from Android 6.0, location permission is a private permission, which has been applied in the Android manifest, but also needs to be applied dynamically in the code. And requestpermissions means that all we need to do in Android P right now is coarse-location and fine-location.

In Android Q, however, the foreground geo-permissions remain the same, meaning that your App only needs foreground geo-permissions, so you just need to write a requestpermissions in your code. If you need BACKGROUND LOCATION permissions, you need to apply for access-background-location.

At the same time, we also suggest you to use it together with the checkSelfPermission API, because now we have the status of three geo-location permissions, so you need to check the level of your current geo-location permissions, whether you have none at all, or whether you have the foreground. Or do you now have city-wide geolocation access?

One thing to note is that you may ask, if the user has an Android P phone before, and then his phone has been upgraded to Android Q through OEM push, will those apps that need to access the location be affected? The answer is no. Before the application with location access, it will have foreground and background, because Android P to Q will still inherit access, will still have foreground and background location access. If it doesn’t, it doesn’t.

Another point is that the SDK version App before Target Q has a particularly big impact, that is, while-in-use permission is in the system Settings. In fact, users can access the specific Location setting page of each App. It can choose to turn off Permission for the App background or the entire App. If your app is the SDK Level before Target Q, and the user happens to turn off your background Location Permission, your app will not be able to detect the change through the API. Then there is no way to regain background location permissions through any API. So if your application has very important use cases that must use geolocations in the background, be sure to update your Target Q to the Q SDK Version so that you can use the latest API and Manifest Permission.

Foreground services

Next we want to talk about the foreground service and the latest Location Permission changes.

Again, using the map APP as an example, you can see that if the user starts a navigation in the map and then leaves the Map APP, either to go to another APP, or to turn off the screen of the phone, the map APP, he will start a foreground service, Foreground Service to continue the navigation task.

But be aware that if your application, like the map application in our example, only has access to the foreground location, it needs to add a new attribute to its foreground service, This attribute is the latest foregroundServiceLocationType = “location”, it can only be in the front desk service access to the geographic location information. And it’s important to note that attribute is only available in the Q SDK, so your application needs to be compiled with the Q SDK, you don’t need target. And even if your app doesn’t have Target Q, the SDK will be limited, and your service will not be able to get the location in certain situations.

Location reminder

The user’s geolocation control went from Yes and No to three levels, and there was a gradual progression.

We’ve also increased the transparency of this piece of location information for users.

This graph is one of the notifications we’ll be showing users about location usage in the new Android Q. My Train Commute is the name of an APP that is using your location. The APP can be changed at any time using your location information.

If the user presses the notification, it is taken to a Settings page, which allows the user to change the location of the app from All All the time to Allow only while using the app, or to Deny the app altogether.

You might ask him when this notification is going to happen, and will he say it’s happening so often that it’s annoying to users? Notifications will only appear if both of the above conditions are met. One means that the application must have full time location permissions, both foreground and background location permissions. And the time that it appears is when the app goes into the background, and when it first gets the Fine Location message, notice that if the user goes into the system Settings, changes the full time location of the app to only in the foreground, or turns it off, and then changes it back to full time, So this technique will be cleared, that is, the next time the application receives the first fine location information in the background, the notification will appear again.

Best Practice

These are all the changes in Android Q regarding location permissions.

I want to summarize the Best practices in Android Q.

Summary of Android Q Location permission Changes

• First, please apply for geolocation information only when you need it. Because every time you apply for geolocation permissions, your application needs to give the user a popbox, and then for the user, of course, you want as few popboxes as possible. So don’t ask for geolocation permission if you don’t need it.

• The second is that you want to apply only for the location permissions you need. Because we just mentioned that there are many levels of geographic LOCATION, with permissions including coarse-location and fine-location, as well as foreground and background, please carefully consider what kind of scenario your use case is, and then apply only the level you need.

• The third point is the problem about the application, there may be some developers will feel if in my code to find all I need to use the location permissions points there are too many and too complicated, I just directly in the application for the first time open, is or is to find a unified point of relief finish all permissions apply, very convenient for me, Some of the code should be in one place. But it’s actually quite confusing for the user, because he doesn’t even know what your application is doing, and he already sees you asking for privileges that are very personal and security sensitive to him. So we want you to try to put these applications in context. For example, if you are a food delivery App, you need to obtain the user’s address to deliver food to him. Before this process, we hope that you do not apply for both coarse-location and fine-location as soon as possible. Only when the user enters the address, The application coarse-Location and fine-location pop-ups are displayed.

• Fourth, we hope that you can apply for location in a progressive way. That is to say, we just mentioned at the beginning, if your App only needs to apply for the foreground location right now, please leave the background location right for later, and you can apply for it when you really need.

Last but not least, before writing any code that requires location permissions, check your current Locaiton level. Because there are now three levels, you need to check to see if you have the Location Permission you need, and most importantly, if you don’t have the Location Permission you need, Maybe you should consider a backup plan if your App really just won’t work. Take-out App because like I just said, if the user at the time of his address, your App bounced ask users to location permissions, user said I don’t give, in fact, the user can also according to his own geographic location himself to fill out, he directly selected from the provinces and cities to the street, he could to fill out, he may not need you to locate, And then you help him find the location.

Android Q Labs live features page

Android Q Labs opening speech

What are the updates to Android Q

Android Q modernizes your application

Restrictions on background Activity startup

Android Q partitioned storage

Android Q gesture navigation

Jetpack update

Android Q adaption for foldable devices

Introduction to common system images

Google Play Store policy

Android Q has a dark theme

Android Q Labs concludes the presentation