Respect for consumer data privacy is a core principle at Foursquare – thus, all of our products are designed and built with privacy in mind. The recently released Android 12 introduces new features, focusing on user location privacy, specifically allowing users to provide apps only their approximate location. But being a trusted location data platform, it’s also important for us to access the user’s location to power FSQ/Pilgrim SDK and other services.
At first glance, many developers may worry that these new features create some new challenges for SDK and app products. Both require proper implementation of these new features and testing, and apps that require precise location also must explain to users the value exchange your add apps’ value through onboarding or upselling. But for those interested in building privacy-first apps, these requirements should be seen as opportunities – not obstacles.
I gathered some observations and recommendations from updating our app, Foursquare City Guide, to support this new security feature. Additionally, I detail another new security feature starting in Android 12: opting out of the advertising ID.
Android Share Location: PRECISE VS APPROXIMATE
Android already allows users to select when they want to grant the app location access (foreground/background); Android 12 takes this a step further by allowing users to specify the accuracy of the locations they share, choosing between approximate and precise location accuracy.
Precise location uses data from various sensors on the user’s phone, such as GPS, to pinpoint the user’s location down to meters. Suppose the user only grants approximate location accuracy. In that case, Android uses Google Play services to locate the user based on Wi-Fi and cellular data, locating a user within an area a few hundred meters wide, allowing an app to know which neighborhood or region the user is. However, it is not accurate enough to determine the user’s location (venue, restaurant, etc.). For this reason, an app must identify when a user has opted out of precise location accuracy. Additionally, apps may have to update how they request location permissions based on the app’s target API level.
CODE CHANGES REGARDING PERMISSION REQUESTS
Android 12 introduces an updated runtime dialog for requesting location permissions that allows the user to decide whether to grant the app ACCESS_FINE_LOCATION (precise) or ACCESS_COARSE_LOCATION (approximate).
For this reason, if your app targets API level 31 or higher and you request ACCESS_FINE_LOCATION you must also request ACCESS_COARSE_LOCATION. 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.
This dialog allows the user to select the location duration category (While using the app, Only this time, Deny) and the location accuracy permissions to grant the app. (the buttons have visual cues informing the user about the accuracy of your app requests). Users will still be able to update these permissions by going in the Apps section of their phone settings. (Note that 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.)
CHECKING LOCATION PERMISSIONS
All apps running on Android 12 must now check both the duration category and accuracy permissions granted by the user, which is true even if the app doesn’t target Android 12 (API level 31). The updated permissions matrix is below:
Android 12 Permission Options Summary
While Android’s developer docs suggest you can fulfill most use cases even when you have access to only approximate location information, some use cases require the user’s precise location. If precise location information is necessary (navigation/map, rideshare apps), an app can check if it has been granted precise location permission by using the following code:
if (ContextCompat.checkSelfPermission(activity, Manifest.permission.ACCESS_FINE_LOCATION) == PackageManager.PERMISSION_GRANTED)) {
// Get precise location (FusedLocationProviderClient)
} else {
// Fallback
}
On our Pilgrim SDK, some of our services require us to access the user’s precise location, and, accordingly, we have made the necessary updates to our SDK to be ready for Android 12. Access involves mainly checking for required permissions, as shown above. However, as an SDK, we do not request these permissions from the user; apps integrating our framework must do this. For City Guide, which integrates Pilgrim, we include additional onboarding location option screens explaining our precise location permission rationale to the user.
ACCESSING ADVERTISING ID
Another privacy feature that rolled out with Android 12 is a Google Play services update that affects how apps can access the advertising ID. For background, the advertising ID is a unique, user-resettable ID that uniquely identifies a particular user for use cases such as ad personalization, attribution, and fraud prevention. Starting from late 2021, on Android 12 devices, when users opt-out of interest-based advertising or ads personalization, the returned value of the advertising ID will be 00000000-0000-0000-0000-000000000000 regardless of the app’s target SDK level. Users can opt-out of interest-based advertising or ads personalization in the Android settings and have since 2013.
However, now the advertising ID will be zeroed out and unusable after the user has opted out. Additionally, apps targeting 31 or higher will need to declare a Google Play services permission in their manifest to access the advertising ID using the Advertising ID API. This update will affect all apps running on devices that support Google Play in early 2022.
KEY ANDROID TIPS & Data Privacy TAKEAWAYS FOR DEVELOPERS
Android 12 takes significant steps toward increasing user data privacy by allowing users to control how their precise location and advertising ID are shared with apps. As you go through the process of updating your apps, I suggest you keep the following in mind:
- Update location permission code: Ensure you update how your app checks if the user has granted precise location permission as shown above. All apps running on Android 12, even apps not targeting 31, will need to update this code. If your app targets 31 then also update your permission requests like above and make sure to include both ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION
- Test it out: Test how your app handles approximate location following the guidelines provided by the Android developer docs.
- Be transparent: Provide your users with transparent explanations of what value your add apps by requiring their precise location. Make sure to communicate this effectively through upsells and onboarding interfaces. We also ran experiments on these screens to determine the ideal flow and copy that educates the user while increasing the likelihood of granting the needed permissions.
Check out our Developer Blog or reach out to Foursquare’s experts using the form below to learn more tips for adapting to new Android and iOS features.
