Permission processing during Android 6.0 Runtime, android6.0

Permission processing during Android 6.0 Runtime, android6.0

Request permissions at runtime

From Android 6.0 (API level 23), users are granted permissions to applications when they install programs. This method simplifies the application installation process because you do not need to grant permissions when installing or updating the application. This also gives users more control over applications. For example, a user can choose to give the camera application access to the camera rather than the location of the device. You can revoke permissions at any time by setting the application screen.

 

System permissions are classified into two categories: Common and dangerous:

• Normal permissions do not directly pose privacy risks to users. If your application list lists a normal permission, the system automatically grants the permission.
• Dangerous permissions allow applications to access users' confidential data. If your application list lists a normal permission, the system automatically grants the permission. If you list a dangerous license, the user must explicitly approve the application.

 

In all versions of Android, the normal and dangerous permissions that your application needs to declare must be included in its Application List, as stated in the Declaration. However, the impact of the Declaration is different depending on the system version and the target level of the SDK application:

• If the device runs Android 5.1 or lower, or the target SDK of the application is 22 or lower: If you have a dangerous license in the list, when the user grants permission to install the application, if they do not grant permissions, the system does not install the application.
• If the device runs Android 6.0 or later, and the target SDK of your application is 23 or higher: Permission list of the Application List, it must require every dangerous permission to be executed when the application is running. The user can grant or deny each permission, and the application can continue to run with limited capabilities, even if the user rejects the permission request.

Note:: From Android 6.0 (API level 23), users can revoke permissions from any application at any time, even if the application API level is low. You should test your application to confirm that it is in the correct action when you lose a target that requires a license, no matter what API-level application.

 

This section describes how to use Android to support library checks, requests, and permissions. The Android framework of Android 6.0 provides similar methods (API level 23 ). However, it is relatively simple to use the support library because the application does not need to check which version of Android is called before running.

 

 

Check permissions

If your application requires a dangerous license, you must check whether you have the permission to perform an operation each time and require the permission. Users can always revoke the permission, so even if the camera used the app yesterday, it cannot assume that it still has the permission today.

Check if you have the permission to call the ContextCompat. checkSelfPermission () method. For example, this code snippet shows how to check the write permission on the active calendar:

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

If the application permits this method, PackageManager is returned. PERMISSION_GRANTED, the application can continue to run. If the application does not have permission, the method returns PERMISSION_DENIED, and the application must explicitly require user permission.

Requested permission

If your application requires a dangerous license listed in the Application List, it must require the user to grant permissions. Android provides several methods for requesting permission. Call these methods to propose a standard Android dialog box that you cannot customize.

Explains why this application requires Permissions

In some cases, you may want to help users understand why your application requires a license. Taking photography as an example, if a user starts an app, the user may not be surprised to allow the app to request to use the camera, however, the user may not understand why the application accesses the user's location or contact. Before requesting a license, you should consider providing an explanation for the user. Remember, you don't want to overwhelm users to provide explanations. If you provide too many explanations, users may find the application frustrating and delete it.

One way you can use is to provide an explanation only when the user has rejected the permission request. If a user has been trying to use a function to require a license, but has been rejecting the permission, this may indicate that the user does not understand why the application needs to provide the function. In this case, it may be a good idea to explain.

When the help is found, the user may need an explanation,Android provides a utiltity method., ShouldShowRequestPermissionRationale (). This method returnsTrueIf the application requires this license, the user rejects the request.

Note:: If the user rejects the permit request in the past and selects the do not ask option again to allow the request system dialog box, this method returns false. This method also returns false if the device policy prohibits applications from having this permission.

Required Permissions

If the application does not allow its needs, the application must call a requestPermissions () method to request the appropriate permissions. The application requires you to specify the code that identifies the permission request through the required permissions and an integer. This method is an asynchronous function: it returns the effect of the system calling the callback method of the application on the result after the user responds to the dialog box. The application passes the same request code to requestPermissions ().

The following code checks that the application allows reading user contacts and requests permission if necessary:

// Here, thisActivity is the current activityif (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 application calls requestPermissions (), a standard dialog box is displayed. The application cannot configure or change the dialog box. If you need to provide any information or explain it to the user, you should call it requestPermissions () to explain why the permissions required by the application are described.

 

Handle permission request response

When the application requests permissions, the system provides you with a dialog box. When the user responds, the system calls the onRequestPermissionsResult () method of the application and transmits the user response. Your application must overwrite that method to find out if it is licensed. The same request code is passed to requestPermissions (). For example, if an application requests READ_CONTACTS to access it, the callback method may be as follows:

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

 

 

As shown in the dialog box, the system describes the permission list that allows organizations to access your applications. For example, if you request the READ_CONTACTS permission, the system dialog box only indicates that your application needs to access the contacts of the device. Once each user only needs to authorize the permission group. If your application requests any other permission groups (listed in the Application List), the system automatically assigns them. When requesting a license, the system calls your onRequestPermissionsResult () callback method and uses PERMISSION_GRANTED to pass the system dialog box in the same way if the user explicitly grants you a request.

 

Note:: The application still requires explicit requests for each license, even if the user has allowed the other in the same group. In addition, the grouping of permission groups may change the future Android version. Your code should not rely on the assumption that the specific permissions are not in the same group.

For example, assume that you have the READ_CONTACTS and WRITE_CONTACTS lists in the Application List. If you request READ_CONTACTS and the user to grant permissions and then you request WRITE_CONTACTS, the system immediately grants the permission not to interact with the user.

If the user rejects the permission request, the application should take appropriate measures. For example, your application may display a dialog box to explain why it cannot perform the operations requested by the user and requires permission.

When the system requires the user to grant permissions, the user can choose to tell the system that the permission is not required. In this case, an application uses requestPermissions () to request permissions at any time, and the system immediately denies this request. The system calls your onRequestPermissionsResult () callback method and uses PERMISSION_DENIED to explicitly reject your request in the same way. This means that when you call requestPermissions (), you cannot assume that you directly interact with the user.