Android Developer ,必知必会的权限管理知识

      本文主要讲解了Android  权限管理方面几个点:1)Android 权限背景知识(业内人士可跳过);2)权限检查及权限兼容(核心);3)跳转到app管理权限页面(选读)

一、Android 权限背景知识

        提到Android 权限管理,业内人士都知道Google 在Android 6.0时提出了运行时权限管理机制,在Android 6.0之前,所申请的权限只需要在AndroidManifest.xml列举就可以,从而容易导致一些安全隐患,因此,在Android 6.0 时,Google 为了更好的保护用户隐私提出了新的权限管理机制(官网  :Working with System Permissions),同时将其分为两大类:

(1)Normal Permissions

      Normal Permissions  一般不涉及用户隐私,是不需要用户进行授权的,比如手机震动、访问网络等;

(2)Dangerous Permission

        Dangerous Permission一般是涉及到用户隐私的,需要用户进行授权(动态申请),比如读取SIM卡状态、访问通讯录、SD卡读写等。

通过 adb shell pm list permissions -d -g 可以查看  Dangerous Permission (以权限组形式)

Dangerous Permission group

        如上图所示 :Dangerous Permission 一般以 Permission group 形式存在,只要 Permission group中某一个 permission 被Granted,则整个Permission group下的权限均被Granted (目前是这样,以后规则说不定会变)。


二、权限检查及权限兼容

本节主要介绍介绍如何进行权限检查及权限兼容,主要分为以下几类:

(1)targetSdkVersion>=23,终端设备是6.0(api 23)以上系统;

这部分权限检查比较简单,不涉及权限兼容,使用官方方案就可以 ,使用 Context::checkSelfPermisson ,建议使用ContextCompat::checkSelfPermisson检查权限 即可 ,一般检查流程 如下: 

1)判断是否有对应权限 (ContextCompat::checkSelfPermisson)

2)判断是否需要解释对应权限用途(ActivityCompat::shouldShowRequestPermissionRationale)

如果需要解释,则现实自定义权限界面即可

3)不需要解释的话,直接请求对应权限(ActivityCompat::requestPermissions)

上述情况较为简单,在此不再赘述。

(2)targetSdkVersion<23,终端设备是6.0(api 23)以上系统;

       使用的是老的权限机制,在app 安装时会询问AndroidManifest.xml文件中的权限,但是用户可以在设置列表中关闭相关权限,这种情况可能会对app正常运行造成一定影响。

(3) 终端设备系统小于6.0(api 23)

       大家可能要问,终端设备系统小于6.0情况还需要考虑吗,肯定是用的老的权限管理机制,在app 安装时会询问AndroidManifest.xml文件中的权限,用户关闭不了,真的是这样吗 ?

      答案是否定的,在实测中发现,目前有不少国产Rom 手机在6.0之前就有关闭权限的开关。这种情况也是我们兼容的对象。

      下面将会以自己开发过程中遇到的问题进行展开 ,目前企鹅FM支持免流了,需要使用READ_PHONE_STATE权限 (读取SIM卡状态),由于之前未对改权限是否关闭没有进行相关判断,因此收到了很多例因为上述权限关闭,导致免流失败的情况。

适配过程如下 :

(1)使用  try catch 来检查权限是否关闭

        想法很简单,如果改权限被用户禁止了,那肯定会异常,因此可以在catch 中做文章,结果发现这一招根本没有用,为啥了 ?因为使用 READ_PHONE_STATE 权限的方法内部已经try catch ,外面无法捕获,因此该方法失效。

(2)ContextCompat::checkSelfPermisson

既然在6.0 可以使用Context::checkSelfPermisson进行权限检查,那能否使用support v4 中的ContextCompat::checkSelfPermisson 方法了,试一下,发现在api 23 以下失效,为了探究原因,查看了ActivityCompat::requestPermissons 内部实现,如下

ActivityCompat::requestPermissons

内部权限检查方法在api 23 以下,使用的是 PackageManager::checkPermission,再去查看PackageManager::checkPermission方法,如下:发现只要权限在AndroidManifest.xml中注册过,均会认为该权限granted ,因此上述方法在api 23 以下也失效。

PackageManager::checkPermission


......

查阅相关资料和请教组内同事,发现Support V4 下面有一个专门检查权限的工具类PermissionChecker。

(3)PermissionChecker

查看PermissionChecker源码发现 ,PermissionChecker内部实际上使用的是AppOpsManagerCompt,而AppOpsManager是在api 19 加入进入的(AppOpsManager后面介绍)

PermissionChecker::checkPermission

进而查看AppOpsManagerCompat 内部实现 

AppOpsManagerCompat::permissionToOp

IMPL实现如下:

IMPL实现 

从上图可以看出:在api 23以下, AppOpsManagerImpl::permissionToOp 直接返回为null ,这直接导致api 23以下权限检查将会返回 granted ,因此,该方法在api 23 下,权限检查方法也会失效。

(4)AppOpsManager

      API 19以上  ,Google 官方提供了 AppOpsManager 类来检查权限,看到这个api 时,脑海浮现出 “天无绝人之路啊”,里面有两个比较重要的方法 :AppOpsManager::checkOp(int op ,int uid ,String packageName) (hide方法)和AppOpsManager::checkOp(String op,int uid ,String packageName)(public 方法 ,api 23 以上可用),不经思考,直接写出了如下两个方法

1)AppOpsManager::checkOp(int op ,int uid ,String packageName)

需要使用反射 :

AppOpsManager::checkOp(int op ,int uid ,String packageName)

2)AppOpsManager::checkOp(String op,int uid ,String packageName)

API >= 23 才可以使用 :

AppOpsManager::checkOp(String op,int uid ,String packageName)

在实测中发现,api 低于23时 ,OP_READ_PHONE_STATE =51 找不到,导致反射失败。

仔细察看了一下 6.0 (API 23 )_NUM_OP = 62,如下,为何找不到51 了

6.0 (API 23 )_NUM_OP = 62

难不成 每个版本还不一样,查看其他版本,验证了这个想法:

5.1.1 (API 22 )_NUM_OP = 48

5.1.1 

Op个数限制  (需要找到对应源码说明**)详情 参看 :

查看Android 对应版本 _NUM_OP (目前最高支持5.1.1版本)

       此时,OP_READ_PHONE_STATE = 51 在6.0(API 23)以下,通过反射是找不到的,因此对于READ_PHONE_STATE权限检查仅限于6.0及6.0以上。

      同时也仔细看了一下AppOpsManager 类介绍,并不是为开发者设计的,不过其他权限兼容可以使用这种方法,前提是 要看OP_*是在什么版本才有的,需做兼容方案 。

public class AppOpsManager

extends Object

API for interacting with "application operation" tracking.

This API is not generally intended for third party application developers; most features are only available to system applications. Obtain an instance of it through Context.getSystemService with Context.APP_OPS_SERVICE.

(5)最后查看了几个第三方权限库(暂未看完)

1)PermissionsDispatcher

2)AndPermission


三、跳转到app管理权限页面 

        既然在这里讲解跳转到app 管理权限页面的方法,可想而之,事情绝对不太简单。Android 碎片化不仅在存在于ui适配 ,同样也存在于这里,导致我们无法使用同一种方式跳转到app管理权限页面(适配,Android 开发永远的痛)。

        那有没有办法可以简化适配工作,减少开发量,方法当然有,不过需要我们自己去总结和探索的,目前已有方法:

(1)直接跳转到系统设置页

Intent intent =newIntent();

intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

intent.setAction(Settings.ACTION_APPLICATION_DETAILS_SETTINGS);

intent.setData(Uri.fromParts("package",getPackageName(), null));

try{

startActivity(intent);

}catch(Exception exception) {

exception.printStackTrace();

}

        记得要添加上 try catch ,不加可能会crash。这种方式就不需要适配各个厂商的不同版本rom,缺点是,用户只能跳转到系统设置页,然后去找对应app 的权限管理(总会有一些用户找不到)

(2)站在前人的肩上

    引用前人经验:Android各大手机品牌手机跳转到权限管理界面 (未一一验证,毕竟没那么多手机)

    那是不是前人经验一定对了,那就不一定了,在当时可能是对的,在现在可能就行不通了,现在以MIUI跳转到app 权限管理页面为例进行说明。  

1)MIUI 6/7 

Intent localIntent = new Intent("miui.intent.action.APP_PERM_EDITOR");

localIntent.setClassName("com.miui.securitycenter", "com.miui.permcenter.permissions.AppPermissionsEditorActivity");

localIntent.putExtra("extra_pkgname", context.getPackageName());

try{

startActivity(intent);

}catch(Exception exception) {

exception.printStackTrace();

}

2)MIUI 8 

Intent localIntent = new Intent("miui.intent.action.APP_PERM_EDITOR");

localIntent.setClassName("com.miui.securitycenter", "com.miui.permcenter.permissions.PermissionsEditorActivity");

localIntent.putExtra("extra_pkgname", context.getPackageName());

try{

startActivity(intent);

}catch(Exception exception) {

exception.printStackTrace();

}

       对比1)和2)发现,在MIUI 6/7 和MIUI 8 上面,权限管理页面的activity名字不一样了,因此使用MIUI6/7的方法在MIUI8上就会失效,如果没有加上try catch ,就会直接crash。

      对于上述变化,作为一个开发者一般都是不知道的,即便通过反馈发现了这个问题,也有可能不知道对应的activity是什么,此刻要么搜索网上有没有类似解决方案,要么求助于对应rom 开发厂商的开发者论坛 (有时解决回应速度相当慢),那有没有更好的办法了,方法详见(3)部分。

(3)查看某个ROM的某个版本的权限管理页面的activity

 这里以华为p8为例简要说明,详细步骤如下:

1)通过设置找到对应app的权限管理页面,如下:

企鹅fm在华为p8上的权限管理页面

2)找到对应页面的activity

方法一:通过add 工具查看栈顶Activity

adb shell dumpsys activity | grep "mFocusedActivity"  

企鹅fm在华为p8上的权限管理页面对应的activity

更为详细的堆栈信息

详细的堆栈信息

方法二:使用Activity Tracer工具

使用方法:可参见我之前的文章 :Android开发—— 小工具,大效率

使用Activity Tracer查看权限管理页面对应的activity



比较赞的文章  :

应用宝Android6.0运行时权限适配总结

解除国产Android权限监控限制

Android权限管理原理 (相当给力)

Android权限是否被拒如何进行判断?(知乎热议)

AndroidL的checkPermission方法详解 (底层实现过程)

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

推荐阅读更多精彩内容