How does ACCESS_BACKGROUND_LOCATION introduced in Android Q affect Geofence APIs?

Question

In order to use the Geofence API the user has to give the app ACCESS_FINE_LOCATION. This location is considered to be dangerous and can be revoked at any time; once this permission is revoked, the app can not request the geofence updates.

How does ACCESS_BACKGROUND_LOCATION permission fit in this picture? We know for sure that this permission is also dangerous and can be revoked at any time. Does it mean that if we want to register some IntentService to be invoked every time the geofence change occurs, we also have to make sure the user has provided ACCESS_BACKGROUND_LOCATION permission? Or do we need to use this permission only if we attempt to get a current location in our own background Service/BroadcastReceiver?

The reason I'm asking this question is that the documentation seems to be a bit vague at this point: the documentation describing the Q Developer Preview mentions that geofencing is one of the use cases for the background location retrieval, while the Geofencing API page does not mention ACCESS_BACKGROUND_LOCATION among its requirements.

Answer 1

Geofencing API Documentation is now updated and we need to define ACCESS_BACKGROUND_LOCATION to monitor Geofences if we target Android Q

From the doc:

To use geofencing, your app must request ACCESS_FINE_LOCATION. If your app targets Android 10 (API level 29) or higher, your app must also request ACCESS_BACKGROUND_LOCATION.

Answer 2

My guess the section "Re-register geofences only when required":

Registered geofences are kept in the com.google.process.location process owned by the com.google.android.gms package.

will be that it is not really needed, as com.google.process.location should be the one getting the location data (so the one needing to request the ACCESS_BACKGROUND_LOCATION permission).

That being said, following this logic ACCESS_FINE_LOCATION permission should neither be needed. The fact that it is needed may be because of two reasons (I don't know the real reason):

• that either when registering the geofence or when receiving a notification location is checked,
• or that this permission is checked by Google Play Services to forbid an app to circumvent the lack of location permission by using Play Services as a proxy process to obtain the information.

For me, the second assumption makes more sense, meaning that even when technically will not be needed by the app (the process getting the location is Play Service), it is required for privacy/security reasons.

Following this logic, Google should (will?) also enforce the ACCESS_BACKGROUND_LOCATION, both to ensure user's privacy/security and to reduce battery consumption.

Answer 3

On beta 4, adding a geofence when ACCESS_BACKGROUND_LOCATION is not granted, even when the app is fully in the foreground, fails with status code 13 ("error").