背景
配合监管要求，针对APP用户获取管理权限做如下整改：

APP在首次启动页面对权限进行解释说明（包括解释权限的涵义以及说明使用权限的用途）
个人中心-设置，增加权限设置菜单，展示涉及获取的所有权限，以及展示当前开启/关闭状态
一切为了监管……
软件环境
Xcode11.2
Swift4.2
iOS13.2.2
开门见山，上代码
工具类：SystemPermissionMonitor.swift

检测相机权限
static func checkCamera() -> (Bool, AVAuthorizationStatus) {
let status = AVCaptureDevice.authorizationStatus(for: .video)
return (status == .authorized, status)
}

检测相册权限
// (iOS 8, *)
static func checkPhotoLibrary() -> (Bool, PHAuthorizationStatus) {
let status = PHPhotoLibrary.authorizationStatus()
return (status == .authorized, status)
}
// (iOS, introduced: 6.0, deprecated: 9.0, message: “Use PHAuthorizationStatus in the Photos framework instead”)
static func checkPhotoLibrary4oldVersion() -> (Bool, ALAuthorizationStatus) {
let status = ALAssetsLibrary.authorizationStatus()
let authorized = status == .authorized
return (authorized, status)
}

获取相册权限
static func openPhotoLibraryAlert() -> (Bool, PHAuthorizationStatus) {
let sema = DispatchSemaphore(value: 0)
var status: PHAuthorizationStatus = .notDetermined
PHPhotoLibrary.requestAuthorization { (authStatus) in
status = authStatus
sema.signal()
}
let _ = sema.wait(timeout: DispatchTime.distantFuture)
return (status == .authorized, status)
}

检测定位权限
static func checkLocation() -> (Bool, CLAuthorizationStatus) {
let status = CLLocationManager.authorizationStatus()
return (status == .authorizedAlways || status == .authorizedWhenInUse, status)
}

检测通知权限
static func checkNotification() -> (Bool, Any?) {
if #available(iOS 10.0, *) {
let sema = DispatchSemaphore(value: 0)
var status: UNAuthorizationStatus = .notDetermined
UNUserNotificationCenter.current().getNotificationSettings { (settings) in
status = settings.authorizationStatus
sema.signal()
}
let _ = sema.wait(timeout: DispatchTime.distantFuture)
return (status == .authorized, status)
} else {
let settings = UIApplication.shared.currentUserNotificationSettings
let types = settings?.types
let isEnabled = types == [.alert, .badge, .sound]
return (isEnabled, types)
}
}

ViewModel：SystemPermissionViewModel.swift

App需要用到的权限枚举
enum PermissionType: Int {
case PhotoLibrary
case Camera
case Location
case Notification
case Audio
case Others
}

实体
struct PermissionModel {
var name: String?
var status: Any?
var authorized: Bool = false
var permissionType: PermissionType = .Others
init(_ name: String?, permissionType: PermissionType) {
self.name = name
self.permissionType = permissionType
}
}

数据初始化
var permissionArray: [PermissionModel] = []
override func setup() {
super.setup()
let permissionNameArray = [“相册”,”相机”,”地理位置”,”通知”, “麦克风”, “其他”]
let permissionTypeArray: [PermissionType] = [.PhotoLibrary, .Camera, .Location, .Notification, .Audio, .Others]
permissionArray = []
for (i, name) in permissionNameArray.enumerated() {
let model = PermissionModel(name, permissionType: permissionTypeArray[i])
permissionArray.append(model)
}
// Check permission
checkPermission()
// Reload tableView
updateDataArray(permissionArray)
}

检测是否开启各权限
private func checkPermission() {
let (authorized4photoLibrary, status4photoLibrary) = SystemPermissionMonitor.checkPhotoLibrary()
filterPermissionArray(authorized4photoLibrary, status: status4photoLibrary, permissionType: .PhotoLibrary)

let (authorized4camera, status4camera) = SystemPermissionMonitor.checkCamera()
filterPermissionArray(authorized4camera, status: status4camera, permissionType: .Camera)

let (authorized4location, status4location) = SystemPermissionMonitor.checkLocation()
filterPermissionArray(authorized4location, status: status4location, permissionType: .Location)

let (authorized4notification, status4notification) = SystemPermissionMonitor.checkNotification()
filterPermissionArray(authorized4notification, status: status4notification, permissionType: .Notification)

let (authorized4audio, status4audio) = SystemPermissionMonitor.checkAudio()
filterPermissionArray(authorized4audio, status: status4audio, permissionType: .Audio)
}

过滤不需要显示的权限&更新权限实体状态
private func filterPermissionArray(_ authorized: Bool, status: Any?, permissionType: PermissionType) {
for (i, model) in permissionArray.enumerated() {
if model.permissionType != permissionType { continue }

if isNotDetermined(status, permissionType: permissionType) {
// Remove permissions that user has not yet made a choice with regards to this application
permissionArray.remove(at: i)
} else {
// Update the value of the property
permissionArray[i].authorized = authorized
permissionArray[i].status = status
}
break
}
}

判断用户是否尚未对此应用程序的权限作出选择(.notDetermined)
/// Whether user has not yet made a choice with regards to this application
private func isNotDetermined(_ status: Any?, permissionType: PermissionType) -> Bool {
switch permissionType {
case .PhotoLibrary:
let status: PHAuthorizationStatus? = status as? PHAuthorizationStatus
return status == .notDetermined
case .Camera, .Audio:
let status: AVAuthorizationStatus? = status as? AVAuthorizationStatus
return status == .notDetermined
case .Location:
let status: CLAuthorizationStatus? = status as? CLAuthorizationStatus
if #available(iOS 13, *) {
// “Allow once”, your app will be notified that the CLAuthorizationStatus changed to authorizedWhenInUse. Just like you’re used to in older iOS version when you get a permanent permission. It is now allowed for your app to start requesting locations, no code changes necessary.
// Users can jump out and back into your app, and you will still have location permission. It’s only after a (longer) period of inactivity that iOS will revoke the permission and turn the CLAuthorizationStatus back to notDetermined
// Return false, adapting to the new ‘allow just once’ location permission in iOS 13
return false
}
return status == .notDetermined
case .Notification:
if #available(iOS 10.0, *) {
let status: UNAuthorizationStatus? = status as? UNAuthorizationStatus
return status == .notDetermined
}
break
default:
break
}
return false
}

效果图

摘要：

Android 6.0之后的版本增加了运行时权限，应用程序在执行每个需要系统权限的功能时，需要添加权限请求代码（默认权限禁止），否则应用程序无法响应；Android 7.0在Android 6.0的基础上，对系统权限进一步更改，这次的权限更改包括三个方面：

1. APP应用程序的私有文件不再向使用者放宽
2. Intent组件传递file://URI的方式可能给接收器留下无法访问的路径，触发FileUriExposedException异常，推荐使用FileProvider
3. DownloadManager不再按文件名分享私人存储的文件。旧版应用在访问COLUMN_LOCAL_FILENAME时可能出现无法访问的路径。面向 Android 7.0 或更高版本的应用在尝试访问 COLUMN_LOCAL_FILENAME 时会触发 SecurityException

简单的三句话，无法让TeachCourse真正理解Android 7.0系统权限更改的含义，如果不按照文档的方式去做，API 24开发的应用程序是否就用不了？

一、深入理解FileProvider

FileProvider属于Android 7.0新增的一个类，该类位于v4包下，详情可见android.support.v4.content.FileProvider，使用方法类似与ContentProvider，简单概括为三个步骤，这里先以调用系统相机拍照并保存sdcard公共目录为例，演示使用过程：

• 在资源文件夹res/xml下新建file_provider.xml文件，文件声明权限请求的路径，代码如下：

• 在AndroidManifest.xml添加组件provider相关信息，类似组件activity，指定resource属性引用上一步创建的xml文件（后面会详细介绍各个属性的用法），代码如下：

• *后一步，Java代码申请权限，使用新增的方法getUriForFile()和grantUriPermission()，代码如下（后面会详细介绍方法对应参数的使用）：

• 修改build.gradle文件compileSdkVersion大于或等于24，targetSdkVersion等于24，使用Android 7.0模拟器运行Demo，效果图：

那么，我们已经了解Android 7.0系统权限申请的步骤，接下来说明每一个步骤需要注意的事项、相关方法参数的说明、属性的含义以及可以的申请权限目录（*后下载相关Demo）。

1.1 定义一个FileProvider

直接使用FileProvider本身或者它的子类，需要在AndroidManifest.xml文件中声明组件的相关属性，包括：

• android:name，对应属性值：android.support.v4.content.FileProvider或者子类完整路径
• android:authorities，对应属性值是一个常量，通常定义的方式packagename.fileprovider，例如：cn.teachcourse.fileprovider
• android:exported，对应属性值是一个boolean变量，设置为false
• android:grantUriPermissions，对应属性值也是一个boolean变量，设置为true，允许获得文件临时的访问权限

想要关联res/xml文件夹下创建的file_provider.xml文件，需要在<provider>标签内，添加<meta-data>子标签，设置<meta-data>标签的属性值，包括：

• android:name，对应属性值是一个固定的系统常量android.support.FILE_PROVIDER_PATHS
• android:resource，对应属性值指向我们的xml文件@xml/file_provider

1.2 指定授予临时访问权限的文件目录

上一步说明了怎么定义一个FileProvider，这一步主要说明怎么定义一个@xml/file_provider文件。Android Studio或Eclipse开发工具创建Android项目的时候默认不会创建res/xml文件夹，需要开发者手动创建，点击res文件夹新建目录，命名xml，如下图：

然后，在xml文件夹下新建一个xml文件，文件命名file_provider.xml，指定根标签为paths，如下图：

在xml文件中指定文件存储的区块和区块的相对路径，在<paths>根标签中添加<files-path>子标签（稍后详细列出所有子标签），设置子标签的属性值，包括：

• name，是一个虚设的文件名（可以自由命名），对外可见路径的一部分，隐藏真实文件目录
• path，是一个相对目录，相对于当前的子标签<files-path>根目录
• <files-path>，表示内部内存卡根目录，对应根目录等价于Context.getFilesDir()，查看完整路径：
  /data/user/0/cn.teachcourse.demos/files
• 代码如下：

<paths>根标签下可以添加的子标签也是有限的，参考官网的开发文档，除了上述的提到的<files-path>这个子标签外，还包括下面几个：

1. <cache-path>，表示应用默认缓存根目录，对应根目录等价于getCacheDir()，查看完整路径：/data/user/0/cn.teachcourse.demos/cache
2. <external-path>，表示外部内存卡根目录，对应根目录等价于
   Environment.getExternalStorageDirectory()，
   查看完整路径：/storage/emulated/0
3. <external-files-path>，表示外部内存卡根目录下的APP公共目录，对应根目录等价于
   Context#getExternalFilesDir(String) Context.getExternalFilesDir(null)，
   查看完整路径：
   /storage/emulated/0/Android/data/cn.teachcourse.demos/files/Download
4. <external-cache-path>，表示外部内存卡根目录下的APP缓存目录，对应根目录等价于Context.getExternalCacheDir()，查看完整路径：
   /storage/emulated/0/Android/data/cn.teachcourse.demos/cache

*终，在file_provider.xml文件中，添加上述5种类型的临时访问权限的文件目录，代码如下：

1.3 生成指定文件的Content URI

Content URI方便与另一个APP应用程序共享同一个文件，共享的方式通过ContentResolver.openFileDescriptor获得一个ParcelFileDescriptor对象，读取文件内容。那么，如何生成一条完整的Content URI呢？TeachCourse总结后，概括为三个步骤，*步：明确上述5种类型中的哪一种，第二步：明确指定文件的完整路径（包括目录、文件名），第三步：调用getUriForFile()方法生成URI

1.4 授予Content URI临时访问权限

上一步获得的Content URI，并没有获得指定文件的读写权限，想要获得文件的读写权限需要调用Context.grantUriPermission(package, Uri, mode_flags)方法，该方法向指定包名的应用程序申请获得读取或者写入文件的权限，参数说明如下：

• package，指定应用程序的包名，Android Studio真正的包名指build.gradle声明的applicationId属性值；getPackageName()指AndroidManifest.xml文件声明的package属性值，如果两者不一致，就不能提供getPackageName()获取包名，否则报错！
• Uri，指定请求授予临时权限的URI，例如：contentUri
• mode_flags，指定授予临时权限的类型，选择其中一个常量或两个：Intent.FLAG_GRANT_READ_URI_PERMISSION，Intent.FLAG_GRANT_WRITE_URI_PERMISSION

授予文件的临时读取或写入权限，如果不再需要了，TeachCourse该如何撤销授予呢？撤销权限有两种方式：*种：通过调用revokeUriPermission()撤销，第二种：重启系统后自动撤销

1.5 对外提供可访问的Content URI

有多种方式可以向客户端APP提供可访问文件的Content URI，其中一种常用的方式是通过发送Intent给需要启动的Activity，在重写的startActivityResult()方法中获取授予临时权限的Content URI或向用户提供可访问的接口来获取文件，后面的这种方式获取文件后转换成Content URI，以文章开头拍照的功能为例，TeachCourse想要在sdcard的公共目录pictures/查看已保存的照片，实现过程：

• 请求授予访问公共目录的权限，代码如下：

• 在重写的startActivityResult()方法中获取授予临时权限的Content URI，代码如下：

• 查询Environment.DIRECTORY_PICTURES目录，返回的Content URI包含的文件和文件类型相关信息，代码如下：

运行Demo，控制台打印效果图：

更多说明，可以参考Google提供的例子

二、深入理解DownloadManager

同样，为了方便理解DownloadManager的用法，首先以一个简单例子开始：从指定的url下载资源，然后显示下载资源的相关信息，运行Demo的效果图：

Android 7.0系统权限更改的第三点，简单的说：通过访问COLUMN_LOCAL_FILENAME，在Android 7.0系统上可能无法获取Demo效果图fileName对应的文件路径，这时候可能触发异常SecurityException，打印的log信息，如下：

1. Caused by: java.lang.SecurityException: COLUMN_LOCAL_FILENAME is deprecated; use ContentResolver.openFileDescriptor() instead
2. at android.app.DownloadManager$CursorTranslator.getString(DownloadManager.java:1499)
3. at cn.teachcourse.download.DownloadManagerActivity.query(DownloadManagerActivity.java:244)
4. at cn.teachcourse.download.DownloadManagerActivity.access$100(DownloadManagerActivity.java:34)
5. at cn.teachcourse.download.DownloadManagerActivity$1.onReceive(DownloadManagerActivity.java:186)
6. at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:1122)
7. at android.os.Handler.handleCallback(Handler.java:751)
8. at android.os.Handler.dispatchMessage(Handler.java:95)
9. at android.os.Looper.loop(Looper.java:154)
10. at android.app.ActivityThread.main(ActivityThread.java:6077)
11. at java.lang.reflect.Method.invoke(Native Method)
12. at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865)
13. at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

2.1 关于DownloadManager

DownloadManager是一个用于处理长时间HTTP请求的系统服务，客户端请求的URI可能是将要下载的指定的文件，处于后台的下载管理器将控制着下载的任务，并监测下载的状态，在下载失败或连接改变以及系统重启后尝试重新下载。

• 如何初始化DownloadManager实例？首先调用getSystemService(String)方法，传入DOWNLOAD_SERVICE常量，来初始化DownloadManager实例，代码如下：

mDownloadManager = (DownloadManager) getSystemService(DOWNLOAD_SERVICE);

• 如何配置请求参数？首先需要使用到内部类DownloadManager.Request，查看源码学习该类的各个方法的使用，TeachCourse简单总结：该类主要用于配置一条新下载任务相关内容，这些内容包括下载任务的保存路径，下载任务所处的网络状态（WiFi或流量状态）和下载任务通知栏显示样式等等，代码如下：

• 如何开启下载任务？下载任务参数配置完成后，就可以开启后台服务下载，同一个DownloadManager实例，可以开启多个下载任务，需要上一步中配置多条URI，每个下载任务分配唯一的id，代码如下：

• DownloadManager通过两种状态的广播，*种：任务下载完成后发送，广播拦截器过滤action是DownloadManager.ACTION_DOWNLOAD_COMPLETE（关于广播的知识，不懂的可以参考TeachCourse博客另外的几篇文章）；第二种：点击通知栏进度条后发送，广播拦截器过滤action是DownloadManager.ACTION_NOTIFICATION_CLICKED，代码如下：

• 如何查询下载任务的相关信息？首先需要使用到内部类DownloadManager.Query，查看源码学习该类各个方法的使用，TeachCourse简单总结：该类正如文章开头样式的例子，通过分配的id查询下载任务相关的信息，这些信息包括文件类型、文件的Uri和文件的长度等，代码如下：

• 代码加入判断语句，如果非Android 7.0系统继续访问COLUMN_LOCAL_FILENAME获得文件存储的*对路径（上面中间部分代码），openFile()方法代码如下：

现在，我们已经掌握了DownloadManager怎么实例化、怎么配置下载任务、怎么开启后台服务以及如何查询任务相关信息，想要实现一个应用程序版本更新就变得很简单，实现多任务下载也不是难事，完整源码参考文章后台通过的Demo。

三、关于ParcelFileDescriptor和FileDescriptor总结

官网的文档推荐我们使用ContentResolver.openFileDescriptor()方法，获得一个ParcelFileDescriptor对象，再通过getFileDescriptor()方法返回一个FileDescriptor，它们之间的关系参考上面的代码。

FileDescriptor通常被称为文件描述符，可以理解成本地的一个文件，通过流的方式读取文件内容以及通过流的方式写入数据到文件，这里是读取或写入数据到FileDescriptor中，假如我们的Uri表示的是一个txt文件，获取FileDescriptor对象后，通过下面的代码读取txt文件的内容：

FileInputStream fis = new FileInputStream(fd);

同理，写入数据到txt文件，代码如下：

获取到输入流或输出流后，剩下的就是关于流的操作了，划分为：文件字节流、文件字符流、缓冲流、数组流等

3.1 改写上面的例子

openFile()方法使用封装好的decodeFileDescriptor()，查看BitmapFactory.decodeFileDescriptor()相关源码，学习如何读取文件描述符中的内容，这里TeachCourse根据读取流的方式，改写如下：

于是，可以对FileDescriptor进行简单的封装成writeData()和readData()，代码如下：

总结：

Android 7.0系统的权限更改，包括三个方面，文章从第二方面开始讲解，着重介绍了FileProvider和DownloadManager两个类的使用，花了好长时间整理、测试和编辑，如果对你有帮忙，别忘了收藏和分享咯！

1. FileProvider源码路径：nougat/WriteToReadActivity.java
2. DownloadManager源码路径：download/DownloadActivity.java
3. Demo源码

4. 参考资料：https://developer.android.google.cn/about/versions/nougat/android-7.0-changes.html

1、前言
从Android 6.0(API 23)开始，对系统权限做了很大的改变。在之前用户安装APP前，只是把APP需要使用的权限列出来给用户告知一下，APP安装后都可以访问这些权限。从6.0开始，一些敏感权限，需要在使用时动态申请，并且用户可以选择拒*授权访问这些权限，已授予过的权限，用户也可以去APP设置页面去关闭授权。这对用户来说提高了安全性，可以防止一些应用恶意访问用户数据，但是对于开发来说，也增加了不少工作量，这块不做适配处理的话，APP在访问权限的时候会容易crash。

2、权限等级和权限组
权限主要分为normal、dangerous、signature和signatureOrSystem四个等级，常规情况下我们只需要了解前两种，即正常权限和危险权限。

2.1、正常权限
正常权限涵盖应用需要访问其沙盒外部数据或资源，但对用户隐私或其他应用操作风险很小的区域。应用声明其需要正常权限，系统会自动授予该权限。例如设置时区，只要应用声明过权限，系统就直接授予应用此权限。下面是截止到API 23的普通权限(需*访问)

2.2、危险权限
危险权限涵盖应用需要涉及用户隐私信息的数据或资源，或者可能对用户存储的数据或其他应用的操作产生影响的区域。例如读取用户联系人，在6.0以上系统中，需要在运行时明确向用户申请权限。

2.3、权限组
系统根据权限用途又定义了权限组，每个权限都可属于一个权限组，每个权限组可以包含多个权限。例如联系人权限组，包含读取联系人、修改联系人和获取账户三个权限。
* 如果应用申请访问一个危险权限，而此应用目前没有对应的权限组内的任何权限，系统会弹窗提示用户要访问的权限组(注意不是权限)。例如无论你申请READ_CONTACTS还是WRITE_CONTACTS，都是提示应用需要访问联系人信息。
* 如果用户申请访问一个危险权限，而应用已经授权同权限组的其他权限，则系统会直接授权，不会再与用户有交互。例如应用已经请求并授予了READ_CONTACTS权限，那么当应用申请WRITE_CONTACTS时，系统会立即授予该权限。下面为危险权限和权限组:

3、运行时请求权限
关于运行时请求权限，官网介绍的很清楚，也有很多其他文章介绍，这里只是简单罗列一下。

3.1、检查权限
应用每次需要危险权限时，都要判断应用目前是否有该权限。兼容库中已经做了封装，只需要通过下面代码即可：

int permissionCheck = ContextCompat.checkSelfPermission(thisActivity,
Manifest.permission.WRITE_CALENDAR);

如果有权限则返回PackageManager.PERMISSION_GRANTED，否则返回PackageManager。PERMISSION_DENIED。

3.2、请求权限
当应用需要某个权限时，可以申请获取权限，这时会有弹出一个系统标准Dialog提示申请权限，此Diolog不能定制，用户同意或者拒*后会通过方法onRequestPermissionsResult()返回结果。当用户拒*过此权限申请时，再次申请Dialog上可以勾选不再提示，这种情况下，以后再申请权限不会弹Dialog直接返回拒*。所以一些依赖某些敏感权限的应用，需要自己去处理，向用户解释 为什么需要此权限，说服用户授予权限。请求权限代码如下：

ActivityCompat.requestPermissions(thisActivity,
new String[]{Manifest.permission.READ_CONTACTS}, REQUEST_CODE);

3.3、处理权限请求响应
当用户处理权限请求后，系统会回调申请权限的Activity的onRequestPermissionsResult()方法，只需要覆盖此方法，就能获得返回结果

@Override
public void onRequestPermissionsResult(int requestCode,
String permissions[], int[] grantResults) {
switch (requestCode) {
case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
// If request is cancelled, the result arrays are empty.
if (grantResults.length > 0
&& grantResults[0] == PackageManager.PERMISSION_GRANTED) {

// permission was granted, yay! Do the
// contacts-related task you need to do.

} else {

// permission denied, boo! Disable the
// functionality that depends on this permission.
}
return;
}
}
}

3.4、考虑使用intent
有很多权限操作可以考虑调用其他应用，这样的话当前应用就不需要申请权限。例如想要获取相机照相，可以通过ACTION_IMAGE_CAPTURE唤起相机应用去完成，相机应用会把照片返回。同样拨打电话、访问联系人，都可以考虑使用类似方法。相比较其他应用，这类专门的应用做一些操作更容易让用户接受。

4、 关于国产机6.0以下系统
部分国产厂商定制了系统(例如小米、华为)，在6.0以下系统就可以单独控制权限。但是通常它们处理的不够彻底，代码中判断是否授权的时候，返回的是已经授权。而真正去做操作的时候，却会因为没有权限导致应用crash。例如我曾遇到过的场景：
* 访问联系人，可以拿到Cursor对象，但是cursor.moveToFirst()会返回false。
* 访问摄像头时，获取到的Camera对象为空

所以在低版本手机上，不要以为拥有系统授权就万事大吉了，一定要多加条件判读和测试。

5、PermissionGrantor，一行代码搞定动态权限申请。
上面运行时请求权限中，我们看到了权限申请依赖于Activity和Fragment，和startActivityForResult()方法的使用类似，必须依赖于Activity和Fragment的回调方法。正常情况下还能满足需求，可是当申请的权限的代码在一个独立的模块中时，例如我封装了一个UI控件，控件中某个操作需要申请权限，或者项目采用了MVVM框架，需要在一些view类或者model类中申请权限，这是处理起来就会很麻烦。
我在自己代码中就遇到类似情况，后面我采用了使用一个单独的Activity来申请权限，通过回调的方式通知业务层授权结果。感觉使用起来挺方便，就把它放到maven仓库中了，项目中通过加入如下依赖即可。

compile ‘com.github.dfqin:grantor:2.1.0’

5.1 PermissionGrantor使用
申请权限很简单，只需要下面一句话即可。

PermissionsUtil.requestPermission(Activity activity, PermissionListener listener,
String[] permissions);

下面是一个申请摄像头的例子：

private void requestCemera() {
if (PermissionsUtil.hasPermission(this, Manifest.permission.CAMERA)) {
//有访问摄像头的权限
} else {
PermissionsUtil.requestPermission(this, new PermissionListener() {
@Override
public void permissionGranted(@NonNull String[] permissions) {
//用户授予了访问摄像头的权限
}

@Override
public void permissionDenied(@NonNull String[] permissions) {
//用户拒*了访问摄像头的申请
}
}, new String[]{Manifest.permission.CAMERA});
}
}

PermissionsUtil.requestPermission还有两个重载的实现。用户拒*授权时，会有一个默认Dialog提示用户开通权限。这个Dialog的内容可以定制，也可以不显示此Dialog