android 6.0 权限知识整理

在android 6.0系统发布后，一些系统权限就不能接在app安装的时候进行直接赋予权限，必须在app运行的时候进行赋予。

---

权限类别(Permission Categories)

系统权限分为两种类别，危险权限和常规权限：

• 常规权限对于用户的私人信息不会造成诸如信息泄露等等的风险，如果app在Mainfest文件中注册常规权限，系统会直接自动赋予权限，就像以前版本进行注册一样。
• 危险权限会提供当前使用的app访问用户私人数据的权限。如果你在在Mainfest文件中注册危险权限，用户必须进行验证是否让当前app进行访问(即弹出一个对话提示框提示用户是否进行访问)。

---

权限组(Permission Group)

所有的权限都属于权限组当中,包括常规权限和危险权限。对于常规权限而言，用户并不需要进行手动赋予权限，而危险权限则相反，所以开发者只需要关注危险权限即可。
如果app是运行在android 6.0(API level 23)版本上并且app的targetSdkVersion必须是23或者更高。
如果一个app需要在Mainfest中请求一个危险权限，但是app当前在权限组中并没有任何相关的权限，系统则会弹出一个提示框来让用户自主选择是否赋予当前app相关权限来支持app的相关操作。比如，如果一个app请求读取联系人的权限(READ_CONTACTS)，系统会弹出一个提示框询问用户是否为当前app提供读取联系人的权限，用户确认提供则app才会获得权限。

如果app在请求一个危险权限(A)的时候，app已经包含相同权限组中另一个危险权限了，那么系统会自动提供A的权限，相当于一个权限组中的其中一个权限被请求了通过了，其他权限不需要再次请求。

附危险权限组：

危险权限

---

不同sdk版本的权限

所有的权限都描述在Mainfest文件当中，在不同版本的sdk当中，描述权限展现的行为不同，效果不同：

• 如果设备运行在Android 5.1版本及以下，目标sdk在22以及以下，则对于危险权限可以在用户安装app的时候就进行权限的赋予操作，如果用户不允许其中某一项权限，则app安装失败。
• 如果设备运行在Android 6.0及以上，目标sdk版本是23及以上，app对于常规权限可以在用户安装期间就赋予权限，对于危险权限则需要在用户运行app期间进行请求，用户授权给app后，权限才会被允许，如果用户不允许相关权限，则app依然可以运行，但是相关功能不能访问，如当用户通过app调用camera功能，app提示需要相关权限，用户进行拒绝，那么app的照相功能则不能访问，其他功能依然可以进行。

注意
在Android 6.0(API 23)以上的设备，用户可以随时随地取消任何app的相关权限，即使相关app的sdk版本号是低于23的。因此，你必须测试你的app是否在相关权限取消后，能否依然正常的运行(坑啊！！！！)。

---

是否要使用权限

一般而言，当我们需要使用一个功能的时候需要调用所需要相关的权限，如上述举的例子，然而这只是其中一种方法，在官方文档中还推荐了一种方法，即使用Intent充当媒介来使用相关功能。

举个例子，当你的app需要照相的功能的时候，你可以通过添加camera权限来直接访问相机，你的app通过添加这个权限可以使用所有关于camera的API来进行你想要完成的所有操作，在这种情况下，别无他法。
但如果你并不需要所有的控制权，你可以通过intent的ACTION_IMAGE_CAPTURE属性来进行。通过intent的发送，系统会让用户选择一个相机app(如果用户没有默认使用的相机APP的话)，用户进行拍照和相片选择完成后将图片通过onActivityResult()方法回调传回。

两种方法的对比：

权限：

• 使用权限的时候，app在安装或者运行期间获得所对应的权限，对此你必须设计UI界面来支持相对应错综复杂的功能的实现(如camera);其次，如果用户在安装期间(或者随后在删掉相关权限)不同意相关权限的赋予，那么app就安装失败或者运行出现异常，因此，对于一个上线的app这是一个非常重要的处理点。

Intent：

• 使用Intent不需要进行UI界面的设计，完全交给第三方进行，因此，这意味着你对用户体验不能进行手把手的控制;其次，如果用户操作相关功能时候没有对应默认的app进行功能调用，系统更会让用户去选择一个app。如果用户没有指定一个默认的处理app，每调用一次相关功能就会出现一个提示框来提示用户选择相关app操作，这对用户体验来说是非常糟糕的。

---

权限实践

在android 6.0版本的时候，我们在使用相对应的危险权限的使用，需要手动调用弹出提示框，否则app并不会主动调用弹出，如果开发者要调用的相关功能而没有相对应的权限，极大可能导致app的崩溃。

例子：
允许状态效果：

allow.gif

拒绝状态效果：

deny.gif

主要代码：

 public void check(){
        if (ContextCompat.checkSelfPermission(this, Manifest.permission.WRITE_EXTERNAL_STORAGE)
                != PackageManager.PERMISSION_GRANTED) {
            //申请WRITE_EXTERNAL_STORAGE权限
            ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE},
                    100);
        }else {

            Toast.makeText(MainActivity.this,"已经赋予过权限",Toast.LENGTH_SHORT).show();
        }
    }

    @Override
    public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
        if (requestCode==100){
            if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // 允许
                Toast.makeText(MainActivity.this,"有权限",Toast.LENGTH_SHORT).show();
            } else {
               if (!ActivityCompat.shouldShowRequestPermissionRationale(MainActivity.this, Manifest.permission.WRITE_EXTERNAL_STORAGE)){
                   Toast.makeText(MainActivity.this,"没有权限,请开启对应权限",Toast.LENGTH_SHORT).show();
               }
                


            }
        }
    }

代码中主要有3个方法：

//检查是否有相关的权限
ContextCompat.checkSelfPermission(@NonNull Context context, @NonNull String permission)
//向用户请求权限
requestPermissions(final @NonNull Activity activity,
            final @NonNull String[] permissions, final int requestCode)

//另外一个方法，该方法的作用是当用户勾选不再提示的框框后，对话框不弹出来了，app没有相关操作，所以需要提醒用户
shouldShowRequestPermissionRationale(@NonNull Activity activity,@NonNull String permission)

目前解决的方法如上所示，但是如果每一个activity都通过这种方法进行判断，那么代码量就偏大了，因此有了第三方库PermissionsDispatcher,通过注解的方式进行，大大简化了代码。

主要的整理如上所述，想要深入了解的请移步android官方文档。

---

参考文章

• http://developer.android.com/guide/topics/security/permissions.html#normal-dangerous
• http://developer.android.com/training/permissions/requesting.html
• http://developer.android.com/training/permissions/best-practices.html#explain
• http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0830/3387.html
• http://blog.csdn.net/yangqingqo/article/details/48371123
• http://www.open-open.com/lib/view/open1450578678148.html