Android6.0中的运行时请求权限

原文链接:https://blog.lujun.co/2015/12/07/Android6.0%E4%B8%AD%E7%9A%84%E8%BF%90%E8%A1%8C%E6%97%B6%E8%AF%B7%E6%B1%82%E6%9D%83%E9%99%90/

问题来源于最近的一个项目中,原本好好的程序,在一台Nexus 6(Android6.0)上测试发现所有需要保存图片到本地的都不行,看报错:


error_1.png

其实不仅仅是保存图片这里报这个错,还有打开相机的时候也会报错。好了问题就这么开始了!

看到这里都知道是权限的问题所引起的原因,对,确实是因为权限的问题引起的,但是程序明明已经在Manifest中声明了以上操作需要的权限,而且在以前测试的系统机型中都是没问题的,为什么!突然间想到了Marshmallow发布的时候提及到的Requesting Permissions at Run Time这东西,对就是他的原因!

Requesting Permissions at Run Time究竟是啥,官方对他是如下介绍滴:
从Android6.0(API >= 23)开始,用户在APP运行的时候授予其权限而不是像以前安装的时候就通通授予了(以前授权方式好像没什么卵用)。由于不在需要在安装或更新APP的时候授予相关权限,这就简化了APP的安装过程。这也提高了用户对APP功能的控制,比如:用户可以选择让一个Camera APP使用Camera,用户可以在任何时候在设置面板撤销这个权限。。。
看完是不是有点像我们在国产ROM中常见到的每个应用运行时权限授予。

系统权限也被分成normaldangerous两类:

  • Normal类的权限不会直接涉及到用户隐私风险。如果APP在Manifest文件中声明了Normal类的权限,系统会自动授予这些权限。
  • Dangerous类的权限可能会让APP涉及到用户机密的数据。如果APP在Manifest文件中声明了Normal类的权限,系统会自动授予这些权限。如果在Manifest文件中添加了Dangerous类的权限,用户必须明确的授予对应的权限后APP才具有这些权限。
    关于哪些权限属于Normal类,哪些属于Dangerous类,如下图:


    normal-dangerous-permissions.png

更详细请看normal-dangerous-permissions文档。

现在我们知道了在APP中normal和dangerous类的权限都需要Manifest文件中声明,但是在不同的版本系统和target SDK效果是不一样的,有如下几点需要注意:

  • 系统Android 5.1以下或target SDK 22以下,只要在Manifest文件中声明了需要的权限,用户在安装APP的时候就会授予相应的权限;如果不授予当然APP也无法安装。
  • 如果设备运行在6.0以上并且你的应用的target SDK版本>=23,APP除了需要在Manifest文件中声明相应的权限之外,还要在APP运行时向用户进行请求每个dangerous类的权限。用户可以选择授予或不授予该权限,即使用户不授予该权限APP也可以继续运行,但是相关的需要权限的操作是没法进行的。

使用系统提供的API检查并请求权限

a. 检查权限

以为用户可以随时撤销对APP的授权,所以在每次准备进行需要dangerous类权限操作的时候,需要检查APP是否具有对应的权限。使用[ContextCompat.checkSelfPermission()](http://developer.android.com/reference/android/support/v4/content/ContextCompat.html#checkSelfPermission(android.content.Context, java.lang.String))检查权限,代码如下:

// 检查activity是否有写日程的权限
// Assume thisActivity is the current activity
intpermissionCheck=ContextCompat.checkSelfPermission(thisActivity,Manifest.permission.WRITE_CALENDAR);

上面代码,如果APP有该权限返回PackageManager.PERMISSION_GRANTED,APP接着可以进行对应操作;如果没有权限,以上方法返回PERMISSION_DENIED,APP需要明确的向用户请求授权。

b. 请求权限

如何使用系统的API向用户请求dangerous类的权限,也很简单,support-library都基本上帮我们做好了。首先这个权限已经在Manifest文件中声明(废话么),然后向用户请求该权限,同意了你就用,否则想都别想(用户是上帝)。Google是这么解释why the app needs permissions的:

在某些情况下,你可能想让用户理解为啥你的APP需要这个权限。比如用户打开了一个拍摄APP(好吧,又是Camera),用户不会对这个APP需要使用Camera感到奇怪,但是用户可能不能理解为什么这破APP还需要使用我的位置和联系人数据(不能忍了)!所以在你请求某个权限之前,你应该考虑提供一段解释性的话给用户。请记住你不是要靠这点解释性的话就让用户彻底的明白你为什么需要这个权限,如果你解释过多,用户觉得没卵用直接卸了APP。只有当用户拒绝了你权限请求之后才是使用那段解释性的话最好的时候,因为如果用户一直尝试使用某个需要权限的功能,但是却又一直不授予该权限,这就表明用户真不知道为什么这个功能需要这个这个权限,在这种情况下,你的解释性的话就派上用场了。

Android提供[shouldShowRequestPermissionRationale()](http://developer.android.com/reference/android/support/v4/app/ActivityCompat.html#shouldShowRequestPermissionRationale(android.app.Activity, java.lang.String))方法求向用户展示为啥你需要这个权限,当用户之前已经请求过该权限并且拒绝了授权这个方法返回true。
注意:如果用户拒绝权限请求的时候选择了Don’t ask again选项,上面的方法返回false,当然如果设备本身就不允许有这个权限也是返回false。
看看代码:

// Here, thisActivity is the current activity
if(ContextCompat.checkSelfPermission(thisActivity,Manifest.permission.READ_CONTACTS)!=PackageManager.PERMISSION_GRANTED){
  // Should we show an explanation?
   if(ActivityCompat.shouldShowRequestPermissionRationale(thisActivity,Manifest.permission.READ_CONTACTS)){
      // Show an expanation 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.
  }else{
      // No explanation needed, we can request the permission.
       ActivityCompat.requestPermissions(thisActivity,newString[{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.
  }
}

其中[requestPermissions()](http://developer.android.com/reference/android/support/v4/app/ActivityCompat.html#requestPermissions(android.app.Activity, java.lang.String[], int))就是请求权限方法,异步方法。看看这个方法需要三个参数:

@param activity The target activity
@param permissions The requested permissions(这里就是你需要申请的权限,在Manifest类中可以找到你需要的权限)
@param requestCode Application specific request code to match with a result  reported to onRequestPermissionsResult(int, String[], int[])}(标志这次授权的唯一请求码,当用户进行授权操作后在回调方法中可以根据这个标识符进行区分不同的授权操作)

有个缺点就是使用系统请求授权API你不能自定义样式,请求授权弹出来的是标准的Android Dialog(如下图,遵循Android标准蛮好的),如果你希望提供一些信息之类的应该在[requestPermissions()](http://developer.android.com/reference/android/support/v4/app/ActivityCompat.html#requestPermissions(android.app.Activity, java.lang.String[], int))之前进行操作。

request_permission_dialog.png

c. 处理授权请求回调

使用onRequestPermissionsResult(int ,String , int[])方法处理回调,上面说到了根据[requestPermissions()](http://developer.android.com/reference/android/support/v4/app/ActivityCompat.html#requestPermissions(android.app.Activity, java.lang.String[], int))方法中的requestCode,我们就可以在回调方法中区分授权请求,看代码:

@Override
publicvoidonRequestPermissionsResult(intrequestCode,Stringpermissions[],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;
        }
        // other 'case' lines to check for other
        // permissions this app might request
      }
}

最后注意以下两点:

  • 当在Manifest文件中声明了同一个permission group中的权限后,请求权限时不会列出具体的权限,只是将这个permission group权限进行说明。对于permission group中的所有权限,用户只需要授权一次,以后里面的所有其他权限都不需要在进行授权(撤销后等操作除外),系统会自动认为是授权并以PERMISSION_GRANTED为参数调用onRequestPermissionsResult方法,和弹出系统请求授权对话框点击授权是一样的效果。虽然这样,对于每个授权还是需要进行单独请求授权操作。
  • Requesting Permissions at Run Time是当target API >= 23并且系统为Android 6.0 (API level 23)及以上才有的,如不属于这种情况APP还是像以前一样在安装的时候回提示所有需要的权限并授予这些权限。
    看看简单的demo效果;


    compare.png

代码:
https://gitlab.com/lujun/RuntimePermissionDemo

参考:
[http://developer.android.com/training/permissions/requesting.html#perm-request][1]
[][2]http://stackoverflow.com/questions/23527767/open-failed-eacces-permission-denied
[1]:http://developer.android.com/training/permissions/requesting.html#perm-request
[2]:http://stackoverflow.com/questions/23527767/open-failed-eacces-permission-denied

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,602评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,442评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,878评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,306评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,330评论 5 373
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,071评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,382评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,006评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,512评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,965评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,094评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,732评论 4 323
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,283评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,286评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,512评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,536评论 2 354
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,828评论 2 345

推荐阅读更多精彩内容