在 Android Wear 上请求权限

Android 6.0(API 级别 23)引入了一个新的权限模型,该模型带来了一些针对 Wear 的变更以及适用于所有 Android 设备的其他变更。

即使有配套的手机应用,用户也必须为 Wear 应用授予权限。从 Android 6.0(API 级别 23)开始,Wear 应用将无法接收在手机应用中授予的权限。例如,如果用户授予一个手机应用使用位置数据的权限,则 Wear 应用的用户随后仍然需要授予同一权限。

注:此页面假设您可能正在创建一个与手表应用配套的手机应用。不过,并非必须创建手机应用;您的手表应用可以是独立应用。

对于 Wear 应用和手机应用,Android 6.0(API 级别 23)权限模型还通过不再要求用户提前授予应用可能需要的每个权限,简化了应用的安装和升级。相反,在确实需要使用权限之前,应用不会请求权限。

注:对于要使用新权限模型的应用,它必须为 uses-sdk-elementcompileSdkVersion 指定值 23

本文档的其余部分将讨论在开发 Android Wear 应用时如何使用 Android 6.0(API 级别 23)权限模型。

权限情景

一般来说,在 Android Wear 上请求危险权限时,您可能会遇到以下四个情景:

  • Wear 应用穿戴式设备上运行的应用请求权限。
  • Wear 应用手持式设备上运行的应用请求权限。
  • 手机应用穿戴式设备上运行的应用请求权限。
  • 穿戴式设备应用使用与其手机应用不同的权限模型

本部分的其余内容将阐述上述每一个情景。如需了解有关请求权限的更多详细信息,请参阅请求权限

Wear 应用为穿戴式设备上运行的应用请求权限。

当 Wear 应用为穿戴式设备上运行的应用请求权限时,系统将显示一个对话框以提示用户授予该权限。应用或 Service 只能从 Activity 调用 requestPermissions() 函数。如果用户通过某个 Service (如表盘)与您的应用交互,则该 Service 必须先打开一个 Activity,方可请求权限。

当为执行指定操作而显然需要请求某些权限时,您的应用将会请求这些权限。如果您的应用显然需要特定权限,则您的应用可以在启动时提示用户。如果对权限的需求并非如此明显,您可以选择在提示请求权限前提供额外说明。

如果应用或表盘一次需要多个权限,则将依次显示每个权限请求。

此时将依次显示多个权限屏幕。

图 1. 依次显示的权限屏幕。

:从 Android 6.0(API 级别 23)开始,Android Wear 会自动将 Google 日历、通讯录和位置数据同步到穿戴式设备。因此,此方案适合 Wear 应用请求此数据的情形。

Wear 应用请求手机权限

当 Wear 应用请求手机权限时,Wear 应用必须提示用户在手机上授予此权限。此处,手机应用可以通过一个 Activity 向用户提供附加说明。此 Activity 应包含两个按钮:一个用于授予权限,一个用于拒绝授予权限。

Wear 应用提示用户在手机上授予权限。

图 2. 提示用户在手机上授予权限。

手机应用请求穿戴式设备权限

当用户处于手机应用中且应用需要穿戴式设备权限时,手机应用必须提示用户在穿戴式设备上接受权限。手机应用在穿戴式设备上使用 requestPermissions() 函数触发系统权限对话框。

手机应用提示用户在穿戴式设备上授予权限。

图 3. 提示用户在穿戴式设备上授予权限。

穿戴式设备应用和手机应用之间的权限模型不匹配

如果您的手机应用开始使用 Android 6.0(API 级别 23)模型,但是您的穿戴式设备应用没有使用该模型,则系统将下载 Wear 应用,但不会安装它。用户首次启动该应用时,系统提示他们授予所有待处理的权限。一旦用户执行此操作,系统将安装此应用。如果您的应用(例如,表盘)没有启动器,则系统将显示一个卡片信息流通知,要求用户授予应用所需的权限。

权限-请求模式

向用户请求权限有不同的模式。按照优先级顺序,这些模式分别为:

  • 情境请求,当权限对于获取特定功能明显必要但并非必须提供此权限才能运行应用时。
  • 情境说明,当请求权限的理由并非显而易见且并非必须提供此权限才能运行应用时。
  • 预先请求,对权限的需求显而易见且必须具有此权限才能运行应用时。
  • 预先说明,对此权限的需求并非显而易见但必须具有此权限才能运行应用时。

情境请求

当为执行指定操作而显然需要某些权限时,您的应用应请求这些权限。当用户了解权限与其要使用的功能的关系时,授予权限的可能性会更大。

例如,为显示附近的景点,某个应用可能需要用户的位置。当用户点按应用以搜索附近地点时,应用可以立即请求位置权限,因为在搜索附近地点和位置权限需求之间存在显而易见的关系。这种关系的显而易见性让应用无需显示额外的说明屏幕。

应用在明显需要权限时请求权限。

图 4. 情境请求

情境说明

如有必要,您可以选择在提示请求权限之前提供附加说明。同样,如果对于特定的操作,您的应用需要访问所请求的权限以完成该操作的理由并非显而易见,您的应用应提供情境说明。

图 5 展示了一个情境说明示例。应用启动定时器并不需要特定权限,但是内联说明显示该 Activity 的部分功能(位置检测)已被锁定。当用户点按此提示时,将显示权限请求屏幕,从而允许用户解锁位置检测。

您可以使用 shouldShowRequestPermissionRationale() 函数帮助您的应用决定是否提供更多信息。如需了解更多详情,请参阅在运行时请求权限

在需要请求权限时,应用将解释为何需要此权限。

图 5. 情境说明。

预先请求

如果您的应用明显需要某个权限才能正常运行,则您可以在用户启动应用时提示需要该权限。例如,地图应用明显需要访问设备的位置才能运行其预期 Activity。对于此权限,无需提供进一步的说明。

如果应用明显需要某个权限才能正常运行,它可以在启动时立即请求该权限。

图 6. 预先请求。

预先说明

在某些情况下,应用要求某个权限以执行基本功能,但对该权限的需求并非显而易见。在这些情况下,当用户首先启动应用或设置表盘时,应用或表盘可能选择向用户提供说明并请求此权限。

在启动时请求权限时,应用可以解释它为何需要此权限。

图 7. 预先说明。

处理拒绝

如果用户拒绝了应用请求的某个权限,而此权限对于目标 Activity 的运行并非至关重要时,则系统不会阻止他们继续运行此 Activity。如果此 Activity 的特定部分因拒绝授予权限而被停用,则提供可视化的可操作反馈。图 8 显示使用锁定图标来表明某项功能因用户未授予使用此功能的权限而被锁定。

当用户拒绝授予权限时,在关联的功能旁边会显示锁定图标。

图 8. 锁定图标,显示某项功能因为用户拒绝授予权限而被锁定。

当之前被拒绝的穿戴式设备应用权限对话框再次显示时,它将包含一个 Deny, don't show again 选项。如果用户选择此选项,那么他们将来只能通过进入该穿戴式设备的“设置”应用来授予此权限。

系统提供停止请求权限的选项。

图 9. 不再显示权限请求屏幕的选项。

Service 权限

如上所述,只有一个 Activity 可以调用requestPermissions() 函数,因此,如果用户通过某个 Service(例如,一个表盘)与您的应用交互,则该 Service 必须先打开一个后台 Activity 才能请求权限。此 Activity 可以提供附加说明,也可以只是一个可调出系统对话框的不可见 Activity。

如果您的穿戴式设备应用运行的 Service 是非表盘 Service,且用户启动的应用没有请求权限的显而易见的理由,您可以在穿戴式设备上发布一个说明性通知。此通知可提供一个用于打开一个 Activity 的操作,随后,该 Activity 将触发系统权限对话框。

:对于权限请求,这是唯一可以接受的卡片信息流通知方式。

当通过 Service 与应用间接交互时,用户可能需要授予权限。

图 10.请求权限的 Service。

设置

与手机一样,用户可以随时在“设置”中更改 Wear 应用的权限。因此,当用户尝试执行需要某个权限的操作时,应用应始终首先调用 checkSelfPermission() 函数以检查此应用目前是否具备执行此操作所需的权限。即便知道用户以前曾授予该权限,应用也应执行此检查,因为用户可能随后撤销了该权限。

用户可以通过“设置”应用更改权限。

图 11.通过“设置”应用更改设置。