Android6.0如何在运行期间申请权限Requesting Permissions at Run Time_requestsystempermission

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.
从6.0开始，app在运行期间让用户授权权限，不再是在安转期间，这个方法简化了安转过程，从此用户在他安转或者更新app的时候不再需要授权权限，他也给用户更多的控制应用程序的功能，举个例子。一个用户可以选在相机权限二部选择地理位置权限，用户可以在任何时候去app的设置界面撤回权限，

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.
正常的权限对用户隐私没有没有直接的危险，如果你app清单文件中列的都是正常的权限，系统自动给这些权限授权。

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.
危险的权限可以让app 访问用户机密的数据，如果清单文件有危险的权限，用户对你的app必须明确的给批准认可。
1
2

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版本中，你的app需要声明两种权限在你的清单文件中，但是声明的作用依赖于不同的系统版本号和你的app targetsdk
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.

如果你的设备运行在5.1版本或者更低，你的app targetsdk版本号低于22.如果你列出了危险权限在你的清单文件中，用户必须在安装事授权这些权限，否则系统就不会安装这个app。
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.
如果你的设备运行在6.0或者更高，必须在清单文件中声明，并且在app运行时，必须请求每一个危险的权限，用户可以授权或者拒绝每一个权限，并且app可以继续执行有限的功能即使用户拒绝了权限请求

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

下面的章节介绍了如何使用support lib来检查请求权限，Android底层从6.0版本提供了许多方法，使用这些支持库是简单的，因为你的app在调用这些方法前不需要坚持使用的是哪一个Android版本。

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.
如果你的app需要一个危险的权限，你执行某些操作时如果需要某个权限，必须每次都检查无论你是否已经有过该权限，用户经常取消该权限，所以即使app昨天使用过相机，但是不能假定今天仍有这个权限。
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() 方法，下面这个代码片段展示了如何检查当前的activity是否有Manifest.permission.WRITE_CALENDAR权限。
// 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.

如果app有权限。这个方法会返回一个int值 PackageManager.PERMISSION_GRANTED，这个app可以继续进行操作，如果app没有这个权限
会返回 PERMISSION_DENIED，并且app需要向用户请求这个权限。

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.
如果你的app需要你一个你在清单文件中列出的权限，你必须询问用户授权这个权限，Android提供了一些方法你可以用来请求这些权限，调用这些方法会显示一个标准的你不能自定义的dialog，

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.
在很多情况下，你很想帮助用户明白你为什么需要哪些权限，举个例子，如果用户启动一个相册相关的app，用户可能不会惊讶向用户请求使用相机的权限，但是用户可能不明白为什么app需要访问用户的位置和联系人信息，在你请求权限之前，你应该考虑对用户有一个合理的解释，记住不要请求一个权限使用太多的解释，用户可能会觉得糟糕并且卸载了他。
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.
一个可以用的方法是当用户关掉个权限请求时你提供一个合理的解释，如果用户依然使用需要申请改权限的功能，但是依然关闭权限请求，可能是用户不明白为什么app 需要申请这个权限来支持这个功能，向这样的情况，展示一个解释是一个很好的主意
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,同样如果设备禁止app有这个权限也会返回false。

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

如果这个app不再拥有这个需要的权限，app必须调用requestPermissions()来请求权限，你的app通过你想要的权限，和为这个权限指定的一个请求码，这个方法是异步的，等用户回应对话框，系统回调方法回传结果和请求权限事的请求码。
// 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.
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

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:
当你app 请求结果时，系统会展示一个对话框，当用户回应时，系统会回调你apponRequestPermissionsResult的回调方法，传回用户的处理结果，你的app需要重写这个方法来查出用户是否授权了这个权限，这个回调方法会回传请求权限时的请求码，举个例子，请求读取联系人的权限你可能会收到回调方法

@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
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

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.

在对话框上，系统介绍了你所需要请求的权限，他不在列出指定的权限，举个例子，如果你请求联系人的权限，系统对话框仅仅询问你的app去访问设备联系人，用户仅仅需要授权一次为每一个权限组，如果你的app请求其他的权限，系统会自动的授权，当你请求这个权限，系统会调用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.

注意 你的app 仍旧需要明确的请求权限，即使用户已经授权过其他的权限在同一个的权限组，另外，权限组会在将来的发布版本中可能会有变化，你的代码不应该依赖特定的权限或者是不在同一个权限组。

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.
如果用户拒绝了权限请求，你的app应该采取合理的行为，举个例子，你可以展示一个合理的理由去解释为什么不能拒绝你所请求的权限，
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.

当系统询问用户授权权限时，用户有一个操作告诉系统不要再次询问这个权限授权问题，在这种情况下，任何时候APP使用requestPermissions方法去请求权限，系统都会立即拒绝这个请求，系统会去调用你的onRequestPermissionsResult()这个回调方法并且传递拒绝授权，如果用户拒绝你的权限请求也是同样的处理结果，这就爱意味着当你调用requestPermissions（），你不能再次直接的和用户交互。