Android应用权限简要介绍

• 1. 一个Android应用默认情况下是不拥有任何权限的, 一个应用是没有权利去进行一些可能会造成不好影响的操作的. 这些不好的影响可能是对其它应用,操作系统,或者是用户.如果应用需要一些额外的能力,则它需要在AndroidManifest.xml中静态地声明相应的权限.
     如果应用没有在manifest中声明权限, 却使用了相应的功能, 在调用到相应功能的时候, 将会抛出异常.
     比如程序要发送一个请求,却忘记加Internet权限, 那么在发送这个请求的时候程序就会抛出异常,一般不会catch这个异常,所以程序直接就崩溃了:
     Caused by: java.lang.SecurityException: Permission denied (missing INTERNET permission?)
     Android 6.0开始, 一部分比较危险的权限需要在程序运行时显式弹框,请求用户授权.
     至于什么时候弹这个框,由应用程序自己决定.
     对于其他权限,认为不是很危险,所以仍然保持原来的做法,在用户安装应用程序时就予以授权.

Permission的保护等级

permission的保护等级通过protectionLevel属性设置, 共有4种: normal,dangerous,signature,signatureOrSystem.
签名相关的比较不常用, 剩下的两种是normal和dangerous
总结下来就是: 所有的权限仍然在manifest中静态声明, normal权限的在安装的时候自动授权, 而dangerous的权限需要应用明确地请求用户授权.
Dangerous Permissions:

Table 1. Dangerous permissions and permission groups.

可以总结为:
1.所有的权限都在manifest中声明.
2.如果(1)你的app的targetSdkVersion是23及以上,并且(2)app运行在Android 6.0及以上的设备,危险权限必须动态请求.
当权限被拒绝,app理应还是能够使用的,只不过权限相关的部分功能不能用.
3.上一条中的两个条件(1)(2)没有同时满足,即属于其他情况, 所有权限在安装时请求,如果用户不接受,则不安装.

特别注意这种情况: 旧应用新系统.
如果targetSdkVersion小于23,即被认为是Android 6.0发布之前开发的应用, 还没有兼容6.0.
这种应用即便是被装在Android 6.0的机器上,也是采用原来的安装即授予权限逻辑, 所有权限在应用安装时全部被授权.
在Android 6.0的设备上安装targetSdkVersion小于23的应用之后, 可以在应用的设置中查看,发现所有的dangerous权限状态都是打开.

Permission group
所有的权限都有自己的permission group.
系统弹框请求某一个permission时也是只说明了它的类别,当用户同意,系统会给予它该条permission.(只有这一条).
但是如果app已经有了该group下的另一条permission,系统将会自动授予权限(也即请求权限的callback直接返回),这过程中不与用户交互.

动态权限请求的实现

原文: https://developer.android.com/training/permissions/requesting.html

因为权限动态检查相关的API是Android 6.0才加入的, 所以minSdkVersion不是23时,推荐使用SupportLibrary来实现,好处是: 程序里不必加if来判断当前设备的版本.

1.检查权限状态

如果执行的操作需要一个dangerous permission, 那么每次在执行操作的地方都必须check你是否有这个permission, 因为用户可以在应用设置里随意地更改授权情况, 所以必须每次在使用前都检查是否有权限.

检查权限的方法: ContextCompat.checkSelfPermission()两个参数分别是Context和权限名.

返回值是:PERMISSION_GRANTED if you have the permission, or PERMISSION_DENIED if not.

比如:

if (PackageManager.PERMISSION_GRANTED== ContextCompat.checkSelfPermission(
MainActivity.this, Manifest.permission.READ_CONTACTS)) { 
    //has permission, do operation directly
    ContactsUtils.readPhoneContacts(this);
    Log.i(DEBUG_TAG, "user has the permission already!");
    } else { 
      //do not have permission
}

2.动态请求权限

如果上面权限检查的结果是DENIED, 那么就需要显式地向用户请求这个权限了.

Android提供了几个方法来动态请求权限, 调用这些方法会显示出一个标准的Dialog, 这个Dialog目前是不能被定制的.

2.1有时候可能需要解释为什么需要这个权限

有时候你可能会需要跟用户解释一下权限的用途.

注意不是每条权限都需要解释,显而易见的那种可以不解释,太多的解释会降低用户体验.

一种方式是,当用户拒绝过这个权限,但是又用到了这个功能, 那么很可能用户不是很明白为什么app需要这个权限, 这时候就可以先向用户解释一下.

为了发现这种用户可能需要解释的情形, Android提供了一个工具类方法: shouldShowRequestPermissionRationale()

如果app之前请求过该权限,被用户拒绝, 这个方法就会返回true.

如果用户之前拒绝权限的时候勾选了对话框中”Don’t ask again”的选项,那么这个方法会返回false.

如果设备策略禁止应用拥有这条权限, 这个方法也返回false.

注意具体解释原因的这个dialog需要自己实现, 系统没有提供.

2.2请求权限

请求权限的方法是: requestPermissions() 传入一个Activity, 一个permission名字的数组, 和一个整型的request code.

这个方法是异步的,它会立即返回, 当用户和dialog交互完成之后,系统会调用回调方法,传回用户的选择结果和对应的request code.

代码:

if (PackageManager.PERMISSION_GRANTED == ContextCompat.checkSelfP
ermission(MainActivity.this, Manifest.permission.READ_CONTACTS)) { 
//has permission, do operation directly
    ContactsUtils.readPhoneContacts(this);
    Log.i(DEBUG_TAG, "user has the permission already!");
} else { 
    //do not have permission
    Log.i(DEBUG_TAG, "user do not have this permission!");
   // Should we show an explanation?
      if (ActivityCompat.shouldShowRequestPermissionRationale(MainActivit
        y.this, Manifest.permission.READ_CONTACTS)) { 
// Show an explanation to the user *asynchronously* -- don't block
 // this thread waiting for the user's response! After the user 
// sees the explanation, try again to request the permission.
       Log.i(DEBUG_TAG, "we should explain why we need this permission!");
    } else {
     // No explanation needed, we can request the permission.
        Log.i(DEBUG_TAG, "==request the permission==");

        ActivityCompat.requestPermissions(MainActivity.this, new String[]{
          Manifest.permission.READ_CONTACTS},
          MY_PERMISSIONS_REQUEST_READ_CONTACTS);
 // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
 // app-defined int constant. The callback method gets the 
// result of the request.
 }
}  

这个对话框是系统的,不能自定义.

经验证, 请求权限对话框中的”Don’t ask again”的选项, 只有该条权限之前的状态是Denied的时候,才会出现.

以前从未授权(即第一次弹框), 或者之前的状态是Granted(当然这种情况一般不会弹框询问), 出现的弹框都是不带该不再询问的选项的.

2.3处理请求权限的响应

当用户对请求权限的dialog做出响应之后,系统会调用onRequestPermissionsResult() 方法,传回用户的响应.

这个回调中request code即为调用requestPermissions()时传入的参数,是app自定义的一个整型值.

如果请求取消,返回的数组将会为空.

代码:

@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.
                ContactsUtils.readPhoneContacts(this);
                Log.i(DEBUG_TAG, "user granted the permission!");

            } else { // permission denied, boo! Disable the 
                // functionality that depends on this permission.
                Log.i(DEBUG_TAG, "user denied the permission!");
            } return;
        } // other 'case' lines to check for other 
// permissions this app might request
 }
}

系统自动回调的情况:

有一些情形下,调用

1.自动授权: 如果用户已经允许了permission group中的一条A权限,那么当下次调用requestPermissions()方法请求同一个group中的B权限时, 系统会直接调用onRequestPermissionsResult()` 回调方法, 并传回PERMISSION_GRANTED的结果.

2.自动拒绝: 如果用户选择了不再询问此条权限,那么app再次调用requestPermissions()方法来请求同一条权限的时候,系统会直接调用onRequestPermissionsResult()回调,返回PERMISSION_DENIED.