Permissions Best Practices

在安装的过程中，用户非常easy忽略权限请求。

假设一个用户相应用感觉沮丧或者操心泄漏个人信息，那么这些用户就会不用他或者卸载它。

怎样规避这个问题呢？

Consider Using an Intent

在非常多的案例中，你可能会在两种实现方式中做出选择，你能够是的你的app拥有一个权限。也能够通过Intent的方式让还有一个app帮你实现相关功能。

比如。一款应用须要通过照相机获取图片，你能够通过请求CAMERA权限，该权限能够使得你的app能够直接控制相机。

你的应用能够用camera的api控制相机和获取图片。这样的方式能够使你的应用全然的控制拍照过程中，并同意相机界面融合到应用中。

然而，假设你不须要所有的控制权，你能够使用Intent 的ACTION_IMAGE_CAPTURE请求图片。

当你发送这个Intent,系统就会提供几个相机的app可选项（前提是没有设置默认使用的应用） ，用户能够选择一个相机应用。然后通过onActivityResult()方法获得返回值。

同理，假设你须要拨打一个电话，使用用户的联系人列表等等，你能够创建一个Intent，或者直接向用户请求权限。

每一种方式都有利有弊。

假设你申请一个户权限：

当你进行一个操作的时候，你的app控制了用户的体验。

然而过多的控制，会添加应用的复杂度。由于你须要设计适当的UI。

在执行时（API>=23）或者安装时，用户被提示授予权限许可。在这之后。你的应用在进行时时无需和用户进行额外的交互。然而，假设用户没有授予权限或者撤销了，你的应用将无法正常执行。

假设使用intent 的方式：

你不须要为了执行设计UI。处理该Intent的应用将提供UI。

然而，因为打开的是另外的应用，这也就意味着，你不能控制用户的交互体验了。在你通过intent启动的app中。因为不是你自己设计的界面。所以用户的交互是不受你控制的。

假设你通过intent启动的这个应用。用户没有一个默认的应用，系统就会弹出一个窗体。让用户选择一个app。

假设用户没有设置一个默认启动的，每次进行该操作的时候，都会弹出一个选择窗体。

Only Ask for Permissions You Need

每一次的权限请求，都是强迫用户去做出一个选择。

你应该最少的向用户去请求权限。

假设用户的版本号大于等于Android6.0，每当用户尝试使用一些须要权限的新特性的时候，你的应用都会弹出一个请求权限的窗体。假设是在早前的版本号中，权限列表是在安装的时候提示给用户的。假设权限列表太长或者看起来不舒服，用户可能不去安装这个应用。为了处理这些问题。你应该最少程度的请求权限。

你能够用intent的方式取代。假设你的新特性须要一个权限。你能够让还有一个app帮你实现这个功能。

Don't Overwhelm the User

假设用户的系统是大于等于Android6.0，用户必须在程序执行时去授予权限。

假设你一次性让面对用户非常多的权限请求，你可能使你的用户收到打击，退出你的应用。

相反的，你应该在什么时候使用，什么时候想用户请求。

在应用中，一个或多个权限往往是必要的。这样的情况。一启动app，我们就要想用户请求。比如。你做了一个摄影的应用。

这个应用须要用户的Camera权限。

当用户第一次启动应用。他们不会对你的权限请求感到困惑。可是假设这款应用有一个特色的红能，向你的通讯录好友风向图片，你不能上来就去请求用户的R  EAD_CONTACT权限。你应该在分享的时候去向用户请求权限。

假设你的应用提供了向导。最好是在向导结束之后在向用户请求权限。

Explain Why You Need Permissions

当你调用requestPermission()方法的时候，系统就会弹出弹出权限申请弹窗，可是这里没有表述你为什么须要这个权限。在非常多案例中。用户会感到困惑。一个比較不错的注意是在调用requestPermission（）之前，向用户解释你为什么须要这个权限。

比如：一个摄影app，想要用定位服务在图片上打上标志。一个普通的用户可能不明确为什么一个图片须要使用定位，会感到非常困惑。

在这个案例中。一个好主意是在requestPermission（）之前向用户解释。

还有一种方式，你能够把权限请求融合在向导中。在向导中。你能够向用户展示app的特殊功能点，而且向用户展示你为什么须要这个权限。比方。这个摄影的app，就能够在向导中表明”向联系人分享照片“这个特色功能。然后告诉你用户你须要联系人列表这个权限。

然后向用户申请。

这个应用能够能过通过调用requestPermission（）方法，向用户请求权限。

当然，不是每个用户都会看完你的向导。所以你还是要在用户使用该功能的时候，检測用户是否授权。假设没有。还要弹窗向用户申请该权限。

Test for Both Permissions Models

在Android6.0中，通过在执行时请求权限取代了安装时。由于这个原因，你必须在更广泛的条件下測试你的应用。

在Android6.0之前我们有充足的理由相信，我们的程序执行了，就有了足够的权限，由于这些权限已经在manifest文件里声明。

在新的权限模型中，就不能够这样了。

在大于等于API23的情况下，你须要确定你的权限：

·        IDentify your app’s current permissions andthe related code paths.

·        Test user flows across permission-protectedservices and data.

·        Test with various combinations of grantedor revoked permissions. For example, a camera app might listCAMERA, READ_CONTACTS,
and ACCESS_FINE_LOCATION in itsmanifest. You should test the app with each of
these permissions turned on andoff, to make sure the app can handle all permission configurations gracefully.

·        Use the adb toolto manage permissions from the command line:

o    Listpermissions and status by group:

$ adb shell pm list permissions -d -g

o    Grantor revoke one or more permissions:

$ adb shell pm [grant|revoke] <permission-name> ...

·        Analyze your app for services that usepermissions.

假设您认为我的分享对您实用，微信扫一扫关注我吧。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">