问题描述
在 the docs 中，FusedLocationProviderClient.getCurrentLocation() 的内容如下：
此方法可能会返回几秒钟前的位置，但永远不会返回更旧的位置。这适用于需要单个新当前位置的前台应用程序。
调用此方法的后台应用程序将在后台位置限制下受到限制，因此后台应用程序可能会发现该方法更频繁地返回空位置。
“将被限制”的含义是什么？
在我的情况下，我有一个最多每 30 分钟更新一次的小部件。授予适当的位置权限（前台和后台）后，我已经可以使用 FusedLocationProviderClient.getLastLocation() 访问最后一个已知位置，并且运行良好。
但我想探索一种更积极的方法，使用 getCurrentLocation() 而不是 getLastLocation()。对于前台没有应用程序的小部件，即使将 LocationRequest.PRIORITY_HIGH_ACCURACY 传递给 getCurrentLocation()，我也从未看到状态栏中出现小“位置”图标（地图图钉图标），正如我所期望的如果设备正在主动请求新的位置修复。是的，已请求并授予 ACCESS_FINE_LOCATION 权限。在应用程序中（在前台）使用相同的方法调用，我确实看到了“位置”图标。
那么，对于小部件来说，如果它会以某种方式受到严重阻碍，那么在后台使用 getCurrentLocation() 而不是 getLastLocation() 有什么真正的好处吗？有时它似乎需要大约 30 秒才能完成（在任何位置访问的状态栏中都没有可见的标志）然后返回一个 null 位置，那么它实际上在做什么？
我可以启动一个前台服务（带通知），但如果用户无论如何都要看到（通过状态栏中的“位置”图标）该位置正在被主动访问，这似乎有点矫枉过正。
那么“节流”究竟是什么？只是限制频率（小部件最多每 30 分钟更新一次，所以它几乎不“频繁”）？或者限制准确性（例如没有 GPS）？
解决方法
我认为可能与这些background location limits有关：
为了降低功耗，Android 8.0（API 级别 26）限制了应用在后台运行时检索用户当前位置的频率。在这种情况下，应用每小时只能接收几次位置更新。