【译】Permissions Best Practices Android M权限最佳做法

Permissions Best Practices

PreviousNext

In this document

• Consider Using an Intent
• Don't Overwhelm the User
• Explain Why You Need Permissions
• Test for Both Permissions Models

You should also read

• Interacting with Other Apps

It's easy for an app to overwhelm a user with permission requests. If a user finds the app frustrating to use, or the user is worried about what the app might be doing with the user's information, they may avoid using the app or uninstall it entirely. The following best practices can help you avoid such bad user experiences.

一个应用程序很容易通过权限请求吓倒用户。如果用户发现应用程序使用起来不爽，或者担心应用程序可能利用用户的信息做一些事情，就可能会避免使用该应用程序，或完全卸载它。以下最佳做法可以帮助你避免这种糟糕的用户体验。

Consider Using an Intent 考虑使用Intent

---

In many cases, you can choose between two ways for your app to perform a task. You can have your app ask for permission to perform the operation itself. Alternatively, you can have the app use an intent to have another app perform the task.

For example, suppose your app needs to be able to take pictures with the device camera. Your app can request the CAMERA permission, which allows your app to access the camera directly. Your app would then use the camera APIs to control the camera and take a picture. This approach gives your app full control over the photography process, and lets you incorporate the camera UI into your app.

However, if you don't need such complete control, you can use an ACTION_IMAGE_CAPTURE intent to request an image. When you send the intent, the system prompts the user to choose a camera app (if there isn't already a default camera app). The user takes a picture with the selected camera app, and that app returns the picture to your app's onActivityResult() method.

Similarly, if you need to make a phone call, access the user's contacts, and so on, you can do that by creating an appropriate intent, or you can request the permission and access the appropriate objects directly. There are advantages and disadvantages to each approach.

If you use permissions:

• Your app has full control over the user experience when you perform the operation. However, such broad control adds to the complexity of your task, since you need to design an appropriate UI.
• The user is prompted to give permission once, either at run time or at install time (depending on the user's Android version). After that, your app can perform the operation without requiring additional interaction from the user. However, if the user doesn't grant the permission (or revokes it later on), your app becomes unable to perform the operation at all.

If you use an intent:

• You do not have to design the UI for the operation. The app that handles the intent provides the UI. However, this means you have no control over the user experience. The user could be interacting with an app you've never seen.
• If the user does not have a default app for the operation, the system prompts the user to choose an app. If the user does not designate a default handler, they may have to go through an extra dialog every time they perform the operation.

总之就是能让别的应用干的活就让别的应用干，这样又不用设计界面，又不用申请权限，只要一个intent就解决问题了。以及权限申请就小不就大，不要过分请求权限。

Only Ask for Permissions You Need 只申请你（的应用）需要的权限

---

Every time you ask for a permission, you force the user to make a decision. You should minimize the number of times you make these requests. If the user is running Android 6.0 (API level 23) or later, every time the user tries some new app feature that requires a permission, the app has to interrupt the user's work with a permission request. If the user is running an earlier version of Android, the user has to grant every one of the app's permissions when installing the app; if the list is too long or seems inappropriate, the user may decide not to install your app at all. For these reasons, you should minimize the number of permissions your app needs.

Quite often your app can avoid requesting a permission by using an intent instead. If a feature is not a core part of your app's functionality, you should consider handing the work over to another app, as described in Consider Using An Intent.

每当你申请一个权限，都会迫使用户做出决定，所以你应该尽量减少这些请求的次数。如果用户运行的是Android6.0（API级别23）或更高版本，每次用户尝试一些需要权限的新应用功能，应用程序会因为请求权限中断用户的工作。如果用户运行的是Android的早期版本，用户在安装应用程序时要授予应用程序的每一个权限;如果列表太长或看起来不合适，用户最后可以决定不安装您的应用程序。由于这些原因，你应该尽量减少你的应用程序需要权限的数量。

很多时候你的应用程序可避免请求权限而采用intent。如果一个功能不是你的应用程序的功能的核心部分，你应该考虑将此功能切换到其他应用程序，正如上面一条所说的。

Don't Overwhelm the User 不要吓倒用户

---

If the user is running Android 6.0 (API level 23) or later, the user has to grant your app its permissions while they are running the app. If you confront the user with a lot of requests for permissions at once, you may overwhelm the user and cause them to quit your app. Instead, you should ask for permissions as you need them.

In some cases, one or more permissions might be absolutely essential to your app. It might make sense to ask for all of those permissions as soon as the app launches. For example, if you make a photography app, the app would need access to the device camera. When the user launches the app for the first time, they won't be surprised to be asked for permission to use the camera. But if the same app also had a feature to share photos with the user's contacts, you probably should not ask for the READ_CONTACTS permission at first launch. Instead, wait until the user tries to use the "sharing" feature and ask for the permission then.

If your app provides a tutorial, it may make sense to request the app's essential permissions at the end of the tutorial sequence.

如果用户运行的是Android 6.0（API级别23）或更高版本，用户不得不授予您的应用程序的权限当您的应用在运行时。如果你一次让用户面对了很多的权限请求，你可能会吓倒用户，并导致他们退出你的应用程序。相反，你应该在需要相关权限时再请求。

在某些情况下，一个或多个权限可能是您的应用程序绝对需要的，而一旦该应用程序启动就请求所有这些权限是合理的。例如，如果你做了一个摄影的应用程序，该应用程序需要访问设备摄像头。当用户启动的第一次应用程序，他们不会惊讶被请求允许使用相机的权限。但是，如果相同的应用程序也有一个功能，与用户共享联系人的照片，你可能不应该要求在第一次运行时就请求READ_CONTACTS权限。相反，等到用户尝试使用“共享”功能时再请求权限即可。

如果你的应用程序提供了一个教程，在教程结束时请求相关权限时合理的。

Explain Why You Need Permissions 解释为什么你需要这些权限

---

The permissions dialog shown by the system when you call requestPermissions() says what permission your app wants, but doesn't say why. In some cases, the user may find that puzzling. It's a good idea to explain to the user why your app wants the permissions before calling requestPermissions().

For example, a photography app might want to use location services so it can geotag the photos. A typical user might not understand that a photo can contain location information, and would be puzzled why their photography app wants to know the location. So in this case, it's a good idea for the app to tell the user about this featurebefore calling requestPermissions().

One way to inform the user is to incorporate these requests into an app tutorial. The tutorial can show each of the app's features in turn, and as it does this, it can explain what permissions are needed. For example, the photography app's tutorial could demonstrate its "share photos with your contacts" feature, then tell the user that they need to give permission for the app to see the user's contacts. The app could then callrequestPermissions() to ask the user for that access. Of course, not every user is going to follow the tutorial, so you still need to check for and request permissions during the app's normal operation.

当你调用requestPermissions（）系统会显示权限对话框，这说明了你需要这些权限，但没有说为什么需要。在一些情况下，用户可能会很困惑。在调用requestPermissions（）之前向用户解释为什么你的应用程序需要这个权限是个好主意。

例如，一个摄影的应用程序可能需要使用定位服务，这样就可以标记的照片拍摄的地理位置。一个普通用户可能不明白照片可以包含位置信息，并会疑惑为什么一个摄影应用程序要知道位置。因此，在这种情况下，在调用requestPermissions（）之前为用户讲述这个功能是个好主意。

一个通知用户的方法是将这些请求纳入一个教程。这个教程可以轮流显示每个应用程序的功能，这样就可以很好的说明为什么需要这些权限。例如，拍摄应用程序的教程可以模拟其“分享照片与您的联系人”功能，然后告诉用户这需要给应用程序相关权限才能查看用户联系人。该应用程序便可以调用callrequestPermissions（）向用户索要该权限。当然，并不是每一个用户都会按照教程给你所需要的权限，所以你仍然需要在应用程序的正式运行期间检查并请求权限。

Test for Both Permissions Models 测试两种权限模式

---

Beginning with Android 6.0 (API level 23), users grant and revoke app permissions at run time, instead of doing so when they install the app. As a result, you'll have to test your app under a wider range of conditions. Prior to Android 6.0, you could reasonably assume that if your app is running at all, it has all the permissions it declares in the app manifest. Under the new permissions model, you can no longer make that assumption.

The following tips will help you identify permissions-related code problems on devices running API level 23 or higher:

• Identify your app’s current permissions and the related code paths.
• Test user flows across permission-protected services and data.
• Test with various combinations of granted or revoked permissions. For example, a camera app might listCAMERA, READ_CONTACTS, and ACCESS_FINE_LOCATION in its manifest. You should test the app with each of these permissions turned on and off, to make sure the app can handle all permission configurations gracefully.
• Use the adb tool to manage permissions from the command line:
  • List permissions and status by group:

    $ adb shell pm list permissions -d -g

  • Grant or revoke one or more permissions:

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

• Analyze your app for services that use permissions.

从Android 6.0（API等级23）开始，用户在应用权限运行时授予和撤销权限，而不是在安装应用程序时。这样一来，你就必须在更广泛的条件下测试您的应用程序。在Android 6.0之前，你可以假设，您的应用程序在运行时拥有所有在manifest中声明的权限。而根据新的权限模型，你再也不能作出这样的假设。

以下提示将帮助您识别运行的API级别23或更高的权限相关的设备代码的问题：

• 确定你的应用程序的当前的权限和相关的代码路径。
• 测试用户跟随跨权限保护的服务和数据。
• 测试授予与撤销请求的各种组合。例如，一个摄像头应用程序可能列出CAMERA，READ_CONTACTS和ACCESS_FINE_LOCATION在其manifest。您应该测试每一个权限打开和关闭以确保应用程序能够很好的处理所有的权限配置。
• 使用adb工具通过命令行来管理权限：
  • 按组列出权限和状态：

　　　　　　$ adb shell pm list permissions -d -g

• • 授予或撤销一个或多个权限：

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

• 分析您的应用程序使用权限时的服务。

转载请标明出处和链接，作者保留所有权