FusedLocationProviderClient的isLocationAvailable恒为false但定位正常，能否忽略？

核心结论 #

1. 可以忽略isLocationAvailable = false的状态，直接使用onLocationResult返回的定位结果，该异常属于FusedLocationProvider的已知接口误报，不是业务逻辑问题。
2. 只要在onLocationResult中做好常规的位置有效性校验，就不会出现错误定位、低精度定位的额外风险。
3. 该问题确实是近年FusedLocation系统内部逻辑变更导致的，2022年之后Google Play服务的FusedLocationProvider模块多次调整后，多个版本都存在该回调异常的bug，尤其在使用PRIORITY_BALANCED_POWER_ACCURACY优先级时容易复现。

具体说明 #

你已经完成了权限申请、定位设置前置校验的必要步骤，且实际测试中所有配置下都能拿到符合精度要求的定位结果，足以证明定位链路本身是正常的。isLocationAvailable的设计初衷是提前告知应用定位模块可用性，但现在的异常返回不影响实际定位结果的有效性。

优化建议 #

• 放弃依赖onLocationAvailability的返回值判断定位可用性，你已经做的LocationSettingsRequest前置检查结果比该回调的返回可信度更高。
• 在onLocationResult中增加常规的位置有效性校验逻辑即可，参考代码如下：

val locationCallback = object : LocationCallback() {
    override fun onLocationResult(locationResult: LocationResult?) {
        locationResult ?: return
        if (locationResult.locations.isEmpty()) return
        val location = locationResult.locations[0]
        // 校验位置时间戳是否新鲜，可根据业务调整有效期阈值
        val isLocationFresh = System.currentTimeMillis() - location.time < 10 * 60 * 1000
        // 校验位置精度是否符合业务要求，可根据需求调整精度阈值
        val isAccuracyQualified = location.hasAccuracy() && location.accuracy < 100
        if (isLocationFresh && isAccuracyQualified) {
            // 业务逻辑使用该位置
        }
    }
}

• 如果你需要消除该异常告警，可以尝试将LocationRequest的优先级修改为PRIORITY_HIGH_ACCURACY，绝大多数机型在该优先级下不会触发该bug，代价是会轻微增加设备功耗。

内容的提问来源于stack exchange，提问作者Christian