（七）Working with System Permissions使用系统权限

本文首次发表于依鹏csdn博客，转载注明出处http://blog.csdn.net/m0_37240709/article/details/77899730

Working with System Permissions使用系统权限

To protect the system's integrity and the user's privacy, Android runs each app in a limited access sandbox. If the app wants to use resources or information outside of its sandbox, the app has to explicitly request permission. Depending on the type of permission the app requests, the system may grant the permission automatically, or the system may ask the user to grant the permission.

为了保护系统的完整性和用户的隐私，Android在一个有限的访问沙箱中运行每个应用。如果该应用想要使用在沙箱之外资源或信息，那么该应用必须明确请求权限。根据应用请求的权限类型，系统可以自动授予权限，或者系统可以请求用户授予权限。

This class shows you how to declare and request permissions for your app.

这节课程向您展示了如何声明和请求应用程序的权限。

1、Declaring Permissions声明权限

Every Android app runs in a limited-access sandbox. If an app needs to use resources or information outside of its own sandbox, the app has to request the appropriate permission. You declare that your app needs a permission by listing the permission in the App Manifest.

每个Android应用都在一个受限访问沙箱中运行。如果应用程序需要在使用自己沙箱之外的资源或信息，应用程序必须请求适当的权限。需要通过在应用程序清单中列出权限来声明你的应用需要的权限。

Depending on how sensitive the permission is, the system might grant the permission automatically, or the device user might have to grant the request. For example, if your app requests permission to turn on the device's flashlight, the system grants that permission automatically. But if your app needs to read the user's contacts, the system asks the user to approve that permission. Depending on the platform version, the user grants the permission either when they install the app (on Android 5.1 and lower) or while running the app (on Android 6.0 and higher).

根据权限的敏感性，系统可能会自动授予许可，或者设备用户可能需要授予请求。例如，如果你的应用请求权限去打开设备的手电筒，系统会自动授予该权限。但如果你的应用需要读取用户的联系人信息，系统会要求用户批准该权限。根据平台版本的不同，用户可以在安装应用时(在Android 5.1和更低的版本上)或者在运行应用程序时(在Android 6.0和更高版本上)获得权限。

1.1、Determine What Permissions Your App Needs确定你的应用需要哪些权限

As you develop your app, you should note when your app is using capabilities that require a permission. Typically, an app is going to need permissions whenever it uses information or resources that the app doesn't create, or performs actions that affect the behavior of the device or other apps. For example, if an app needs to access the internet, use the device camera, or turn Wi-Fi on or off, the app needs the appropriate permission. For a list of system permissions, see Normal and Dangerous Permissions.

当你开发你的应用时，你应该注意到你的应用正在使用需要权限的功能。通常，当应用程序使用并非应用创建的信息或资源时，或执行影响设备或其他应用程序行为的操作，应用程序需要获得权限。例如，如果一个应用需要访问互联网，使用设备摄像头，或者打开或关闭无线网络，该应用需要得到适当的权限。对于系统权限列表，请参阅正常和危险的权限。

Your app only needs permissions for actions that it performs directly. Your app does not need permission if it is requesting that another app perform the task or provide the information. For example, if your app needs to read the user's address book, the app needs the READ_CONTACTS permission. But if your app uses an intent to request information from the user's Contacts app, your app does not need any permissions, but the Contacts app does need to have that permission. For more information, see Consider Using an Intent.

你的应用只需要对它直接执行的操作的权限。如果你的应用程序要求另一个应用执行任务或提供信息，那么你的应用就不需要获得许可。例如，如果你的应用需要阅读用户的通讯录，那么该应用就需要阅读联系人的许可。但如果你的应用程序使用了从用户联系人应用中请求信息的意图，你的应用不需要任何权限，但联系人应用程序确实需要获得许可。要了解更多信息，请参阅使用意图。

1.2、Add Permissions to the Manifest在清单文件中添加权限

To declare that your app needs a permission, put a element in your app manifest, as a child of the top-level element. For example, an app that needs to send SMS messages would have this line in the manifest:

要声明你的应用需要得到的权限，在你的应用程序清单中加入元素，作为顶级元素的一个子元素。例如，一个需要发送SMS消息的应用程序将在清单中有这一行:

    
    

    
        ...
    

The system's behavior after you declare a permission depends on how sensitive the permission is. If the permission does not affect user privacy, the system grants the permission automatically. If the permission might grant access to sensitive user information, the system asks the user to approve the request. For more information about the different kinds of permissions, see Normal and Dangerous Permissions.

在您声明一个权限之后，系统的行为取决于权限是多么的敏感。如果权限不影响用户隐私，系统将自动授予权限。如果权限允许访问敏感的用户信息，系统会要求用户批准请求。有关不同类型权限的更多信息，请参阅正常和危险的权限。

2、Requesting Permissions at Run Time在运行时请求权限

Beginning in Android 6.0 (API level 23), users grant permissions to apps while the app is running, not when they install the app. This approach streamlines the app install process, since the user does not need to grant permissions when they install or update the app. It also gives the user more control over the app's functionality; for example, a user could choose to give a camera app access to the camera but not to the device location. The user can revoke the permissions at any time, by going to the app's Settings screen.

从Android 6.0(API级别23)开始,用户在应用程序运行时授予应用程序权限,而不再是安装程序时。这种方法简化了应用程序的安装过程,因为用户不需要在安装或更新应用程序时授予权限。这也给了用户对应用程序功能的更多的控制；例如，用户可以选择让相机应用程序访问摄像头，而不是设备的位置。在任何时候，用户都可以通过进入应用的设置屏幕来撤销权限。

System permissions are divided into two categories, normal and dangerous:

系统权限分为两类:正常和危险:

• Normal permissions do not directly risk the user's privacy. If your app lists a normal permission in its manifest, the system grants the permission automatically. 正常的权限不会直接危及用户的隐私。如果你的应用程序在它的清单中列出了一个正常的权限，系统会自动授予权限。

• Dangerous permissions can give the app access to the user's confidential data. If your app lists a normal permission in its manifest, the system grants the permission automatically. If you list a dangerous permission, the user has to explicitly give approval to your app. 危险的权限可以让应用程序访问用户的机密数据。如果你的应用程序在它的清单中列出了一个正常的权限，系统会自动授予权限。如果你列出了一个危险的许可，用户必须明确地批准你的应用程序获得这个权限。

For more information, see Normal and Dangerous Permissions.

要获得更多信息，请查看正常和危险的权限。

On all versions of Android, your app needs to declare both the normal and the dangerous permissions it needs in its app manifest, as described in Declaring Permissions. However, the effect of that declaration is different depending on the system version and your app's target SDK level:

在所有的Android版本中，你的应用程序需要在其应用程序清单中声明它所需要的正常和危险的权限，就像在声明权限中所描述的那样。不过，系统版本和应用程序的目标SDK级别的不同，声明的效果会有所不同:

• If the device is running Android 5.1 or lower, or your app's target SDK is 22 or lower: If you list a dangerous permission in your manifest, the user has to grant the permission when they install the app; if they do not grant the permission, the system does not install the app at all. 如果该设备运行的是Android 5.1或更低，或者你的应用的目标SDK是22或更低:如果你在清单中列出了危险的许可，用户在安装应用时必须给予许可;如果他们不给予许可，系统根本就不安装该应用。

• If the device is running Android 6.0 or higher, and your app's target SDK is 23 or higher: The app has to list the permissions in the manifest, and it must request each dangerous permission it needs while the app is running. The user can grant or deny each permission, and the app can continue to run with limited capabilities even if the user denies a permission request. 如果该设备运行的是Android 6.0或更高版本，而你的应用程序的目标SDK则是23或更高:该应用必须列出清单中的权限，并且它必须在应用运行时请求它所需要的每一个危险的权限。用户可以授予或拒绝每个权限，即使用户拒绝了权限请求，该应用程序也可以继续以有限的能力运行。

Note: Beginning with Android 6.0 (API level 23), users can revoke permissions from any app at any time, even if the app targets a lower API level. You should test your app to verify that it behaves properly when it's missing a needed permission, regardless of what API level your app targets.

注意:从Android 6.0(API级别23)开始，用户可以在任何时候撤销任何应用的权限，即使这款应用的API级别较低。你应该对你的应用进行测试，以验证当它缺少必要的权限时，它的行为是否正确，不管你的应用目标是什么API级别。

This lesson describes how to use the Android Support Library to check for, and request, permissions. The Android framework provides similar methods as of Android 6.0 (API level 23). However, using the support library is simpler, since your app doesn't need to check which version of Android it's running on before calling the methods.

这个课程描述了如何使用Android支持库来检查和请求权限。Android框架提供了类似于Android 6.0(API级别23)的方法。不过，使用支持库更简单，因为你的应用程序不需要在调用方法之前检查它运行的是哪个版本的Android。

2.1、Check For Permissions检查权限

If your app needs a dangerous permission, you must check whether you have that permission every time you perform an operation that requires that permission. The user is always free to revoke the permission, so even if the app used the camera yesterday, it can't assume it still has that permission today.

如果你的应用需要一个危险的权限，你必须在每次执行需要权限的操作时，检查你是否有这个权限。用户总是可以自由地撤销该权限，因此即使应用昨天使用了摄像头，也不能假定它今天仍然拥有该权限。

To check if you have a permission, call the ContextCompat.checkSelfPermission() method. For example, this snippet shows how to check if the activity has permission to write to the calendar:

检查是否有权限,调用ContextCompat.checkSelfPermission()方法。例如，这个代码片段展示了如何检查活动是否允许写入日历:

// Assume thisActivity is the current activity
int permissionCheck = ContextCompat.checkSelfPermission(thisActivity,
        Manifest.permission.WRITE_CALENDAR);

If the app has the permission, the method returns PackageManager.PERMISSION_GRANTED, and the app can proceed with the operation. If the app does not have the permission, the method returns PERMISSION_DENIED, and the app has to explicitly ask the user for permission.

如果该应用获得了许可，该方法将返回PackageManager.PERMISSION_GRANTED，该应用可以继续进行操作。如果该应用没有得到权限，该方法将返回PERMISSION_DENIED，该应用必须明确向用户请求权限。

2.2、Request Permissions请求权限

If your app needs a dangerous permission that was listed in the app manifest, it must ask the user to grant the permission. Android provides several methods you can use to request a permission. Calling these methods brings up a standard Android dialog, which you cannot customize.

如果你的应用程序需要应用清单中列出的危险权限，它必须要求用户给予权限。Android提供了几种方法来请求权限。调用这些方法会弹出一个标准的Android对话框，你不能自定义它。

2.3、Explain why the app needs permissions解释为什么应用需要权限

In some circumstances, you might want to help the user understand why your app needs a permission. For example, if a user launches a photography app, the user probably won't be surprised that the app asks for permission to use the camera, but the user might not understand why the app wants access to the user's location or contacts. Before you request a permission, you should consider providing an explanation to the user. Keep in mind that you don't want to overwhelm the user with explanations; if you provide too many explanations, the user might find the app frustrating and remove it.

在某些情况下，您可能希望帮助用户理解为什么您的应用程序需要获得许可。例如，如果用户发布了一个拍照应用，用户可能不会感到惊讶，该应用会要求用户使用摄像头，但用户可能不理解为什么该应用需要访问用户的位置或联系人。在您请求许可之前，您应该考虑为用户提供一个解释。记住，你不想用解释淹没用户;如果你提供了太多的解释，用户可能会觉得这款应用令人沮丧，并将其删除。

One approach you might use is to provide an explanation only if the user has already turned down that permission request. If a user keeps trying to use functionality that requires a permission, but keeps turning down the permission request, that probably shows that the user doesn't understand why the app needs the permission to provide that functionality. In a situation like that, it's probably a good idea to show an explanation.

您可能使用的一种方法是仅当用户已经拒绝了该权限请求时才提供解释。如果用户一直试图使用需要获得权限的功能，但不断拒绝权限请求，这可能表明用户不理解为什么应用程序需要这个权限来获得该功能。在这种情况下，给出一个解释可能是个好主意。

To help find situations where the user might need an explanation, Android provides a utiltity method, shouldShowRequestPermissionRationale(). This method returns true if the app has requested this permission previously and the user denied the request.

为了帮助寻找用户可能在什么情况下需要一个解释，Android提供了一种实用方法，shouldShowRequestPermissionRationale()。如果应用程序之前有请求此权限，并被用户拒绝请求，该方法将返回true。

Note: If the user turned down the permission request in the past and chose the Don't ask again option in the permission request system dialog, this method returns false. The method also returns false if a device policy prohibits the app from having that permission.

注意:如果用户在过去拒绝了许可请求，并且在权限请求系统对话框中选择了不再请求选项，那么这个方法返回false。如果设备的策略是禁止应用程序获得此权限，该方法也会返回false。

Figure 1. System dialog prompting the user to grant or deny a permission.

图1所示。系统对话框提示用户授予或拒绝权限。

2.4、Request the permissions you need请求你需要的权限

If your app doesn't already have the permission it needs, the app must call one of the requestPermissions() methods to request the appropriate permissions. Your app passes the permissions it wants, and also an integer request code that you specify to identify this permission request. This method functions asynchronously: it returns right away, and after the user responds to the dialog box, the system calls the app's callback method with the results, passing the same request code that the app passed to requestPermissions().

如果您的应用程序还没有它所需要的权限，那么应用程序必须调用requestPermissions()方法中的一个来请求适当的权限。您的应用程序通过它得到想要的权限，以及您指定的一个整数请求码来识别这个权限请求。这个方法是异步的:它会立即返回，在用户响应对话框之后，系统会调用应用的回调方法，并将应用程序传递的请求代码传递给requestPermissions()。

The following code checks if the app has permission to read the user's contacts, and requests the permission if necessary:

以下代码检查该应用是否有权限读取用户的联系人信息，并在必要时请求权限:

// Here, thisActivity is the current activity
if (ContextCompat.checkSelfPermission(thisActivity,
                Manifest.permission.READ_CONTACTS)
        != PackageManager.PERMISSION_GRANTED) {

    // Should we show an explanation?
    if (ActivityCompat.shouldShowRequestPermissionRationale(thisActivity,
            Manifest.permission.READ_CONTACTS)) {

        // Show an expanation to the user *asynchronously* -- don't block
        // this thread waiting for the user's response! After the user
        // sees the explanation, try again to request the permission.

    } else {

        // No explanation needed, we can request the permission.

        ActivityCompat.requestPermissions(thisActivity,
                new String[]{Manifest.permission.READ_CONTACTS},
                MY_PERMISSIONS_REQUEST_READ_CONTACTS);

        // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
        // app-defined int constant. The callback method gets the
        // result of the request.
    }
}

Note: When your app calls requestPermissions(), the system shows a standard dialog box to the user. Your app cannot configure or alter that dialog box. If you need to provide any information or explanation to the user, you should do that before you call requestPermissions(), as described in Explain why the app needs permissions.

注意:当你的应用程序调用requestPermissions()时，系统会向用户显示一个标准的对话框。你的应用程序不能配置或改变对话框。如果您需要向用户提供任何信息或解释，那么在调用requestPermissions()之前，您应该这样做，这是解释为什么应用程序需要权限的原因。

2.5、Handle the permissions request response处理权限请求响应

When your app requests permissions, the system presents a dialog box to the user. When the user responds, the system invokes your app's onRequestPermissionsResult() method, passing it the user response. Your app has to override that method to find out whether the permission was granted. The callback is passed the same request code you passed to requestPermissions(). For example, if an app requests READ_CONTACTS access it might have the following callback method:

当您的应用程序请求权限时，系统会向用户显示一个对话框。当用户响应,系统调用应用程序的onRequestPermissionsResult()方法,传递用户响应。你的应用程序必须覆盖该方法，以确定是否获得了许可。回调传递的请求码与你传递给requestPermissions()方法的请求代码相同。例如，如果一个应用程序请求READ_CONTACTS访问，它可能有以下回调方法:

@Override
public void onRequestPermissionsResult(int requestCode,
        String permissions[], int[] grantResults) {
    switch (requestCode) {
        case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0
                && grantResults[0] == PackageManager.PERMISSION_GRANTED) {

                // permission was granted, yay! Do the
                // contacts-related task you need to do.

            } else {

                // permission denied, boo! Disable the
                // functionality that depends on this permission.
            }
            return;
        }

        // other 'case' lines to check for other
        // permissions this app might request
    }
}

The dialog box shown by the system describes the permission group your app needs access to; it does not list the specific permission. For example, if you request the READ_CONTACTS permission, the system dialog box just says your app needs access to the device's contacts. The user only needs to grant permission once for each permission group. If your app requests any other permissions in that group (that are listed in your app manifest), the system automatically grants them. When you request the permission, the system calls your onRequestPermissionsResult() callback method and passes PERMISSION_GRANTED, the same way it would if the user had explicitly granted your request through the system dialog box.

系统显示的对话框描述了应用程序需要访问的权限组;它没有列出具体的权限。例如，如果你请求READ_CONTACTS权限，系统对话框就会说你的应用需要访问设备的联系人。用户只需要对每个权限组授予一次权限。如果您的应用程序请求该组中的任何其他权限(在您的应用程序清单中列出)，系统将自动授予它们。请求权限时,系统调用你onRequestPermissionsResult()回调方法和传递PERMISSION_GRANTED, 如果用户通过系统对话框显式地授予您的请求，也会如此。

Note: Your app still needs to explicitly request every permission it needs, even if the user has already granted another permission in the same group. In addition, the grouping of permissions into groups may change in future Android releases. Your code should not rely on the assumption that particular permissions are or are not in the same group.

注意:你的应用程序仍然需要明确地请求它所需要的每一个权限，即使用户已经在同一组中获得了另一个权限。此外，在未来的Android版本中，权限分组可能会发生变化。您的代码不应该依赖于特定权限在或不在同一组的假设。

For example, suppose you list both READ_CONTACTS and WRITE_CONTACTS in your app manifest. If you request READ_CONTACTS and the user grants the permission, and you then request WRITE_CONTACTS, the system immediately grants you that permission without interacting with the user.

例如，假设您在应用程序清单中列出了READ_CONTACTS和WRITE_CONTACTS权限。如果您请求READ_CONTACTS权限，并且用户授予权限，然后您请求WRITE_CONTACTS，系统将立即授予您该权限，而不需要与用户进行交互。

If the user denies a permission request, your app should take appropriate action. For example, your app might show a dialog explaining why it could not perform the user's requested action that needs that permission.

如果用户拒绝了权限请求，你的应用应该采取适当的行动。例如，您的应用程序可能会显示一个对话框，解释为什么它不能执行用户请求的操作。

When the system asks the user to grant a permission, the user has the option of telling the system not to ask for that permission again. In that case, any time an app uses requestPermissions() to ask for that permission again, the system immediately denies the request. The system calls your onRequestPermissionsResult() callback method and passes PERMISSION_DENIED, the same way it would if the user had explicitly rejected your request again. This means that when you call requestPermissions(), you cannot assume that any direct interaction with the user has taken place.

当系统请求用户授予权限时，用户可以选择告诉系统不要再请求该权限。在这种情况下，每当应用程序使用requestPermissions()再次请求该权限时，系统会立即拒绝请求。系统调用你onRequestPermissionsResult()回调方法并传递PERMISSION_DENIED，如果用户再次拒绝了你的请求，你也会这样做。这意味着当您调用requestPermissions()时，您不能假定已经与用户发生任何直接交互。

3、Permissions Best Practices权限的最佳实践

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.

对于一个应用程序来说，使用权限请求来淹没用户是很容易的。如果用户发现这款应用令人沮丧，或者用户担心该应用可能会对用户的信息做什么，他们可能会避免使用该应用，或者完全卸载应用。下面的最佳实践可以帮助您避免这种糟糕的用户体验。

3.1、Consider Using an 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.

例如，假设你的应用需要能够用设备摄像头拍照。你的应用可以请求相机的权限，允许你的应用直接访问相机。你的应用会使用摄像头api来控制摄像头拍摄照片。这种方法可以让你的应用完全控制摄影过程，让你把相机UI融入到你的应用中。

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.

但是，如果您不需要这样的完全控制，您可以使用ACTION_IMAGE_CAPTURE意图来请求一个图像。当你发送意图时，系统会提示用户选择一个相机应用(如果还没有默认的相机应用程序)。用户使用选定的拍照应用程序拍照，该应用会将照片返回到应用的onActivityResult()方法中。

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. 当你执行操作时，你的应用程序可以完全控制用户体验。但是，这种广泛的控制增加了任务的复杂性，因为您需要设计一个适当的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. 用户被提示在运行时或在安装时给予权限(取决于用户的Android版本)。在此之后，你的应用程序可以在不需要用户额外交互的情况下执行操作。但是，如果用户不授予权限(或稍后撤销)，则应用程序就无法执行操作。

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. 您不需要为操作设计UI。处理意图的应用程序提供了UI。但是，这意味着您无法控制用户体验。用户可以与你从未见过的应用互动。

• 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. 如果用户没有默认的应用程序，系统会提示用户选择一个应用程序，如果用户没有指定一个默认的处理程序，那么他们每次执行操作时都要经过一个额外的对话框。

3.2、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.

每次你要求得到权限，你就强迫用户做出决定。您应该最小化发出这些请求的次数。如果用户运行的是Android 6.0(API级别23)或更高版本，每次用户尝试一些需要获得权限的新应用程序时，应用程序就必须使用权限请求来中断用户的工作。如果用户运行的是早期版本的Android，那么用户在安装应用时必须给予每个应用的权限;如果这个列表太长或者看起来不合适，用户可能会决定不安装你的应用。出于这些原因，您应该最小化应用程序需要的权限数量。

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.

通常，你的应用程序可以通过使用意图来避免请求权限。如果某个功能不是应用程序功能的核心部分，那么应该考虑将工作交给另一个应用程序，正如在考虑使用意图时所描述的那样。

3.3、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.

如果用户正在运行Android 6.0(API级别23)或更高级别,用户要在应用程序运行时授予权限。如果你用大量的权限请求来面对用户,你可能会淹没用户和让他们退出你的应用。相反,你应该在需要权限时请求权限。

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.

在某些情况下，一个或多个权限对你的应用来说是绝对必要的。在应用发布的时候请求这些权限是有意义的。例如，如果你制作了一个摄影应用，该应用就需要访问设备摄像头。当用户首次发布这款应用时，他们对于被要求使用摄像头不会感到惊讶。不过，如果同一款应用也有一个功能，可以与用户的联系人分享照片，那么你可能不应该在第一次启动时请求READ_CONTACTS权限。相反，等待用户尝试使用“共享”功能，然后请求获得权限。

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

如果你的应用程序提供了一个教程，那么在教程的末尾请求应用程序的基本权限是有意义的。

3.4、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().

当您调用requestPermissions()时，系统显示的权限对话框显示了您的应用程序想要的权限，但没有说明原因。在某些情况下，用户可能会感到困惑。在调用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 feature before calling requestPermissions().

例如，一个摄影应用可能想要使用位置服务，这样它就可以对照片进行地理标记。一个典型的用户可能不知道照片可以包含位置信息，而他们的摄影应用想要知道位置的原因也会让人困惑。因此，在这种情况下，在调用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 call requestPermissions() 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()来请求用户进行访问。当然，并不是每个用户都要遵循这个教程，因此在应用程序的正常操作中，您仍然需要检查和请求权限。

3.5、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.

从Android 6.0(API级别23)开始，用户在运行时授予和撤销应用权限，而不是在安装应用时这样做，因此，你必须在更大范围的条件下测试你的应用。在Android 6.0之前，你可以合理地假设，如果你的应用程序在运行，它会拥有在应用程序清单中声明所有的权限。在新的权限模型下，您不能再做这样的假设了。

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

下面的技巧将帮助您在运行API级别23或更高的设备上识别与权限相关的代码问题:

• 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 list CAMERA, 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. Remember, beginning with Android 6.0 the user can turn permissions on or off for any app, even an app that targets API level 22 or lower. 使用不同的授予或撤销权限的组合进行测试。例如，一个相机应用程序可以在其清单中列出CAMERA, READ_CONTACTS, 和ACCESS_FINE_LOCATION权限。你应该对应用程序进行测试，每次打开和关闭这些权限，以确保应用程序能够优雅地处理所有的权限配置。请记住，从Android 6.0开始，用户可以打开或关闭任何应用程序的权限，即使是针对API级别22或更低的应用程序。

• Use the adb tool to manage permissions from the command line: 使用adb工具来管理命令行上的权限:

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]  ...

• Analyze your app for services that use permissions. 为使用权限的服务分析你的应用程序