Android Q Labs| Android Q 地理位置权限变动

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

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 地理位置权限变动的好处

Android Q SDK有一大好处，就是说你能够根据你的 app 的使用状况，还有你所须要的范围来申请这个位置权限。比方说你的 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。

Android Q 地理位置权限变动总结

• 第一点，请你们只在须要的时候申请地理位置信息权限。由于每申请你每次接触到地理位置权限的时候，你的应用都须要给用户一个弹框，而后对于用户来讲，固然你是但愿越少弹框越好。因此说若是你不须要的时候，请不要申请地理位置权限。

• 第二点是但愿仅申请须要的地理位置权限。由于咱们刚刚提到有不少个等级的地理位置，权限有 COARSE-LOCATION 和 FINE-LOCATION，有前台的也有后台的，请你们仔细考虑一下，你的用例到底是一个什么样的场景，而后只申请你须要的等级。

• 第三点就是关于申请的问题了，可能有一些开发者会以为若是在个人代码里面找到全部的我须要使用地理位置权限的点有太多又太复杂，我干脆就直接在应用第一次开启，或者是找一个就是统一的时间点一口气把全部的权限都申请完，对我来讲很省事，一些代码就放在一个地方就行了。但实际上这对用户来讲他是比较困扰的，由于他甚至都不知道你的应用要作什么，他就已经看到你再要求一些很是对他来讲很隐私很涉及安全性的一些权限了。因此咱们但愿尽可能大家把这些权限的申请放在有一个上下文的环境里面。 比方说你是一个外卖 App，你须要获取用户的地址来给他送外卖，在这个过程以前，咱们就但愿你不要就赶快把 COARSE-LOCATION 和 FINE-LOCATION 都申请了，只在就是用户进入到他填写地址那一步，再弹出申请 COARSE-LOCATION和FINE-LOCATION 弹框。

• 第四点是但愿你们用一个渐进式的方式去申请 location，也就是说咱们刚刚最开始提到的，若是你的 App 在此刻只须要申请前台的地理位置权限就能够知足你的需求，那就请把后台地理位置权限留到后面，等你真正须要的时候再去申请。

最后一点其实也是最重要的一点，但愿开发者在写全部须要地理位置权限的代码这一块，注意检查一下你如今的 Locaiton 等级是什么？由于如今有三个等级，你须要看一看你是否是已经有了你须要的 Location Permission，并且最重要的一点是，若是你没有你须要的 Location Permission，那是否是能够考虑一下有一个备用方案是否是你的 App 真的就是真的运行不了。由于就像我刚刚说的外卖 App，若是说用户在填写他地址的时候，你的 App 弹框问用户要地理位置权限，用户说我不给，其实用户也能够按照他本身的地理地理位置他本身去填写，他从省市直接选到街道，他能够本身去填写，他未必须要你定位，而后你帮他去找地理位置。

Android Q Labs 直播专题页面

Android Q Labs 开场演讲

Android Q 有哪些更新

Android Q 现代化您的应用

后台 Activity 启动的限制

Android Q 分区存储

Android Q 手势导航

Jetpack 更新

Android Q 在折叠屏设备的适配

通用系统映像介绍

Google Play 商店政策

Android Q 深色主题

Android Q Labs 总结演讲