Android Wear 7 Requesting Permissions on Android Wear

最新推荐文章于 2023-05-08 10:54:43 发布

千雅爸爸

最新推荐文章于 2023-05-08 10:54:43 发布

阅读量1k

点赞数

分类专栏： Android Wear Develope Guider

Android Wear Develope Guider 专栏收录该内容

19 篇文章 0 订阅

订阅专栏

Requesting Permissions on Android Wear

<翻译>在Android Wear 上面请求权限

In this document

Permission Scenarios
Requesting Permissions
Permissions for Services
Settings
<翻译> 1：权限场景，2：请求权限，3：服务的权限 4：设置

Dependencies and prerequisites

<翻译>依赖和前期准备

Android 6.0 (API Level 23) or higher on the wearable and accompanying device
Google Play services 8.3 or higher
An Android Wear device
<翻译>1：在手表上面和相关的设备上面需要Android6.0（API Level23）或者更高，
2：Google Play service 8.3 或者更高
3：一个android Wear 的设备

Permission Scenarios

1：权限场景

Broadly speaking, there are four scenarios you may encounter when requesting dangerous permissions on Android Wear:

The Wear app requests permissions for an app running on the wearable device.
The Wear app requests permissions for an app running on the handset.
The handset app requests permissions for an app running on the wearable device.
The wearable app uses a different permission model from its handset counterpart.

The rest of this section explains each of these scenarios. For more detailed information about requesting permissions, seeRequesting Permissions.、

<翻译>大体上（Broadly ）说，有四种应用场景（ scenarios）你可能遇到在android 手表上请求危险的权限

1.1 手表应用给正在运行的手表设备上的应用请求权限

1.2 手表应用给正在运行在手机设备上的应用请求权限

1.3 手机应用给正在运行在手表设备上的应用请求权限

《应该还有一种手机应用给手机应用请求权限，不在我们这里的考虑里面，因为我们关心的是手表应用》

1.4 手表应用使用和它的手机对应（counterpart，副本，对应的）应用不同的权限model。

1.1 Wear app requests permission for an app running on the wearable device

<翻译>手表应用给正在运行的手表设备上的应用请求权限

When the Wear app requests a permission for an app running on the wearable device, the system displays a dialog to prompt the user for that permission. An app or service can only call therequestPermissions() method from an activity. If the user interacts with your app via a service, such as a watch face, the service must open an activity before requesting the permission.

<翻译>手表应用给正在运行的手表设备上的应用请求权限的时候，系统展示一个对话框提示（prompt ）用户这个权限。一个应用或者是服务只有从activity 中调用requestPermissions() 的方法。如果用户通过一个servie 和你的应用交互，例如手表的界面，这个service服务必须要在请求权限之前开启一个acitivty。

Your app requests permissions in context when it’s clear why the permissions are needed to perform a given operation. If it's obvious that your app requires certain permissions, your app can prompt for them on launch. If it may not be so obvious, you may choose to provide additional education before prompting for a permission.

If an app or watch face requires more than one permission at a time, permission requests appear one after the other.

<翻译>你的应用请求在上下文（context）中请求权限，它解释为什么需要权限去执行一个需要的操作。如果很明显的你的应用需要中心权限，你的应用可以在launcher上面提示他们（这个应该是我们在安装应用的时候提示的有那些权限的页面吧？）。如果不明显，你可能要选择去提供附加的学习在提示这个权限之前。（可能是解释为什么需要这个权限，例如我们是一个计步软件，那么我们是需要你的gps的，为什么呢？我要在里面给你解释一下，我们要记录你的轨迹，所以需要，这个就是学习）

如果一个应用或这手机界面一次请求多余一个权限，那么权限请求会一个一个的出现。

Figure 1. Permission screens appearing in succession.

Note: From Android 6.0 (API level 23), Android Wear automatically syncs Calendar, Contact, and Location data to the Wear device. As a result, this scenario is the applicable one when Wear requests this data.

<翻译>图表1：权限界面连续的（succession.）出现

注意：从Android 6.0 (API level 23),开始，android 手表自动通过日历，联系人，和地址信息到手机的设备上面。这样的结果就是，这个应用场景在手表请求这个数据的时候是可适用的

1.2 Wear app requests handset permission

手表应用给正在运行在手机设备上的应用请求权限

When the Wear app requests a handset permission, the Wear app must send the user to the handset to accept the permission. There, the handset app can provide additional education to the user via an activity. The activity should include two buttons: one for granting, and one for denying, the permission.

<翻译>当手表应用请求一个手机端的权限，手表应用必须发送用户去手机端去接收权限。也就是说，手机应用可以提供附加的学习去用户通过一个acitivty，这个activity 应该包含两个按钮，一个是接收权限，一个是拒绝权限。

Figure 2. Sending the user to the handset to grant permission.

<翻译>图表2.发送用户到手机端接收权限

1.3 Handset app requests wearable permission

手机应用请求手表权限

When the user is in a handset app and the app requires a wearable permission, the handset app must send the user to the wearable to accept the permission. The handset app uses therequestPermissions() method on the wearable to trigger the system permissions dialog.

<翻译>当用户在手机端应用的时候，手机的应用请求了一个手表的权限，例如请求手表的数据访问权限，那么手机应用必须让用户去手表段接收权限请求。

手机端使用 requestPermissions() 的方法在手表端，然后trigger一个系统权限对画框。

Figure 3. Sending the user to the wearable to grant permission.

<翻译>图表3：让用户去手表端授予权限

1.4 Mismatching permission models between wearable and handset app

<翻译>1.4 手表应用使用和它的手机对应（counterpart，副本，对应的）应用不同的权限model。

If your handset app begins using the Android 6.0 (API level 23) model but your wearable app does not, the system downloads the Wear app, but does not install it. The first time the user launches the app, the system prompts them to grant all pending permissions. Once they do so, it installs the app. If your app, for example a watch face, does not have a launcher, the system displays a stream notification asking the user to grant the permissions the app needs.

<翻译>如果你的手机应用程序开始使用 Android 6.0 (API level 23) model，但是你的手表应用没有，那么系统下载手机应用，但是不会安装这个。用于第一次启动应用的时候，系统提示用户去授予所有挂起的权限。一旦他们这样做了，才开始将应用程序安装到手表端。如果你的应用，例如一个手机face界面，没有一个启动，系统展示一个（stream）简化通知，请求用户去授予应用需要的权限。

Permission-Request Patterns

2：请求权限模式(在代码的哪里请求权限)

There are different patterns for requesting permission from users. In order of priority, they are:

<翻译>用户有不同请求权限的模式，按照优先级排序如下：

1：在上下文中请求，当特殊的功能需要明显的权限的时候，对于应用的运行不是必须的。

2：在上下文中理解，当请求权限的原因不是明显的，对于应用的运行不是必须的。

3：前端请求，当权限是明显需要的，而且对于应用的运行必要的

4：前端理解，当权限不是明显的需要的，但是对于应用的运行是必须的

Ask in context when the permission is obviously necessary for a specific functionality, but is not necessary for the app to run at all.
Educate in context when the reason for requesting the permission is not obvious, and the permission is not necessary for the app to run at all.
Ask up front when the need for the permission is obvious, and the permission is required in order for the app to run at all.
Educate up front when the need for the permission is not obvious, but the permission is required in order for the app to run at all.

2.1 Ask in context

在上下文中请求

Your app should request permissions when it’s clear why they are needed in order to perform a given operation. Users are more likely to grant a permission when they understand its connection to the feature they want to use.

For example, an app may require a user’s location in order to show nearby places of interest. When the user taps to search for nearby places, the app can immediately request the location permission, because there is a clear relationship between searching for nearby places and the need for the location permission. The obviousness of this relationship makes it unnecessary for the app to display additional education screens.

<翻译>你的应用应该请求权限，当他声明了他们需要为了执行一个操作的时候。当用户理解了这个连接使用的特性的时候很有可能授予这个权限。

例如一个app 可能需要用户的地址为了显示附近的感兴趣的地址。当用户点击了搜索附近的位置的时候，应用app会立刻请求地址权限，因为搜索附近位置和请求地址权限有直接的关系，这种明显的关系将会让app 不用展示附加的edutcate教育的界面。

Figure 4. Asking in context.

图表4：在上下文中请求

2.2 Educate in context

2.2 在上下文中教育

If necessary, you may choose to provide additional education before prompting for a permission. Again, your app should do this in context of a specific action, if it’s unclear why your app needs access to the requested permission in order to complete that action.

Figure 5 shows an example of in-context education. The app does not require permissions in order to start the timer, but an inline educational cue shows that part of the activity (location detection) is locked. When the user taps the cue, a permission-request screen appears, allowing the user to unlock location-detection.

You can use the shouldShowRequestPermissionRationale() method to help your app decide whether to provide more information. For additional details, seeRequesting Permissions at Run Time.

<翻译>如果需要，你可能会选择提供一个额外的教育或者称为理解，在提示权限之前。一样的，你的应用应该在一个特殊的activity的上下文中，如果它不是很明显的显示为什么你的应用需要访问请求的权限去完成相应的操作的话。

图表5展示了一个上下文教育/理解。应用没有为了开始计时器请求权限，但是一个内部的教育/理解线索（cue）显示activity的一部分（地理位置检测）上锁了。当用户点击这个cue线索的时候。一个权限请求界面显示了，允许用户去解锁地理检测。

你可以使用 shouldShowRequestPermissionRationale()方法去帮助你的应用决定是否提供相关信息。更多的细节请查看Requesting Permissions at Run Time.

Figure 5. Educating in context.

图表5：在上下文中教育/理解

2.3 Ask up front

If your app clearly requires a permission in order to work at all, you can prompt for that permission when the user launches the app. For example, a maps app clearly requires access to the device’s location to run its expected activities. No further education is necessary for this permission.

<翻译>前端请求

如果你的应用请求的请求了一个权限，为了能够更好的运行，你需要提示这个权限在用户启动这个app的时候。例如一个地图的应用明显的请求访问设备的地址为了运行他的特别的activitys。没有更多的权限的教育/理解需要。

Figure 6. Asking up front.

图表6 前端请求

2.4 Educate up front

前端教育/理解

In some cases, the app requires a permission for basic functionality, but the need for that permission is not obvious. In these cases, when the user first starts the app or sets a watch face, the app or watch face may choose to educate the user and ask for the permission.

<翻译>

在一些情况下，应用为了一个基本功能请求了一个权限，但是需要请求的意图不是很明显，在这些情况下，当用户首先启动了应用或者设置手表界面，应用或者手表界面可能选择教育或者说让用户理解然后授权。

Figure 7. Educating up front.

前端教育/理解

Handling Rejection

处理拒绝权限。

If a user denies a requested permission that is not critical to an intended activity, do not block them from continuing the activity. If certain parts of the activity are disabled by the denied permission, provide visual, actionable feedback. Figure 8 shows the use of a lock icon to indicate that a feature is locked because the user did not grant permission to use it.

<翻译>如果用户拒绝了权限的请求，这个请求对于意图activity不是很重要，不要打断用户，直接开始新的activity 就行了。如果acitivity的中心部分因为用户的拒绝权限而被禁用，那么提供一个可见的，可点击的回馈。例如图表8中，用户没有赋予一个权限，所以屏幕上面有一个小说提示用户这个特性被禁用了。

Figure 8. Lock icon, showing a feature is locked because of denied permission.

图表8：锁定图表，展示因为拒绝权限而被锁定的特性

When a previously denied wearable permission dialog appears a second time, it includes aDeny, don't show again option. If the user chooses this option, then the only way for them to allow this permission in the future is to go into the wearable's Settings app.

<翻译>当一个之前拒绝的手表权限对话框第二次显示的时候，他需要包含一个“拒绝，不要再显示”的选项，如果用户选择了这个选项，那么用户想要在允许这个选线只能在手表的设置应用界面里面了。

Figure 9. Offering not to show the permission-request screen anymore.

图表9：提供不要显示的权限请求界面

Permissions for Services

3：服务的权限

As mentioned above, only an activity can call the requestPermissions() method, so if the user interacts with your app via a service, for example a watch face, the service must open a background activity before requesting the permission. This activity could provide additional education, or it could simply be an invisible activity that brings up the system dialog.

If your wearable app runs a service that is not a watch face, and the user does not launch an app in which it might make sense to request a permission, you can post an educational notification on the wearable. The notification can provide an action to open an activity that then triggers the system permissions dialog.

Note: This is the only acceptable use of a stream notification for permissions requests.

<翻译> 之前提到过，只有一个activity 才能够调用 requestPermissions() 方法。所以如果用户通过服务来和应用交互，例如，手表界面，服务必须要在请求权限之前打开一个后台的activity。这个activity可以提供附加的教育/理解，或者这个可以简单的就是一个不可见的activity带出一个系统对话框。

如果你的手表应用运行一个服务不是手表界面，同时用户没有运行应用，这个应用可能想要请求一个权限。你可以发出一个教育的通知在手表端，是同志里面可以提供一个action去打开一个activity，这个activity 会出发系统权限对话框。

Figure 10. A service requesting permission.

图片10：一个服务请求权限

Settings

4：设置

As with the handset, the user can change a Wear app’s permissions in Settings at any time. Therefore, when the user tries to do something that requires a permission, the app should always first call thecheckSelfPermission() method to see if the app currently has permission to perform this operation. The app should perform this check even if it knows the user has previously granted that permission, since the user might have subsequently revoked that permission.

<翻译>有了手机端，用户可以在任何事件来切换手表应用的权限。所以，当用户试着去做一些需要权限的事情的时候，应用应该一直首先调用checkSelfPermission() 去看看应用是否当前有执行这个操作的权限。应用应该执行这个检测即使他知道用户之前被赋予了这个权限，因为用户可能随后（susequently）撤销（revoked）了这个权限。