Google Geofence Not triggered On Some Devices as expected

Question

At present i am developing an app to track end users' movement to do some operation accordingly. Like when end users enter some geofence areas, a notification would pop up to tell them some info relate to that spot.

In these phones like "Google pixel" series, everything works fine most of time. By the way, sometimes there is a noticeable latency.

But in the devices manufactured by Samsung, the entering or exiting geofence would not be triggered as expect even though end users stay in the center of the geofence area. Moreover, i print the current location in the log console after receiving the location update from "FusedLocationProviderClient". And my location shows i am in the geofence right now at the very moment.

But when end users turn off and on the wifi, the geofence event is triggered. This trick would do the job most of time.

Here are my questions:

1. Is there a way for us to debug the geofence feature ? So we could know what's really happened.

2. Could you guys please explain how the geofence functionality work? More details would save us from the black hole. Thanks.

3. Could someone please provide me with a phone number of Google support team for the geofence issue?

Answer 1

In order to help others who encountered the same issue, i would like to share with you guys the response from the great google team.

Possible Cause

In the past, some mobile OEMs did some over-aggressive optimization to reduce the power consumption, and broke the location stack. Such optimization usually kicked in when the device was still, and caused Geofencer to receive a wrong location, which then led to a false EXIT event. And later on, a correct location result would trigger another ENTER result. Such kind of location jumping and Geofencing event spamming broke many essential Geofencer-based use cases.

So we added some defensive mechanism on the Geofencer's side to protect Geofencer from receiving false location results. When a device is still, and if the device has an active Wi-Fi connection, we stop location requests, and ignore any location results if the accuracy was not high enough. When the Wi-Fi connectivity changes, either a new Wi-Fi connection is established, or the device loses Wi-Fi connectivity, or the device roams between different access points within the same Wi-Fi network, Geofencer will send an immediate location request to detect if the device just entered or exited a Geofence.

What to Expect

Because when a device has Wi-Fi connectivity, we don't sample device location when the device is still. That means if we add a new Geofence around the user's current location, we won't be able to receive ENTER event until the user starts walking around with the device (no longer still), or the Wi-Fi connectivity changes (either disconnected, or roaming). If the user stays at the same place for a long time, we would expect the initial ENTER event be delayed.

Usually such drawback is not a problem for real life use cases. Because when the user enters or exits a Geofence, the device should always in "moving" state. In another word, we shouldn't expect a Geofencing event to be triggered when the device is still. If we want to force triggering Geofencing event when the device is still, toggling Wi-Fi off and back on would be a work around for debugging purpose.

Why Samsung Devices Are Doing Worse?

To summarize, when the device is still and has active Wi-Fi connectivity, Geofencer will stop sampling device location actively, and we would expect newly added Geofences to have much longer delay for the initial event. However, according to your company, some devices can still get Geofencing events. The reason behind that is, we may have some other apps running on the device that also request for location occasionally. Although Geofencer doesn't request for location, it can still consume the passive location results requested by other apps if the location results are considered to be "precise enough".

We'd expect the behavior consistent across all phone models. However, according to your company, Samsung devices seem to have more problems than the other mobile devices. We asked for a bugreport from your company. And from the bugreport, we observed that when the device was moving, FLP location results were quite accurate. The accuracy circle was usually below 15 meters:

08-17 14:29:39 location=Location[fused lat,lng hAcc=13 ]
08-17 14:30:01 location=Location[fused lat,lng hAcc=15 ]
08-17 14:31:39 location=Location[fused lat,lng hAcc=14 ]
08-17 14:32:07 location=Location[fused lat,lng hAcc=14 ]
08-17 14:33:39 location=Location[fused lat,lng hAcc=14 ]
08-17 14:34:02 location=Location[fused lat,lng hAcc=14 ]
08-17 14:34:23 location=Location[fused lat,lng hAcc=14 ]
08-17 14:34:43 location=Location[fused lat,lng hAcc=13 ]
08-17 14:35:39 location=Location[fused lat,lng hAcc=14 ]
08-17 14:36:02 location=Location[fused lat,lng hAcc=13 ]

But when the device became still for a while, and when location was requested, the accuracy circle became much larger. Usually more than 30 meters, sometimes larger than 40 meters:

08-17 17:14:18 location=Location[fused lat,lng hAcc=43 ]
08-17 17:15:13 location=Location[fused lat,lng hAcc=43 ]
08-17 17:15:18 location=Location[fused lat,lng hAcc=43 ]
08-17 17:17:18 location=Location[fused lat,lng hAcc=43 ]
08-17 17:19:18 location=Location[fused lat,lng hAcc=43 ]
08-17 17:21:24 location=Location[fused lat,lng hAcc=43 ]
08-17 17:21:56 location=Location[fused lat,lng hAcc=43 ]

And:

08-17 17:24:45 location=Location[fused lat,lng hAcc=39 ]
08-17 17:27:27 location=Location[fused lat,lng hAcc=39 ]
08-17 17:28:11 location=Location[fused lat,lng hAcc=39 ]
08-17 17:32:03 location=Location[fused lat,lng hAcc=39 ]
08-17 17:34:10 location=Location[fused lat,lng hAcc=39 ]
08-17 17:38:11 location=Location[fused lat,lng hAcc=39 ]

When the passive locations are not accurate enough, Geofencer will simply drop them, and won't use them to calculate Geofencing events. We don't see similar behavior on devices from other manufacturers.

How to Work Around the Problem?

As we described before, usually it's not a problem for real life use cases. When a user enters or exits a Geofence, the device should always have movement. Also, when the user enters or exits home or workplace, a Wi-Fi connectivity change is quite likely to happen, which can lead to an immediate location request and trigger the corresponding Geofence shortly. So we do not need to do anything special to work around this problem on production devices, even for Samsung. The only problem is the initial events for newly added Geofences. If the client app cares about those events, and can't tolerate the initial delay, the client app can request for location itself to detect if it's inside any newly added Geofences.

When doing debugging, it's quite likely that the debugging device is still, and has active Wi-Fi connection. So the Wi-Fi toggling trick can help a lot. Another advantage for this trick is, when using mock location to debug Geofencing client apps, Geofencer usually rejects mock location. Using the Wi-Fi toggling trick and force Geofencer to consume the mock location.

Possible Future Changes on Geofencer's Side

Not being able to trigger initial Geofencing events would be a problem for some use cases. We may update Geofencer to allow initial Geofencing events to be triggered properly even if the device is still. So in the future we may no longer need to request location on the client app's side to calculate initial events.

However, being able to trigger initial Geofencing events doesn't mean that initial Geofencing events will always be triggered immediately. In order to avoid requesting location at an excessive rate, we will never request location immediately when a new Geofence is added. Instead, we'll only schedule location requests at a throttled rate. So a few minutes of delay to the initial Geofencing events would still be expected, even after our future upgrade.