PermissionX 1.5发布，支持申请Android特殊权限啦
前言
Hello 大家早上好，说起 PermissionX，其实我已经有段时间没有更新这个框架了。一是因为现在工作确实比较忙，没有过去那么多的闲暇时间来写开源项目，二是因为，PermissionX 的主体功能已经相当稳定，并不需要频繁对其进行变更。
不过之前一直有朋友在反映，对于 Android 中的一些特殊权限申请，PermissionX 并不支持。是的，PermissionX 本质上只是对 Android 运行时权限 API 进行了一层封装，用于简化运行时权限申请的。而这些特殊权限并不属于 Android 运行时权限的一部分，所以 PermissionX 自然也是不支持的。
但是特殊权限却是我们这些开发者们可能经常要与之打交道的一部分，它们并不难写，但是每次去写都感觉很繁琐。因此经慎重考虑之后，我决定将几个比较常用的特殊权限纳入 PermissionX 的支持范围。那么本篇文章我们就来看一看，对于这几个常见的特殊权限，使用 PermissionX 和不使用 PermissionX 的写法有什么不同之处。
事实上，Android 的权限机制也是经历过长久的迭代的。在 6.0 系统之前，Google 将权限机制设计的比较简单，你的应用程序需要用到什么权限，只需要在 AndroidManifest.xml 文件中声明一下就可以了。
但是从 6.0 系统开始，Android 引入了运行时权限机制。Android 将常用的权限大致归成了几类，一类是普通权限，一类是危险权限，一类是特殊权限。
普通权限指的是那些不会直接威胁到用户的安全和隐私的权限，这种权限和过去一样，只需要在 AndroidManifest.xml 文件中声明一下就可以了，不需要做任何特殊处理。
危险权限则表示那些可能会触及用户隐私或者对设备安全性造成影响的权限，如获取设备联系人信息、定位设备的地理位置等。这部分权限需要通过代码进行申请，并要用户手动同意才可获得授权。PermissionX 库主要就是处理的这种权限的申请。
而特殊权限则更加少见，Google 认为这种权限比危险权限还要敏感，因此不能仅仅让用户手动同意就可以获得授权，而是需要让用户到专门的设置页面去手动对某一个应用程序授权，该程序才能使用这个权限。
不过相比于危险权限，特殊权限没有非常固定的申请方式，每个特殊权限可能都要使用不同的写法才行，这也导致申请特殊权限比申请危险权限还要繁琐。
从 1.5.0 版本开始，PermissionX 对最常用的几个特殊权限进行了支持。正如刚才所说，特殊权限没有固定的申请方式，因此 PermissionX 也是针对于这几个特殊权限一个一个去适配并支持的。如果你发现你需要申请的某个特殊权限还没有被 PermissionX 支持，也可以向我提出需求，我会考虑在接下来的版本中加入。
在过去，我们发布开源库通常都是发布到 jcenter 上的，但是相信大家现在都已经知道了，jcenter 即将停止服务，具体可以参考我的这篇文章 浅谈 JCenter 即将被停止服务的事件 。
目前的 jcenter 处在一个半废弃的边缘，虽然还可以正常从 jcenter 下载开源库，但是已经不能再向 jcenter 发布新的开源库了。而在明年 2 月 1 号之后，下载服务也会被关停。
所以，以后要想再发布开源库我们只能选择发布到其他仓库，比如现在 Google 推荐我们使用 Maven Central。
于是，从 1.5.0 版本开始，PermissionX 也会将库发布到 Maven Center 上，之前的老版本由于迁移价值并不大，所以我也不想再耗费经历做迁移了。1.5.0 之前的版本仍然保留在 jcenter 上，提供下载服务直到明年的 2 月 1 号。
而关于如何将库发布到 Maven Central，请参考 再见 JCenter，将你的开源库发布到 MavenCentral 上吧 。
Android的特殊权限
Android 里具体有哪些特殊权限呢？
说实话，这个我也不太清楚。我所了解的特殊权限基本都是因为需要用到了，然后发现这个权限即不属于普通权限，也不属于危险权限，要用一种更加特殊的方式去申请，才知道原来这是一个特殊权限。
因此，PermissionX 1.5.0 版本中对特殊权限的支持，也就仅限于我知道的，以及从网友反馈得来的几个最为常用的特殊权限。
一共是以下 3 个：
- 悬浮窗
- 修改设置
- 管理外部存储
接下来我就分别针对这 3 个特殊权限做一下更加详细的介绍。
悬浮窗
悬浮窗功能在不少应用程序中使用得非常频繁，因为你可能总有一些内容是要置顶于其他内容之上显示的，这个时候用悬浮窗来实现就会非常方便。
当然，如果你只是在自己的应用内部实现悬浮窗功能是不需要申请权限的，但如果你的悬浮窗希望也能置顶于其他应用程序的上方，这就必须得要申请权限了。
悬浮窗的权限名叫做 SYSTEM_ALERT_WINDOW，如果你去查一下这个权限的文档，会发现这个权限的申请方式比较特殊：
按照文档上的说法，从 Android 6.0 系统开始，我们在使用 SYSTEM_ALERT_WINDOW 权限前需要发出一个 action 为 Settings.ACTION_MANAGE_OVERLAY_PERMISSION 的 Intent，引导用户手动授权。另外我们还可以通过 Settings.canDrawOverlays() 这个 API 来判断用户是否已经授权。
因此，想要申请悬浮窗权限，自然而然就可以写出以下代码：
if (Build.VERSION.SDK_INT >= 23) {
if (Settings.canDrawOverlays(context)) {
showFloatView()
} else {
val intent = Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION)
startActivity(intent)
}
} else {
showFloatView()
}
看上去也不复杂嘛。
确实，但是它麻烦的点主要在于，它的请求方式是脱离于一般运行时权限的请求方式的，因此得要为它额外编写独立的权限请求逻辑才行。
而 PermissionX 的目标就是要弱化这种独立的权限请求逻辑，减少差异化代码编写，争取使用同一套 API 来实现对特殊权限的请求。
如果你已经比较熟悉 PermissionX 的用法了，那么以下代码你一定不会陌生：
PermissionX.init(activity)
.permissions(Manifest.permission.SYSTEM_ALERT_WINDOW)
.onExplainRequestReason { scope, deniedList ->
val message = "PermissionX需要您同意以下权限才能正常使用"
scope.showRequestReasonDialog(deniedList, message, "Allow", "Deny")
}
.request { allGranted, grantedList, deniedList ->
if (allGranted) {
Toast.makeText(activity, "所有申请的权限都已通过", Toast.LENGTH_SHORT).show()
} else {
Toast.makeText(activity, "您拒绝了如下权限：$deniedList", Toast.LENGTH_SHORT).show()
}
}
可以看到，这就是最标准的 PermissionX 的正常用法，但是我们在这里却用来请求了悬浮窗权限。也就是说，即使是特殊权限，在 PermissionX 中也可以用普通的方式去处理。
另外不要忘记，所有申请的权限都必须在 AndroidManifest.xml 进行注册才行：
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.permissionx.app">
<uses-permission android: />
</manifest>
那么运行效果是什么样的呢？我们来看看吧：
可以看到，PermissionX 还自带了一个权限提示框，友好地告知用户我们需要悬浮窗权限，引导用户去手动开启。
修改设置
了解了悬浮窗权限的请求方式之后，接下来我们就可以快速过一下修改设置权限的请求方式了，因为它们的用法是完全一样的。
修改设置的权限名叫 WRITE_SETTINGS，如果我们去查看一下它的文档，你会发现它和刚才悬浮窗权限的文档简直如出一辙：
同样是从 Android 6.0 系统开始，在使用 WRITE_SETTINGS 权限前需要先发出一个 action 为 Settings.ACTION_MANAGE_WRITE_SETTINGS 的 Intent，引导用户手动授权。然后我们还可以通过 Settings.System.canWrite() 这个 API 来判断用户是否已经授权。
所以，如果是自己手动申请这个权限，相信你已经知道要怎么写了。
那么用 PermissionX 申请的话应该要怎么写呢？这个当然就更简单了，只需要把要申请的权限替换一下即可，其他部分都不用作修改：
PermissionX.init(activity)
.permissions(Manifest.permission.WRITE_SETTINGS)
...
当然，不要忘记在 AndroidManifest.xml 中注册权限：
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.permissionx.app">
<uses-permission android: />
</manifest>
运行一下，效果如下图所示：
管理外部存储
管理外部存储权限也是一种特殊权限，它可以允许你的 App 拥有对整个 SD 卡进行读写的权限。
有些朋友可能会问，SD 卡本来不就是可以全局读写的吗？为什么还要再申请这个权限？
那你一定是没有了解 Android 11 上的 Scoped Storage 功能。从 Android 11 开始，Android 系统强制启用了 Scoped Storage，所有 App 都不再拥有对 SD 卡进行全局读写的权限了。
关于 Scoped Storage 的更多内容，可以参考我的这篇文章 Android 11 新特性，Scoped Storage 又有了新花样 。
但是如果有的应用就是要对 SD 卡进行全局读写该怎么办呢（比如说文件浏览器）？
不用担心，Google 仍然还是给了我们一种解决方案，那就是请求管理外部存储权限。
这个权限是 Android 11 中新增的，为的就是应对这种特殊场景。
那么这个权限要怎么申请呢？我们还是先来看一看文档：
大致可以分为几步吧：
第一，在 AndroidManifest.xml 中声明 MANAGE_EXTERNAL_STORAGE 权限。
第二，发出一个 action 为 Settings.ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION 的 Intent，引导用户手动授权。
第三，调用 Environment.isExternalStorageManager() 来判断用户是否已授权。
传统请求权限的写法我就不再演示了，使用 PermissionX 来请求的写法仍然也还是差不多的。只不过要注意，因为 MANAGE_EXTERNAL_STORAGE 权限是 Android 11 系统新加入的，所以我们也只应该在 Android 11 以上系统去请求这个权限，代码如下所示：
if (Build.VERSION.SDK_INT >= 30) {
PermissionX.init(this)
.permissions(Manifest.permission.MANAGE_EXTERNAL_STORAGE)
...
}
AndroidManifest.xml 中的权限如下：
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.permissionx.app">
<uses-permission android: />
</manifest>
运行一下程序，效果如下图所示：
这样我们就拥有全局读写 SD 卡的权限了。
另外 PermissionX 还有一个特别方便的地方，就是它可以一次性申请多个权限。假如我们想要同时申请悬浮窗权限和修改设置权限，只需要这样写就可以了：
PermissionX.init(activity)
.permissions(Manifest.permission.SYSTEM_ALERT_WINDOW, Manifest.permission.WRITE_SETTINGS)
...
运行效果如下图所示：
当然你也可以将特殊权限与普通运行时权限放在一起申请，PermissionX 对此也是支持的。只有当所有权限都请求结束时，PermissionX 才会将所有权限的请求结果一次性回调给开发者。
关于 PermissionX 新版本的内容变化就介绍到这里，升级的方式非常简单，修改一下 dependencies 当中的版本号即可：
repositories {
google()
mavenCentral()
}
dependencies {
implementation 'com.guolindev.permissionx:permissionx:1.5.0'
}
注意现在一定要使用 mavenCentral 仓库，而不能再使用 jcenter 了。
如果你对 PermissionX 的源码感兴趣，可以访问 PermissionX 的项目主页：
