Permissions Best Practices

   在安装的过程中，用户很容易忽略权限请求。如果一个用户对应用感觉沮丧或者担心泄漏个人信息，那么这些用户就会不用他或者卸载它。如何规避这个问题呢？

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.

如果您觉得我的分享对您有用，微信扫一扫关注我吧。

Android 6.0 开发者对系统权限的使用与练习（Permissions Best Practices）

原文：http://blog.csdn.net/nefuyang/article/details/50718029