Register now for Android Dev Summit 2019!

在 Wear OS 上请求权限

Android 6.0(API 级别 23)引入了一个新的权限模型,从而引入了一些专门针对 Wear OS by Google 谷歌的变更以及适用于所有 Android 设备的其他变更。

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

注意:本文假设您要创建一个手机应用,并将其作为手表应用的配套应用。不过,您并非必须创建手机应用;您的手表应用可以是独立应用。

对于 Wear 和手机应用,Android 6.0(API 级别 23)权限模型还可避免让用户预先授予应用可能需要的每项权限,从而简化应用安装和升级。除非应用确实需要相关权限,否则它不会请求这些权限。

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

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

权限情景

大体上来说,在 Wear OS 上,您可能会遇到四种请求危险权限的情景:

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

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

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

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

您的应用会在清楚为何需要权限才能执行指定操作时视情况请求这些权限。如果很显然您的应用会需要某些权限,就可以在启动时提示获取这些权限。如果对权限的需求并非如此明显,您可以选择在提示请求权限前提供额外说明。

如果应用或表盘主题一次需要多项权限,则权限请求会接连出现。

多个权限屏幕,接连显示。

图 1. 权限屏幕接连出现。

注意:从 Android 6.0(API 级别 23)开始,Wear OS 会自动将 Google 日历、联系人和位置数据同步到 Wear 设备。因此,当 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. 不再显示权限请求屏幕的选项。

服务权限

如上所述,只有一个 Activity 可以调用 requestPermissions() 方法,因此,如果用户通过某项服务(例如表盘主题)与您的应用互动,则该服务必须先打开一个后台 Activity 才能请求权限。此 Activity 可以提供额外的说明,也可能只是一个显示系统对话框的隐身 Activity。

如果您的穿戴式设备应用运行的服务不是表盘主题,并且用户未启动可能需要请求权限的应用,那么您可以在穿戴式设备上发布说明性通知。通知可以提供一项操作来打开 Activity,然后触发系统权限对话框。

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

用户可能需要在通过服务与应用间接互动时授予权限。

图 10. 正在请求权限的服务。

设置

与手机一样,用户可以随时在“设置”中更改 Wear 应用的权限。因此,当用户尝试执行需要某项权限的操作时,应用应一律首先调用 checkSelfPermission() 方法,以了解它目前是否有权执行此操作。即使应用知道用户之前已授予该权限,也应执行此项检查,因为用户可能随后又撤消了该权限。

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

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