Restrictions to background location and foreground services in Android 11

Restrictions to background location and foreground services in Android 11

Android 11 is officially out! There are many changes related to privacy you should know about and it’s good to check your apps for potential flaws. It’s also good to know what are the current platform restrictions.

I’d like to focus on important change in Android 11 that can affect your app if you are using location and foreground service. What’s important, it doesn’t matter if you are targeting your app to API29 or to the latest API30. If you are using device with Android 11 it’s also good to know how to deal with location permissions and when your app can be blocked.

Let’s get back to Android 10 for a moment.

Android 10 (API level 29) introduced a number of features and behavior changes to better protect users’ privacy. Read privacy changes docs.

To support the additional control that users have over an app’s access to location information, Android 10 introduces the ACCESS_BACKGROUND_LOCATION permission.

Unlike the ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION permissions, the ACCESS_BACKGROUND_LOCATION permission only affects an app’s access to location when it runs in the background. An app is considered to be accessing location in the background unless one of the following conditions is satisfied:

  • An activity belonging to the app is visible.
  • The app is running a foreground service that has declared a foreground service type of location.To declare the foreground service type for a service in your app, set your app’s targetSdkVersion or compileSdkVersion to 29 or higher. Learn more about how foreground services can continue user-initiated actions that require access to location.

TL;DR: It’s clear. You can use location in the app only when you are showing the user your app, user can see what’s going on and is aware of that. That’s why foreground service type was introduced.

Use case: GPS Tracker

Let’s talk about real example here. I’m working on an app that is recording trips (routes) with GPS. Change that was made in Android 10 wasn’t problematic for us. We are always showing user some UI that the app is working – notification (so we run foreground service working with active notification)

Question: Do we need to use ACCESS_BACKGROUND_LOCATION permission?

No. We are showing notification to the user, user can see that the app is working, everything is fine. And we are asking only for location Allow only while using the app. We don’t need background permission. That’s great!

Auto trip recording

In our app we have some feature called “autostart“. User can start recording automatically. For example when entering their vehicle. Simple BROADCAST RECEIVER matched with Bluetooth.

You can set this up. When you are connected to some BT device, app is starting recording route. We are starting foreground service, showing info to user.

Question: Do we need to use ACCESS_BACKGROUND_LOCATION to start GPS recording with BROADCAST_RECEIVER?

Android 10: No. Start foreground service, get location with foreground service.

Android 11: Yes. You can’t use location even with foreground service when it was started by BROADCAST_RECEIVER. Broadcast Receiver for Android 11 is background process.

When trying to start foreground service with Broadcast Receiver you’ll get this error:

Foreground service started from background can not have location

Solution: You need to get ACCESS_BACKGROUND_LOCATION for your app. Even when using foreground service. The same foreground service will work without having this permission if user stars it manually from your app (e.g. clicking record button in your app).

Changes in Android 11

At Android Developers Summit ’19 Dianne Hackborn said that “Abusing foreground services is becoming big issue and we have to do step to address that…

I believe this is the “step“.

Foreground services in Android 11

Source: /11/privacy/foreground-services

Android 11 changes when foreground services can access the device’s location, camera, and microphone. This helps protect sensitive user data.

Restrictions to access while in use

Restrictions to access while in useIf your app starts a foreground service while running in the background, the foreground service cannot access the microphone or camera. Additionally, the service cannot access location unless your app has background location access.

Asking for location permission in Android 11

I believe that in most cases you don’t need ACCESS_BACKGROUND_LOCATION for your app. It’s always good to analyse your needs here. If you need it for your use case – be aware of other changes here. You can’t ask for this permission directly. And this is another big change in Android 11.

Android 10 vs Android 11

If you are using Android 10 and you’ve added ACCESS_BACKGROUND_LOCATION to your manifest you’ll see this prompt:

Asking for BACKGROUND_PERMISSION in Android 10

Note: You’ll see Allow all the time permission if you are using Android 10.

When using Android 11 you won’t see option for Allow all the time anymore.

Get consent for background location in Android 11

This is Google’s suggestion how to deal with it. Starting Android 11 you need to explain user why you need background permission and you can’t get consent with just a click.

Always explain user why background location permission is needed and direct user to app’s settings screen.

You need to redirect user to app’s settings screen.

User is forced to manually change permission for your app (that’s why explaining him why he should do that is so important)

There’s a great codelab regarding location permission in Android 10 and Android 11. I suggest to check Receive location updates in Android with Kotlin.

This article was also published on Medium.

Android Series #1: App quality, Vitals

Android Series #1: App quality, Vitals

I’m starting Android Series on my blog (yay!). Today I’d like to focus on a news that was announced by Google 2 weeks ago and I feel that this post from official Andoid Developers Blog didn’t get much attention. I talked with many Android developers on many events and I know how approach for maintaining code can vary. In most cases on conferences we are focusing on technology, technical stuff and we forgot about quality. Don’t get me wrong, I know that Google is trying to change this situation. I’ve been to Google I/O 2018 and I was talking with Googlers about it but I saw also that many developers are more exited about technical news from Android’s world and they didn’t get much attention to this topic. It is worth to mention that new technical stuff we got from Google like Android Jetpack, Architecture Components – they are also here to help us to improve the quality – better architecture – more solid app, less crashes, better performance (so this is connected). What’s “the quality” in Android’s world?
Posted by Paul Bankhead, Director, Product Management, Google Play … Over the last year, we’ve been enhancing our search and discovery algorithms’ consideration of app quality and user engagement. This means that apps and games that have high retention rates, low crash rates, low uninstalls, and many other factors, are recommended more often. Recently, we increased the importance of engagement and app quality in our recommendation systems and users reacted favorably to the changes. With more high quality titles being surfaced in the Play Store’s recommendations, people are playing the games they download more often.
Paul Bankhead briefly listed factors that affect the quality of Android applications. We heard in the past that stability and performance is a factor when you are thinking about ASO (App Store Optimization). Now it is more clear what does it mean and we know that Google is already using this factor to filter search results at Play Store (search results, recommendations…). You want more downloads for your app? Make your app stable and don’t forget about performance.

Android Vitals to the rescue!

You’ll find Android Vitals in Google Play Console.
Android vitals is an initiative by Google to improve the stability and performance of Android devices. When an opted-in user runs your app, their Android device logs various metrics, including data about app stability, app startup time, battery usage, render time, and permission denials. The Google Play Console aggregates this data and displays it in the Android vitals dashboard.
Do you care about high retention or low uninstall rate as a developer? Probably you are focusing on crashes, ANRs mainly. It’s not enough right now. You could miss some important factors you’ll find in Android Vitals. It’s easier to understand this when you are working on your app for many years. You’ll see then also that in many cases fixing/improving Android Vitals can be a long term process. You could say that’s it’s not your problem as a developer – retention, number of downloads – it’s marketing or maybe product owner should care about this. Maybe, but right now you should be aware that with Android vitals as a factor in Play Store you are also responsible for this. All sides of a project should have this knowledge. Product manager was ignoring your suggestions about this? Tasks related with performance were moved to low priority queue? Right now maybe you should change your way of dealing with it. Especially when the app is your business. If you are a developer don’t focus only on problems mentioned for example in Crashlytics console. Be aware about Androd vitals. I hope that Google in future will move some information from vistals to Crashlytics console. I started writing more detailed article about Vitals but in my opinion Wojtek Kaliciński’s treatment of the subject is exhaustive. Wojtek posted two great articles about Android Vitals and you should read it:
  1. How to fix app quality issues with Android vitals
  2. How to fix app quality issues with Android vitals (Part 2)
I strongly suggest you also to to see the session about it from Google I/O ’18 See you next time!