android - Google 地理围栏未按预期在某些设备上触发

Question

目前我正在开发一个应用程序来跟踪最终用户的 Action 以相应地进行一些操作。就像最终用户进入某些地理围栏区域时，会弹出一个通知，告诉他们一些与该地点相关的信息。
在像“谷歌像素”系列这样的手机中，大部分时间一切正常。顺便说一句，有时会有明显的延迟。
但在三星制造的设备中，即使最终用户位于地理围栏区域的中心，进入或退出地理围栏也不会按预期触发。此外，在从“FusedLocationProviderClient”接收到位置更新后，我在日志控制台中打印当前位置。我的位置显示我现在正处于地理围栏中。
但是当最终用户关闭并打开 wifi 时，就会触发地理围栏事件。这个技巧大部分时间都可以完成这项工作。
以下是我的问题:

有没有办法让我们调试地理围栏功能？这样我们就可以知道到底发生了什么。

你们能解释一下地理围栏功能是如何工作的吗？更多细节将使我们免于黑洞。谢谢。

有人可以为我提供有关地理围栏问题的 Google 支持团队的电话号码吗？

Answer 1

为了帮助遇到同样问题的其他人，我想与你们分享伟大的谷歌团队的回应。

Possible Cause

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

So we added some defensive mechanism on the Geofencer's side toprotect Geofencer from receiving false location results. When a deviceis still, and if the device has an active Wi-Fi connection, we stoplocation requests, and ignore any location results if the accuracy wasnot high enough. When the Wi-Fi connectivity changes, either a newWi-Fi connection is established, or the device loses Wi-Ficonnectivity, or the device roams between different access pointswithin the same Wi-Fi network, Geofencer will send an immediatelocation request to detect if the device just entered or exited aGeofence.

What to Expect

Because when a device has Wi-Fi connectivity, we don't sample devicelocation when the device is still. That means if we add a new Geofencearound the user's current location, we won't be able to receive ENTERevent until the user starts walking around with the device (no longerstill), or the Wi-Fi connectivity changes (either disconnected, orroaming). If the user stays at the same place for a long time, wewould 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 shouldalways in "moving" state. In another word, we shouldn't expect aGeofencing event to be triggered when the device is still. If we wantto force triggering Geofencing event when the device is still,toggling Wi-Fi off and back on would be a work around for debuggingpurpose.

Why Samsung Devices Are Doing Worse?

To summarize, when the device is still and has active Wi-Ficonnectivity, Geofencer will stop sampling device location actively,and we would expect newly added Geofences to have much longer delayfor the initial event. However, according to your company, some devices canstill get Geofencing events. The reason behind that is, we may havesome other apps running on the device that also request for locationoccasionally. Although Geofencer doesn't request for location, it canstill consume the passive location results requested by other apps ifthe 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 theother mobile devices. We asked for a bugreport from your company. And from thebugreport, we observed that when the device was moving, FLP locationresults were quite accurate. The accuracy circle was usually below 15meters:

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 wasrequested, the accuracy circle became much larger. Usually more than30 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 willsimply 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 usecases. When a user enters or exits a Geofence, the device shouldalways have movement. Also, when the user enters or exits home orworkplace, a Wi-Fi connectivity change is quite likely to happen,which can lead to an immediate location request and trigger thecorresponding Geofence shortly. So we do not need to do anythingspecial to work around this problem on production devices, even forSamsung. The only problem is the initial events for newly addedGeofences. If the client app cares about those events, and can'ttolerate the initial delay, the client app can request for locationitself to detect if it's inside any newly added Geofences.

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

Possible Future Changes on Geofencer's Side

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

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