Android 6.0权限管理的解析与实战

144
作者 宇是我
2016.03.20 16:36 字数 3650

一、引言

随着Android6.0发布,系统增加了一些新的特性和功能。这次的发布介绍了一种新的权限机制。用户可以在运行时直接管理应用程序的权限。这个功能提升了权限控制的可见性和可控性。同时简化了安装和自动升级过程,用户可以单独撤销或者授予应用程序某项权限,对应用拥有更多的控制权。

二、Android 6.0权限机制

当你应用程序target是Android 6.0及以上(API level 23),确保在运行时检查和请求权限。为了确定你的app是否授予某个权限,通过checkSelfPermission()方法判断,请求权限使用requestPermissions()方法。即使你的app不是target Android 6.0,你也应该在新的权限机制下测试你的应用。

用户很容易被一个app繁多的权限请求淹没,当用户发现一个app使用起来很麻烦,或者用户担心app窃取自己的信息。用户会拒绝使用这个app,更有甚至会卸载它。因此,在申请权限的时候,我们应该遵守以下几点规则进行申请。

(a)只向用户请求你需要的权限(尽可能少请求权限)

每次app请求权限,都是强制用户去做决定。你应该尽量减少这些请求的次数,以保证用户流畅操作。

(b)不要让繁多的权限申请请求淹没用户

不要一次性请求所有权限,只有当你需要使用的时候才去申请。在某些情况下,一个或多个权限是你app必须的,这个时候可能在应用一启动就去权限更加有意义。例如,你做的是一个摄影类的应用,应用需要使用设备照相机。当用户第一次启动app的时候,对于app请求使用照相机的权限,用户并不会感到迷惑。但是,如果这个应用拥有向联系人分享照片的功能,你最好不要在应用启动的时候就去申请READ_CONTACTS权限。你应该等到用户使用分享功能的时候,再去询问用户是否申请这个权限。

如果你的app提供了一个引导教程,在引导结束的时候申请必要权限是比较好的。

(c)测试所有的权限模式

从Android 6.0(API 23)开始,用户在运行时授予或者拒绝权限,而不是在安装app的时候。因此,你必须在更广泛的条件下测试你的应用。在Android 6.0之前,你可以合理假设如果你的程序运行,你程序拥有所有申明的权限。但在新的权限模式下,你不能进行这种假设。

下面的一些小贴士,帮助你在Android 6.0或者更高的版本上识别权限相关代码问题。

(1)识别app中当前权限和相关代码路径

(2)用permission-protected服务和数据测试用户流。

(3)通过各种组合测试权限授予和拒绝。

如一个拍照的app,可能会在manifest中声明CAMERA,READ_CONTACTS和ACCESS_FINE_LOCATION权限。你需要测试所有权限的授予和拒绝组合状态,确保app可以在所有的权限组合下优雅滴工作。(注意,从Android 6.0开始,用户可以对任意app的权限进行授予或者拒绝,即使app的目标API是小于23的)

(4)使用adb工具通过命令行管理权限

--组展示权限和状态

$ adb shell pm list permissions -d -g

--授权或者拒绝一个或者多个权限

adb shell pm [grant|revoke] ...

(5)分析应用中使用到权限的相关服务

三、Android系统权限介绍

Google将权限分为两类,一类是普通权限(Normal Permissions),这类权限一般不涉及用户隐私,也不需要用户进行授权,如网络访问,手机震动等,这些权限如下所示:

ACCESS_LOCATION_EXTRA_COMMANDS

ACCESS_NETWORK_STATE

ACCESS_NOTIFICATION_POLICY

ACCESS_WIFI_STATE

BLUETOOTH

BLUETOOTH_ADMIN

BROADCAST_STICKY

CHANGE_NETWORK_STATE

CHANGE_WIFI_MULTICAST_STATE

CHANGE_WIFI_STATE

DISABLE_KEYGUARD

EXPAND_STATUS_BAR

GET_PACKAGE_SIZE

INSTALL_SHORTCUT

INTERNET

KILL_BACKGROUND_PROCESSES

MODIFY_AUDIO_SETTINGS

NFC

READ_SYNC_SETTINGS

READ_SYNC_STATS

RECEIVE_BOOT_COMPLETED

REORDER_TASKS

REQUEST_INSTALL_PACKAGES

SET_ALARM

SET_TIME_ZONE

SET_WALLPAPER

SET_WALLPAPER_HINTS

TRANSMIT_IR

UNINSTALL_SHORTCUT

USE_FINGERPRINT

VIBRATE

WAKE_LOCK

WRITE_SYNC_SETTINGS

另外一类是危险权限(Dangerous Permission),涉及用户隐私,需要用户授权,如对sd卡读取、访问用户手机通讯录等。如图所示:


查看dangerou Permissions可以发现权限是分组的,这个和Android 6.0的授权机制有关。如果你申请某个危险的权限,假设你的app早已被用户授权了同一组的某个危险权限,那么系统会立即授权,而不需要用户去点击授权。比如你的app对READ_CONTACTS已经授权了,当你的app申请WRITE_CONTACTS时,系统会直接授权通过。此外,申请时弹出的dialog上面的文本说明也是对整个权限组的说明,而不是单个权限(ps:这个dialog是不能进行定制的)。

注:不要对权限组过多的依赖,尽可能对每个危险权限都进行正常流程的申请,因为在后期的版本中这个权限组可能会产生变化。

新权限机制实践

(1)在AndroidManifest文件中添加需要的权限

这个步骤和我们之前的开发并没有什么变化,试图去申请一个没有声明的权限可能会导致程序崩溃。

(2)检查权限

if(ContextCompat.checkSelfPermission(thisActivity, Manifest.permission.READ_CONTACTS)!= PackageManager.PERMISSION_GRANTED) {

//

}else{

//

}

这里涉及到一个API,ContextCompat.checkSelfPermission,主要用于检测某个权限是否已经被授予,方法返回值为PackageManager.PERMISSION_DENIED或者PackageManager.PERMISSION_GRANTED。当返回DENIED就需要进行申请授权了。

(3)申请授权

ActivityCompat.requestPermissions(thisActivity,

new String[]{Manifest.permission.READ_CONTACTS},

MY_PERMISSIONS_REQUEST_READ_CONTACTS);

该方法是异步的,第一个参数是Context;第二个参数是需要申请的权限的字符串数组;第三个参数为requestCode,主要用于回调的时候检测。可以从方法名requestPermissions以及第二个参数看出,是支持一次性申请多个权限的,系统会通过对话框逐一询问用户是否授权。

(4)处理权限申请回调

@Override

public void onRequestPermissionsResult(intrequestCode,

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 youneed to do.

} else {

// permission denied,boo! Disable the

// functionality that dependson this permission.

}

return;

}

}

}

ok,对于权限的申请结果,首先验证requestCode定位到你的申请,然后验证grantResults对应于申请的结果,这里的数组对应于申请时的第二个权限字符串数组。如果你同时申请两个权限,那么grantResults的length就为2,分别记录你两个权限的申请结果。如果申请成功,就可以做你的事情了~

// 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.

}

这个API主要用于给用户一个申请权限的解释,该方法只有在用户在上一次已经拒绝过你的这个权限申请。也就是说,用户已经拒绝一次了,你又弹个授权框,你需要给用户一个解释,为什么要授权,则使用该方法。

// Here, thisActivity is the currentactivity

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.

}

}


四、权限库封装

在系统是Android 6.0及以上的手机上,申请每个Dangerous Permission,都需要进行权限处理。如果不进行封装,会有很多的重复代码。这样的代码不够美观,且不利于阅读和维护。下面我介绍两种封装好的权限控制库PermissionGen和MPermissions。其中MPermissions是在PermissionGen的基础上做了优化,即将运行时注解改为编译时注解,提升了性能。

4.1 PermissionGen

4.1.1 库的使用方式

首先我们来看看PermissionGen是怎么使用的。在Activity或者fragment中,申请权限可以通过以下方式:

PermissionGen.needPermission(this,200,Manifest.permission.CAMERA);

或者

PermissionGen.with(MainActivity.this)

.addRequestCode(100)

.permissions(

Manifest.permission.READ_CONTACTS,

Manifest.permission.RECEIVE_SMS,

Manifest.permission.WRITE_CONTACTS)

.request();

通过设置参数,可以实现申请单个权限或者多个权限。我们知道,系统原生权限请求处理都是在回调onRequestPermissionsResult中处理的,这里我们使用PermissionGen,只需要在onRequestPermissionsResult中调用一下以下方法,如此库即可对回调结果进行分发处理。

@Override

public void onRequestPermissionsResult(intrequestCode,String[] permissions,

int[] grantResults) {

PermissionGen.onRequestPermissionsResult(this,requestCode,permissions,grantResults);

}

最后,对于权限授权的回调,是在activity或者fragment中处理的,如下所示。授权成功则执行PermissionSuccess修饰的方法,失败则执行PermissionFail修饰的方法,不同的权限通过requestCode来区分。

@PermissionSuccess(requestCode=200)

public void successOpenCamera(){

Dlog.debug("open camera success");

}

@PermissionFail(requestCode=200)

public void failOpenCamera(){

Toast.makeText(this,"Camera permission is not granted",Toast.LENGTH_SHORT).show();

}

4.1.2 库实现原理解析

通过上面库的使用,我们发现这个用起来真的很方便。下面我们从权限申请开始,一步步从源码分析库是怎么实现的。

首先,当我们去申请权限的时候,都会调用到PermissionGen.java类中的requestPermissions方法,我们来看看这个方法的实现:


首先遍历自己申请的所有权限,没有授权的相关权限存入列表deniedPermissions。若权限全都申请,deniedPermissions长度为0,则通过doExecuteSuccess方法,反射找到相应requestCode对应的回调方法并执行;若权限有未申请的,则调用activity或者fragment的requestPermissions方法去申请相应权限,此时会弹出相应弹窗(弹窗是系统级,不可更改),执行结果回调到onRequestPermissionResult方法。在方法中判断所有申请权限是否已经授权成功。成功执行doExecuteSuccess,失败执行doExecuteFailed。

接下来我们看看onRequestPermissionsResult方法,我们知道在activity或者fragment中,我们重写了onRequestPermissionsResult方法,在其中去执行PermissionGen中的onRequestPermissionsResult方法进行授权结果处理。而在PermissionGen中,对于授权结果的处理,主要是在requestResult中进行处理。


代码中遍历授权请求结果数组,只要有一个权限没有授权通过,则本次的授权就是失败的,调用doExecuteFail方法,成功则调用doExecuteSuccess方法。这里是这个库的精髓所在,库是如何通过doExecuteSuccess和doExecuteFail方法,执行requestCode对应的请求回调方法?这里以doExecuteSuccess为例进行介绍。我们发现doExecuteSuccess有两个参数,第一个参数表示的是请求执行的actvity或者fragment;第二个参数是requestCode。下面我们来看doExecuteSuccess的代码:

private static void doExecuteSuccess(Object activity, intrequestCode) {

Method executeMethod = Utils.findMethodWithRequestCode(activity.getClass(),

PermissionSuccess.class,requestCode);

executeMethod(activity,executeMethod);

}

看到这里就有种豁然开朗的感觉了,findMethodWithRequestCode这个方法必定是通过反射的方式找到注解修饰的对应的方法,然后通过executeMethod去执行对应的方法。我们来看findMethodWithRequestCode的源码:


正如我们所猜测的,代码中通过反射找到通过注解修饰的方法;然后通过对比注解的requestCode定位到正确的回调方法,最后通过executeMethod执行回调方法。

4.2 MPermissions

4.2.1 MPermissons库介绍

MPermissons库是作者在PermissionGen的基础上修改而来的,相信大家也都发现一个问题。PermissionGen是基于反射,在运行时获取回调方法并执行的,这在一定程度上影响了性能。MPermissons基于Annotation Processor,运行时注解,很好解决PermissionGen的问题。

4.2.2 MPermissions的使用

我们来看看MPermissions的使用,基本是和PermissionGen一样的。

首先:请求权限:

MPermissions.requestPermissions(MainActivity.this,REQUECT_CODE_CALL_PHONE,Manifest.permission.CALL_PHONE);

然后,重写onRequestPermissionsResult方法:

@Override

public void onRequestPermissionsResult(intrequestCode,String[] permissions, int[] grantResults)

{

MPermissions.onRequestPermissionsResult(this,requestCode,permissions,grantResults);

super.onRequestPermissionsResult(requestCode,permissions,grantResults);

}

最后注解修饰回调方法:

@PermissionGrant(REQUECT_CODE_CALL_PHONE)

public voidrequestCallPhoneSuccess()

{

Toast.makeText(this,"GRANT ACCESS SDCARD!",Toast.LENGTH_SHORT).show();

}

@PermissionDenied(REQUECT_CODE_CALL_PHONE)

public voidrequestCallPhoneFailed()

{

Toast.makeText(this,"DENY ACCESS SDCARD!",Toast.LENGTH_SHORT).show();

}

4.2.3 MPermissions的实现原理

从上面可以发现MPermissions和PermissionGen的使用方式是一样的,只是接口的命名方式不同而已。同样我们从权限申请开始分析,一路看下去,与PermissionGen的处理逻辑都是一样的。最后不同的doExecuteSuccess和doExecuteFail方法的实现逻辑。


看源码发现,MPermissions是通过Class.forName静态加载的方式,加载了对应activity或者fragment类的代理类,并执行requestCode对应的回调方法。这与PermissionGen的运行时反射处理相比,性能肯定是有提升的。但是到这里我们应该会有一个疑问,那就是这个代理类是从哪里冒出来的?我们继续往下看,发现库项目目录下有一个compile的工程,这是关键所在。我们的代理类,通过annotation Processor,在编译时,生成对应的XXXActivity$PermissionProxy,通过PermissionProcessor中的process方法生成。具体annotation processor的实现,大家可以自己查阅相关资料。


生成代理类如下所示:

public classMainActivity$$PermissionProxyimplementsPermissionProxy {

    publicMainActivity$$PermissionProxy(){

    }

    public void grant(MainActivity source, intrequestCode) {

        switch(requestCode){

        case20:

            source.requestSdcardSuccess();

            break;

        case30:

            source.requestCallPhoneSuccess();

        }

    }

    public void denied(MainActivity source, intrequestCode) {

        switch(requestCode){

        case20:

            source.requestSdcardFailed();

            break;

        case30:

            source.requestCallPhoneFailed();

        }

    }

}

最后,在doExecuteSuccess()或者doExecuteFail()方法中,通过Class.forName()加载的是生成的代理类,通过newInstance()新建对象,然后通过requestCode区分,调用对应的grant或者deny方法。

五、总结

Android6.0的权限控制,虽然目前看来处理起来还是有点繁琐,但使用户对应用有了更多的控制权。借助一些封装的权限控制第三方库,对于应用权限可以做到比较简洁的控制。PermisionGen操作比较简单,但是是运行时反射实现,性能较差;MPermissions解决了这个问题,在编译时生成代理类,解决了库运行时效率低的问题,但与之相比库实现起来略烦琐。


参考文章:Android 6.0 运行时权限处理完全解析

Android