目前我正在开发一个应用程序来跟踪最终用户的 Action 以相应地进行一些操作。就像最终用户进入某些地理围栏区域时，会弹出一个通知，告诉他们一些与该地点相关的信息。
在像“谷歌像素”系列这样的手机中，大部分时间一切正常。顺便说一句，有时会有明显的延迟。
但在三星制造的设备中，即使最终用户位于地理围栏区域的中心，进入或退出地理围栏也不会按预期触发。此外，在从“FusedLocationProviderClient”接收到位置更新后，我在日志控制台中打印当前位置。我的位置显示我现在正处于地理围栏中。
但是当最终用户关闭并打开 wifi 时，就会触发地理围栏事件。这个技巧大部分时间都可以完成这项工作。
以下是我的问题:
最佳答案
为了帮助遇到同样问题的其他人，我想与你们分享伟大的谷歌团队的回应。
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.
关于android - Google 地理围栏未按预期在某些设备上触发，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/63263033/