应用权限最佳做法

权限请求保护设备可用的敏感信息，并且只有在您的应用程序运行需要访问信息时才能使用。 本文档提供了有关如何在不需要访问此类信息的情况下实现相同（或更好）功能的提示; 它并不是关于权限如何在Android操作系统中运行的详尽讨论。

有关Android权限的更一般说明，请参阅权限概述。 有关如何在代码中使用权限的详细信息，请参阅请求应用程序权限。

一、使用Android权限的原则

我们建议您在使用Android权限时遵循以下原则：
＃1：仅使用您的应用所需的权限才能工作。根据您使用权限的方式，可能有另一种方法可以执行您所需的操作（系统意图，标识符，电话呼叫背景），而无需依赖对敏感信息的访问。

＃2：注意库所需的权限。包含库时，还会继承其权限要求。您应该知道您包含的内容，所需的权限以及这些权限的用途。

＃3：保持透明。当您发出权限请求时，请清楚您正在访问的内容以及原因，以便用户做出明智的决策。将此信息与权限请求一起提供，包括安装，运行时或更新权限对话。

＃4：使系统访问显式。当您访问敏感功能（例如，摄像头或麦克风）时，提供连续指示可在用户收集数据时清楚显示，并避免您认为您正在偷偷收集数据。

本指南的其余部分在开发Android应用程序的上下文中详细说明了这些规则。

二、Android 6.0及更高版本的权限

Android 6.0 Marshmallow引入了一种新的权限模型，允许应用程序在运行时从用户请求权限，而不是在安装之前。当应用程序实际需要服务或受服务保护的数据时，支持新模型的应用程序请求权限。虽然这不会（必然）改变整体应用程序行为，但它确实会创建一些与敏感用户数据处理方式相关的更改：

增加情境上下文：在应用程序的上下文中，用户会被提示访问这些权限组所涵盖的功能。用户对请求权限的上下文更敏感，如果您请求的内容与应用程序的目的不匹配，向用户提供有关您请求权限的详细说明更为重要。允许;只要有可能，您应该在请求时和后续对话框中提供您的请求的解释，如果用户拒绝请求的话。

授予权限的灵活性更高：用户可以在请求和设置时拒绝访问各个权限，但是当功能因此而中断时，他们仍然会感到惊讶。最好监控有多少用户拒绝授权（例如使用Google Analytics），以便您可以重构您的应用以避免依赖该权限，或者更好地解释您需要获得应用权限才能正常工作的原因。您还应确保您的应用处理用户拒绝权限请求或在设置中关闭权限时创建的异常。

增加的交易负担：将要求用户单独授予权限组的访问权限，而不是作为一组权限。这使得最小化您请求的权限数量变得极其重要，因为它增加了授予权限的用户负担并增加了至少一个请求被拒绝的可能性。

三、避免请求不必要的权限

每次请求许可时，都会强制用户做出决定。您应该尽量减少发出这些请求的次数。如果用户运行的是Android 6.0（API级别23）或更高版本，则每次用户尝试某些需要权限的新应用功能时，应用都必须通过权限请求中断用户的工作。如果用户运行的是早期版本的Android，则用户必须在安装应用时授予应用的每个权限;如果列表太长或看起来不合适，用户可能决定根本不安装您的应用程序。出于这些原因，您应该尽量减少应用所需的权限数量。

本节提供了常见用例的替代方法，可帮助您限制所做的权限请求数。由于与请求较少权限的其他类似应用相比，请求的用户表面权限的数量和类型会影响下载，因此最好避免请求不必要功能的权限。

1、改为使用意图

在许多情况下，您可以选择两种方式让您的应用执行任务。您的应用程序要求获得执行任务本身的权限，或者它可以使用意图让另一个应用程序执行该任务。

例如，假设您的应用需要能够使用设备相机拍照。您的应用可以申请CAMERA权限，允许您的应用直接访问相机。然后，您的应用程序将使用相机API来控制相机并拍照。这种方法可让您的应用程序完全控制拍摄过程，并允许您将相机UI合并到您的应用程序中。

但是，如果您对访问用户数据的要求很少 - 换句话说，每次您需要访问数据时，用户被提供运行时对话并不是不可接受的中断 - 您可以使用基于意图的请求。 Android提供了一些应用程序可以使用而不需要权限的系统意图，因为用户选择在发出基于意图的请求时与应用程序共享的内容（如果有的话）。

例如，可以使用意图操作类型MediaStore.ACTION_IMAGE_CAPTURE或MediaStore.ACTION_VIDEO_CAPTURE来捕获图像或视频，而无需直接使用Camera对象（或需要权限）。在这种情况下，系统意图将在每次捕获图像时代表您请求用户的许可。

同样，如果您需要拨打电话，访问用户的联系人等，您可以通过创建适当的意图来执行此操作，或者您可以请求权限并直接访问相应的对象。每种方法都有优点和缺点。

如果您使用权限：

• 执行操作时，您的应用程序可以完全控制用户体验。 但是，这种广泛的控制会增加代码的复杂性，因为您需要设计适当的UI。
• 系统会提示用户在运行时或安装时授予一次权限（具体取决于用户的Android版本）。 之后，您的应用可以执行操作，而无需用户进行额外的交互。 但是，如果用户未授予权限（或稍后撤消该权限），则您的应用程序根本无法执行操作。

如果您使用意图：

• 您不必为操作设计UI。 处理意图的应用程序提供UI。
• 用户可以使用他们的首选应用程序执行任务。 例如，用户可以选择他们喜欢的照片应用来拍照。
• 如果用户没有该操作的默认应用程序，系统会提示用户选择应用程序。 如果用户没有指定默认处理程序，则每次执行操作时都可能需要经过额外的对话框。

2、不要压倒用户

如果用户运行的是Android 6.0（API级别23）或更高版本，则用户必须在运行应用时向您的应用授予其权限。如果您同时面对具有大量权限请求的用户，您可能会压倒用户并导致他们退出您的应用。相反，您应该在需要时请求权限。

在某些情况下，一个或多个权限可能对您的应用程序绝对必要。一旦应用程序启动，请求所有这些权限可能是有意义的。例如，如果您制作摄影应用程序，该应用程序将需要访问设备摄像头。当用户第一次启动应用程序时，他们不会对被要求获得使用相机的许可感到惊讶。但是，如果相同的应用程序还具有与用户的联系人共享照片的功能，则您可能不应在首次启动时要求READ_CONTACTS权限。相反，请等到用户尝试使用“共享”功能然后请求权限。

如果您的应用程序提供了教程，那么在教程序列结束时请求应用程序的基本权限可能是有意义的。

3、丢失音频焦点后暂停媒体

在这种情况下，当用户接到电话时，您的应用程序需要进入后台，并且只有在呼叫停止后才重新聚焦。

在这些情况下的常见方法 - 例如，媒体播放器在电话呼叫期间静音或暂停 - 是使用PhoneStateListener监听呼叫状态的变化或监听android.intent.action.PHONE_STATE的广播。此解决方案的问题在于它需要READ_PHONE_STATE权限，该权限强制用户授予对广泛的敏感数据（例如其设备和SIM硬件ID）以及来电的电话号码的访问权限的访问权限。

您可以通过为您的应用请求AudioFocus来检测用户是否在没有READ_PHONE_STATE或MODIFY_PHONE_STATE权限的电话中，这不需要显式权限（因为它不访问敏感信息）。只需将音频背景所需的代码放在onAudioFocusChange（）事件处理程序中，它就会在操作系统移动音频焦点时自动运行。有关如何执行此操作的更详细文档，请参见此处。

4、确定运行实例的设备

在这种情况下，您需要一个唯一标识符来确定运行应用程序实例的设备。

应用程序可以具有特定于设备的偏好或消息（例如，为云中的用户保存特定于设备的播放列表，使得它们可以为他们的汽车和家中具有不同的播放列表）。常见的解决方案是利用设备标识符，例如设备IMEI，但这需要设备ID和呼叫信息权限组（M +中的PHONE）。它还使用无法重置的标识符，并在所有应用程序之间共享。

使用这些类型的标识符有两种选择：
（1）使用com.google.android.gms.iid InstanceID API。 getInstance（上下文上下文）.getID（）将返回应用程序实例的唯一设备标识符。结果是应用程序实例作用域标识符，可以在存储有关应用程序的信息时用作键，如果用户重新安装应用程序，则会重置该标识符。
（2）使用randomUUID（）等基本系统函数创建自己的标识符，该标识符的作用域是应用程序的存储空间。

5、为广告或用户分析创建唯一标识符

在这种情况下，您需要一个唯一标识符，用于为未登录您应用的用户构建配置文件（例如，针对广告定位或衡量转化）。

为广告和用户分析构建配置文件有时需要在其他应用程序之间共享的标识符。对此的常见解决方案涉及利用设备标识符，例如设备IMEI，其需要设备ID和呼叫信息许可组（API级别23+中的PHONE）并且不能由用户重置。在任何这些情况下，除了使用不可重置的标识符并请求对用户来说可能看似不寻常的权限之外，您还将违反Play开发人员计划策略。

遗憾的是，在这些情况下，使用com.google.android.gms.iid InstanceID API或系统函数来创建应用程序范围的ID不是合适的解决方案，因为可能需要跨应用程序共享ID。另一种解决方案是通过getId（）方法使用AdvertisingIdClient.Info类中提供的广告标识符。您可以使用getAdvertisingIdInfo（Context）方法创建AdvertisingIdClient.Info对象，并调用getId（）方法以使用该标识符。请注意，此方法是阻塞的，因此您不应该从主线程调用它;此处提供了此方法的详细说明。

四、了解您正在使用的库

有时，您在应用中使用的库需要权限。 例如，广告和分析库可能需要访问位置或身份权限组才能实现所需的功能。 但是从用户的角度来看，权限请求来自您的应用程序，而不是库。

正如用户选择对相同功能使用较少权限的应用程序一样，开发人员应查看其库并选择未使用不必要权限的第三方SDK。 例如，尝试避免需要Identity权限组的库，除非有明确的面向用户的原因，为什么应用程序需要这些权限。 特别是，对于提供位置功能的库，请确保您不需要请求FINE_LOCATION权限，除非您使用基于位置的定位功能。

五、解释你需要权限的原因

当您调用requestPermissions（）时系统显示的权限对话框说明了您的应用所需的权限，但没有说明原因。 在某些情况下，用户可能会发现令人费解。 在调用requestPermissions（）之前，向用户解释为什么您的应用需要权限是一个好主意。

研究表明，如果用户知道应用程序需要它们的原因，那么用户可以更轻松地处理权限请求。 用户研究表明：

...用户愿意向给定的移动应用程序授予给定权限受到与此类权限相关联的目的的强烈影响。 例如，用户是否愿意授予对其位置的访问权限，这取决于该请求是否需要支持应用程序的核心功能，或者是否要与广告网络或分析公司共享此信息。

根据他的小组的研究，CMU的Jason Hong教授总结说：

...当人们知道应用程序为什么使用像他们的位置一样敏感的东西时 - 例如，针对有针对性的广告 - 这使得他们比简单地告诉应用程序使用他们的位置更舒服。

因此，如果您只使用属于权限组的一小部分API调用，则有助于明确列出您正在使用的权限中的哪些权限以及原因。 例如：

• 如果您只使用粗略位置，请在应用说明或有关您应用的帮助文章中让用户知道这一点。
• 如果您需要访问SMS消息以接收保护用户免受欺诈的身份验证代码，请让用户在您的应用程序说明中和/或您第一次访问数据时知道这一点。

注意：如果您的应用面向Android 8.0（API级别26）或更高版本，请不要在验证用户凭据时请求READ_SMS权限。 而是使用createAppSpecificSmsToken（）生成特定于应用程序的令牌，然后将此令牌传递给可以发送验证SMS消息的另一个应用程序或服务。

在某些条件下，让用户实时了解敏感数据访问也是有利的。 例如，如果您正在访问摄像头或麦克风，通常最好让用户知道应用程序中的某个位置或通知托盘中的通知图标（如果应用程序在后台运行），那么 好像你不是偷偷收集数据。

最终，如果您需要申请权限才能在您的应用中发挥作用，但原因尚不清楚，请找一种方法让用户知道您需要最敏感的权限。

六、测试两种权限模型

从Android 6.0（API级别23）开始，用户在运行时授予和撤消应用程序权限，而不是在安装应用程序时这样做。 因此，您必须在更广泛的条件下测试您的应用。 在Android 6.0之前，您可以合理地假设，如果您的应用程序根本运行，它具有它在应用程序清单中声明的所有权限。 从Android 6.0开始，用户可以为任何应用打开或关闭权限，甚至是针对API级别22或更低级别的应用。 您应该测试以确保您的应用程序正常运行，无论它是否具有任何权限。

以下提示将帮助您在运行API级别23或更高级别的设备上查找与权限相关的代码问题：
确定您应用的当前权限和相关代码路径。
测试用户流经受权限保护的服务和数据。
使用授予或撤销权限的各种组合进行测试。 例如，相机应用程序可能会在其清单中列出CAMERA，READ_CONTACTS和ACCESS_FINE_LOCATION。 您应该打开和关闭每个权限来测试应用程序，以确保应用程序可以正常处理所有权限配置。

使用adb工具从命令行管理权限：
按组列出权限和状态：

$ adb shell pm列出权限-d -g

授予或撤消一项或多项权限：

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

分析您的应用以获取使用权限的服务。