In Sep 2008, Android provided developers with the ability to use GPS location with app users' permission as part of the first Android 1 (API 1). Millions of apps have been built using location-based services in creative ways since then. As more apps started using location in the background, and sending this data to servers for use by applications outside the device, Android started setting some rules of the game to manage battery drain and user privacy. Beginning with Android 8 (API 26) in Aug 2017, the platform has evolved significantly with regard to location access controls. In this post, we review the changes from Android 8 to 10, and take a look beyond to Android 11. In particular, we look at how this impacts product development teams building live location apps.

Android 8 (Oreo) distinguishes foreground and background

Android Oreo (Android 8 / API 26) was the first OS update to impose meaningful restrictions on app developer’s ability to access location by distinguishing between foreground and background apps. Prior to Android 8, apps with location permissions could access that data in any form they liked, which adversely impacted device battery and user privacy.

Remember that time in Nov 2016 when news hit the wire that Uber started background collection of rider location data? There had already been years of chatter about Google Maps tracking you in the background, and we learnt to look away because Google Maps and Android were two products from the same company. The Uber exposé felt more drastic, users awakened en masse, and mobile Operating Systems had to act decisively.

Android 8 clarified that “in an effort to reduce power consumption”:

“The system distinguishes between foreground and background apps” and goes on to clearly define each.
The system “limits how frequently background apps can retrieve the user's current location. Apps can receive location updates only a few times each hour.”
The system allows apps to start a foreground service to “retrieve location updates more frequently”, though clarifies that “when such a foreground service is active, it appears as an ongoing notification in the notification area” (a.k.a. persistent notification)

While the release cited battery efficiency as the main driving force behind the changes, it was no coincidence that Uber ended its post-ride tracking of users’ location a week after the release of Android 8 in Aug 2017.

What did these mean for apps that wanted to access location in the background with higher frequency than few times each hour, and do so with explicit user permission? This was still possible to do by starting a foreground service in the app.

Let me distinguish between foreground apps, background apps, and foreground services with some examples.

Foreground app

A navigation app like Google Maps is naturally used in the foreground. The app uses GPS location with high frequency and pulls up map data from the server so users can get turn-by-turn directions in real-time while driving. From the user’s perspective, the data remains private on the device to serve the navigation use case. However, navigation apps might choose to store this data and send it to the server for telemetry to improve maps for everyone.

Background app

Local search or content apps like the ones we use to check the weather, or find restaurants, or get news, use location to figure out where you are. Many of these apps track background location as specified by Android, and would count as background apps. “Few times each hour” is meaningful when you add up millions of users. Users are often unaware of such tracking and this data might be used for advertising, or find its way to data brokers who sell it to anyone who is willing to pay for it!

Foreground services

Logistics, gig work and delivery apps like the ones used by drivers in the supply chain of commerce, need not be in the foreground at all times. However, business needs to access location at a higher frequency for routing orders, tracking progress, sharing live location with customers, and expensing miles.

To power experiences that users want, many consumer apps might require higher frequency location access in the background too. For instance, social apps that power live location sharing between friends with mutual opt-in, two sided marketplaces with live location sharing to consummate transactions offline, and other consumer apps in health, finance and insurance where the user lets the service track frequent locations for direct personal benefit.

Turns out, there are hundreds of thousands of apps that fall in this category of tracking movement with user permission. In Android 8, these apps start a foreground service that allows access to location even while the app is in the background. The user will see a persistent notification for these apps so there is clear communication that the app is using a foreground service even while the user is on another app or has the phone in the pocket.

Android 9 (Pie) makes incremental changes

Android Pie (Android 9 / API 28) made incremental updates with respect to location access. Android 9 closed some long standing security loopholes. Before Android 9, apps could use Mozilla Location Services or similar services to determine “location based on network infrastructure like Bluetooth beacons, cell towers and WiFi access points” without location permissions from the user. After Android 9, these APIs require the same permission as location APIs. It may be noted that fused location provider merges GPS with network infrastructure to provide accurate user location. It is the ability to circumvent location permissions that got shut with Android 9. It is natural for such vulnerabilities to exist and it was a great move by Android 9 to fix it. Legit businesses were not impacted by this change.

Android 10 makes background permission explicit

Android 10 (API 29) made an important privacy update with “more user control over location permissions”. Remember background apps that get location permissions to check weather and local news, and then track you a few times an hour anyway, even when you are not using the app? These apps now require explicit user permission to access background location.

Apps that start a foreground service, as discussed earlier in the context of tracking commercial movement, can continue to track frequent locations in the background. App developers need to declare a special service property and publish an app update that targets Android 10. Once the user has updated the app, location tracking will continue as before with no change in user flow. As before, users will continue to see persistent notifications for apps with foreground service for location.

Not only did Android 10 let go of dessert names (after a last attempt to name it Android Q for Queen Cake), it deserted background apps secretly tracking locations of consumers who did not intend to be tracked. This is a healthy development for the world of apps, and we expect further improvements in this direction with Android 11 coming up in the Fall of 2020.

Android 11 will add fine grained control

Android 11 is expected to release in Q3 this year, with further improvements in user privacy. Users will get more fine-grained controls over location permissions. Specifically,

Apps will be required to handle one-time permissions where users grant temporary access to location. Apps will need to be “designed to handle situations where data access can be lost when the user moves away from the app and the app can request the permission again”.

In addition, background apps will need to “request foreground (coarse or fine) and background location permissions incrementally in separate calls to the permission request method. Before each request, use a full screen view to explain the benefits that users receive for granting that permission”.

Other considerations

Despite having all necessary location permissions from the user, there are certain scenarios when the app will encounter location outage from the Android platform. This is not an exhaustive list, though representative of issues that developers are likely to encounter in a production environment of a meaningful size.

User may revoke access for the device (applies to all apps) after first granting access in the app

User may revoke access specifically for your app after first granting access in the app

User may force stop the app through settings, thus killing location access for the app

Device may enter low battery or battery saver mode that causes location access to be suspended in uncertain ways

Device may enter an area, like a subway or basement, where locations are unavailable but location service pretends to behave normally

Native v Hybrid

A side impact of the updates in Android 8 onwards is that location APIs will require native app development. Direct control through hybrid frameworks like React Native, Flutter, Cordova, Ionic or Xamarin will no longer work. Hybrid app developers will need to build native functionality for location access.

Summary

In the last three years, location access on Android has evolved from a binary allow/deny state, to few times an hour throttle for background location and persistent notifications for foreground service, to plugging a security loophole to get non-GPS location, to explicit permissions for throttled background location. The future brings granular privacy controls with one-time access, and incremental permissions from foreground to background.

Background location access, as specified by the Android platform, would work best for apps that use location for content personalization and local search. Live location apps using more frequent location with explicit user permission, e.g. commerce, logistics, workforce, gig economy, delivery, ridesharing, social sharing, etc. should use foreground service with properly set attributes as recommended by Android.

Would love to hear from you about your live location use case, and exchange thoughts on the best way to manage access controls to protect user privacy and minimize battery drain.