Android Q 地理位置权限变更

说到地理位置，大家应该就是非常熟悉了，不管是你的应用需要最简单的定位，还是通过一些用户所在的位置信息去做一些更高级的功能，比方说给用户推荐附近的餐厅，或是帮用户寻找附近的好友，还有景点等等这些功能，你都会不可避免地需要用到地理位置权限。

在 Android Q 之前，也就是 Android P 或者更早的版本，如果你的 APP 需要一个地理位置权限的话，用户就会看到这样的一个弹窗出来，然后用户基本上就只有两个选项：允许或者拒绝。如果用户点击允许的话，那么你的 APP 是可以同时获得前台和后台的地理位置权限的。也就是说在任何时间，被授权的 API 都可以获得手机的地理位置。

在 Android Q 中，最大的变化就是在地理位置权限这一块新增加了一个状态，这个状态叫做仅在使用该应用时允许。

应用正在被使用中，其实只有两种状态，一种就是应用有一个可以看见的 Activity，另一种就是有一个正在运行中的前台服务(Frontground service)。比方说这是一个地图的APP，用户如果打开了，就是处于一个可见的状态。然后用户选择一个地点，并且开始导航任务，而且之后就离开了地图应用。然而地图应用为了导航，它就开启了一个前台的导航服务，这个服务我们也可以说该地图 APP 正在被使用中，直到导航结束之前，在整个地图应用，我们都说他是在被使用中的。

在 Android Q 之前，如果你需要使用地理位置权限的话，你需要在 Android manifest 的文件里面添加一个 uses-permission 的申请。之前是有两种，COARSE-LOCATION和FINE-LOCATION。它们并没有前后台的区别，它们的唯一的区别就只是在精度上。COARSE-LOCATION大约只会精确到城市级，FINE-LOCATION能精确到手机提供的位置。

在 Android Q 版本上，依旧还是COARSE-LOCATION和FINE-LOCATION，如果你继续使用这两个，那你只能获得前台的使用位置权限；如果你需要更进一步在后台访问地理位置，需要新添加一个uses-permission，叫做ACCESS-BACKGROUND-LOCATION。值得注意的是只支持最新的Android Q，之前的版本都不兼容，如果说用户的 APP 给了你 Location Permission，你会自动获得BACKGROUND-LOCATION。

Android Q SDK有一大好处，就是说你可以根据你的app的使用情况，还有你所需要的范围来申请这个位置权限。比方说你的APP只需要在前台使用地理位置信息，你就可以显示这样的一个弹框给用户，然后用户可以很清楚看到下面那排小字写的是“只有当您使用该应用时，该应用才有权访问地理位置信息”。然后这对于用户会感觉更安全，因为之前的话他是没有这个选项，现在他有了使用中的保证之后，他可能会更加愿意把这个位置权限给到相对应的应用。

然后你也可以考虑渐进式地申请地理位置权限，比方说现在你看到的弹框，他就是在申请前台的地理位置权限，然后用户可以选择允许或者是拒绝。然后当你有一个特殊的用例，或者是有更进一步的用例，你需要用到后台的地理位置时，你可以再弹出一个新的框，问用户是不是要给你更多位置权限，你可以看到用户现在的选择就是变成一律允许或者是保持现有状态。

用地图 App 做一个例子：比方说我这个地图 App 的主要的功能是说在用户开启我的 App 时，显示周围地区的地理状况给用户。实际上我就可以考虑，我只在 App 开启的时候问用户，拿前台的地理位置权限。用户需要一个更高级的功能时，例如他需要在后台的时候，地图 App 还要给他推送实时交通状况，或是帮用户预计回家要花多长时间等功能。其实这些功能就不会在前台运行，而是在后台。比方说到了下午6点钟去拿一次用户的地理位置，然后帮他计算一下回家时间。如果说用户需要开启这些功能，或者是经过 App 的某一个推荐让他开启这个功能的时候，我地图的应用再去问这个用户拿后台的地理位置信息的权限就会显得合理很多，然后用户也会更愿意根据用例去给应用更高级的位置权限。

从 Android 6.0开始，因为位置权限作为比较隐私的权限，它已经在刚刚的 Android manifest 里面申请还不够，还需要动态地在代码里面去申请，然后 requestpermissions 就是说我们现在在 Android P 里面都会需要做的就 COARSE-LOCATION 和 FINE-LOCATION。

然后这一点在 Android Q 里面对于前台的地理位置权限是保持不变的，也就是说你的 App 只需要前台地理位置权限，你就是只需要在你的代码里写这样的一个 requestpermissions。如果说你需要后台地理位置权限的话，你需要再申请一个 ACCESS-BACKGROUND-LOCATION。

同时我们也建议你和 checkSelfPermission API结合起来使用，因为现在我们有了三个地理位置权限的状态，所以你需要去检查一下你现在的地理位置权限是什么等级，是根本没有，还是说你有前台，还是说你现在已经有了全市的地理位置权限的访问。

需要注意的是有一点你可能会问，如果说用户之前现在手上是 Android P 的手机，然后他这个手机通过 OEM 推送升级到了 Android Q，他手机上之前装的那些需要访问地理位置的这些应用会不会受到影响？答案是否定的。之前有地理位置权限访问的应用，它是会有前台和后台，因为是 Android P 到 Q 里面依旧会继承访问权限，依旧会有前台和后台的地理位置访问权限。如果没有的话就是没有。

还有一点是对于 Target Q 之前的 SDK version App 有特别大的影响，就是说 While-in-use permission 在系统的设置里面，其实用户是可以进到每一个 App 具体的 Location 设置页面，它可以选择把应用的后台或者整个 App 的 Permission 关掉。 如果说你的应用是 Target Q 之前的 SDK Level，如果用户又恰巧把你的后台的 Location Permission 关掉了的话，你的应用是没有办法通过API检测到改变，然后你也没有办法通过任何 API 去重新获得后台的地理位置权限。所以说如果你的应用是有非常重要的用例，一定要在后台使用地理位置的话，请一定要升级你的 Target Q 到 Q SDK Version，这样的话你才可以使用最新的这些 API 还有 Manifest Permission。

Foreground services

接下来我们想讲一下关于前台服务和最新的 Location Permission 的改变。

我们还是用地图的应用作为范例，可以看到用户如果在地图里面开始了一次导航之后，然后又离开了地图的应用，不管是去到别的APP里面，还是说把手机屏幕熄掉，这个地图的应用，他就会开始一个前台服务，也就是 Foreground service 来继续导航任务。

但需要注意的是，如果你的应用，也就是比方说我们刚刚那个例子里面的地图应用，它只有前台地理方位置访问的权限的话，它需要在它的前台服务里面添加一个新的 attribute，这个 attribute 是最新的 foregroundServiceLocationType="location"，它才可以在前台服务里面访问到地理位置信息。而且需要注意的是说 attribute 它是在 Q SDK 才有的，所以你的应用是需要用 Q 的 SDK 来编译，你不需要 target 。而且就算你的应用没有 target Q SDK 也会受到限制，你的 service 会在一定的情况下没有办法拿到这个 location。

Location reminder

用户的地理位置控制权，从之前只有 Yes 和 No，变成了有三个等级，并有了一个逐渐递进的过程。我们还增加了用户对于地理位置信息的这一块的透明度。

这个图就是我们会在新的 Android Q 里面给用户展示的一个关于地理位置使用状况的通知。My Train Commute 是一个APP的名字，可以看到这个 App 正在使用你的地理位置，此应用随时可以使用你的位置信息点按即可更改。

如果用户按了通知，会进到一个设置页面系统设置页面里面，可以让用户把应用的地理位置权限从全时(All all the time)改成仅在前台(Allow only while using the app)或者直接把整个权限 关掉(Deny)。

你可能会问这个通知他是在什么时候才会出现，他会不会说出现得很频繁，让用户觉得很烦。通知只会在以上两种情况同时满足的时候才出现，一个就是说应用它必须要有全时的地理位置权限，它既有前台也有后台的地理位置权限。还有它出现的时间点是在这个应用它进入了后台，并且第一次接收到 fine location 信息的时候，需要注意的是，如果说用户他去到系统设置里面，把应用的全时的地理位置权限改成了仅在前台，或者说直接关掉，然后又改回了全时，那么这个技术它是会被清零的，也就是说下一次能应用在后台收到第一个 fine location 的信息的时候，通知会再出现一次。

Best Practice

以上就是所有的 Android Q 里面关于地理位置权限的改变。我想给大家总结在 Android Q 里面的 Best Practice。

第一点，请大家只在需要的时候申请地理位置信息权限。因为每申请你每次接触到地理位置权限的时候，你的应用都需要给用户一个弹框，然后对于用户来说，当然你是希望越少弹框越好。所以说如果你不需要的时候，请不要申请地理位置权限。

第二点是希望仅申请需要的地理位置权限。因为我们刚刚提到有很多个等级的地理位置，权限有 COARSE-LOCATION 和 FINE-LOCATION，有前台的也有后台的，请大家仔细考虑一下，你的用例究竟是一个什么样的场景，然后只申请你需要的等级。 第三点就是关于申请的问题了，可能有一些开发者会觉得如果在我的代码里面找到所有的我需要使用地理位置权限的点有太多又太复杂，我干脆就直接在应用第一次开启，或者是找一个就是统一的时间点一口气把所有的权限都申请完，对我来说很省事，一些代码就放在一个地方就好了。但实际上这对用户来说他是比较困扰的，因为他甚至都不知道你的应用要做什么，他就已经看到你再要求一些非常对他来说很隐私很涉及安全性的一些权限了。所以我们希望尽量你们把这些权限的申请放在有一个上下文的环境里面。 比方说你是一个外卖 App，你需要获取用户的地址来给他送外卖，在这个过程之前，我们就希望你不要就赶快把 COARSE-LOCATION 和 FINE-LOCATION 都申请了，只在就是用户进入到他填写地址那一步，再弹出申请 COARSE-LOCATION和FINE-LOCATION 弹框。

第四点是希望大家用一个渐进式的方式去申请 location，也就是说我们刚刚最开始提到的，如果你的 App 在此刻只需要申请前台的地理位置权限就可以满足你的需求，那就请把后台地理位置权限留到后面，等你真正需要的时候再去申请。

最后一点其实也是最重要的一点，希望开发者在写所有需要地理位置权限的代码这一块，注意检查一下你现在的 Locaiton 等级是什么？因为现在有三个等级，你需要看一看你是不是已经有了你需要的 Location Permission，而且最重要的一点是，如果你没有你需要的 Location Permission，那是不是可以考虑一下有一个备用方案是不是你的 App 真的就是真的运行不了。因为就像我刚刚说的外卖 App，如果说用户在填写他地址的时候，你的 App 弹框问用户要地理位置权限，用户说我不给，其实用户也可以按照他自己的地理地理位置他自己去填写，他从省市直接选到街道，他可以自己去填写，他未必需要你定位，然后你帮他去找地理位置。

好，谢谢大家，今天这是所有的关于 location 的话题了。