Learn about Android6.0 permissions

First, preface

Starting with Android 6.0 (API level 23), users begin granting permissions to the app while it is running, rather than when the app is installed. This approach simplifies the app installation process because users do not need to grant permissions when they install or update an app. It also gives users more control over the functionality of the app, for example, the user can choose to provide camera access to the camera app without providing access to the device location.

Ii. Classification of rights

System permissions fall into two categories: normal and Dangerous:

1. Normal permissions : Covers areas where the app needs to access its sandbox external data or resources, but is less risky for user privacy or other application operations.

For example, setting the time zone's permissions is normal permissions. If the app declares that it requires normal permissions, the app is automatically granted that permission.

1 Access_location_extra_commands2 access_network_state3 Access_notification_policy4 access_wifi_state5 BLUETOOTH6 Bluetooth_admin7 Broadcast_sticky8 change_network_state9 change_wifi_multicast_stateTen change_wifi_state One Disable_keyguard A Expand_status_bar - get_package_size - Install_shortcut the INTERNET - kill_background_processes - modify_audio_settings - NFC + read_sync_settings - Read_sync_stats + receive_boot_completed A Reorder_tasks at request_ignore_battery_optimizations - request_install_packages - Set_alarm - Set_time_zone - Set_wallpaper - set_wallpaper_hints in Transmit_ir - Uninstall_shortcut to Use_fingerprint + Vibrate - Wake_lock theWrite_sync_settings

Normal Permissions

2. Dangerous rights : covers the areas where the application requires data or resources that involve user privacy information, or that may affect the operation of the data or other applications stored by the user.

For example, a contact who is able to read a user is a dangerous permission. If the app declares that it requires dangerous permissions, the user must explicitly grant the permission to the app.

3. Permission groups

All dangerous Android system permissions belong to the permission group.

I, if the app requests the dangerous permissions listed in its manifest, and the app does not currently have any permissions in the permission Group, a dialog box is displayed to the user describing the permission groups to be accessed by the app. The dialog box does not describe specific permissions within the group. For example, if the app requests read_contacts permissions, the System dialog box simply indicates that the app requires access to the device's contact information. If the user approves, the system will grant the app its requested permissions.

II. If the app requests the dangerous permissions listed in its manifest, and the app has another dangerous permission in the same permission group, the system immediately grants that permission without any interaction with the user. For example, if an app has been requested and granted the Read_contacts permission, and then it requests write_contacts, the permission is granted immediately.

Any permission can belong to a permission group, including normal permissions and app-defined permissions. However, the permissions group affects the user experience only when the permissions are dangerous. Permission groups with normal permissions can be ignored.

1 group:android.permission-group.contacts2 Permission:android.permission.WRITE_CONTACTS3 Permission:android.permission.GET_ACCOUNTS4 Permission:android.permission.READ_CONTACTS5 6 Group:android.permission-group.phone7 Permission:android.permission.READ_CALL_LOG8 Permission:android.permission.READ_PHONE_STATE9 Permission:android.permission.CALL_PHONETen Permission:android.permission.WRITE_CALL_LOG One Permission:android.permission.USE_SIP A Permission:android.permission.PROCESS_OUTGOING_CALLS - Permission:com.android.voicemail.permission.ADD_VOICEMAIL -  the Group:android.permission-group.calendar - Permission:android.permission.READ_CALENDAR - Permission:android.permission.WRITE_CALENDAR -  + Group:android.permission-group.camera - Permission:android.permission.CAMERA +  A group:android.permission-group.sensors at Permission:android.permission.BODY_SENSORS -  - group:android.permission-group.location - Permission:android.permission.ACCESS_FINE_LOCATION - Permission:android.permission.ACCESS_COARSE_LOCATION -  in Group:android.permission-group.storage - Permission:android.permission.READ_EXTERNAL_STORAGE to Permission:android.permission.WRITE_EXTERNAL_STORAGE +  - Group:android.permission-group.microphone the Permission:android.permission.RECORD_AUDIO *  $ group:android.permission-group.smsPanax Notoginseng Permission:android.permission.READ_SMS - Permission:android.permission.RECEIVE_WAP_PUSH the Permission:android.permission.RECEIVE_MMS + Permission:android.permission.RECEIVE_SMS A Permission:android.permission.SEND_SMS thePermission:android.permission.READ_CELL_BROADCASTS

Permission Groups

Iv. Checking Permissions

If your app requires dangerous permissions, you must check whether you have that permission each time you perform an action that requires this permission. Users are always free to call this permission, so even if the app used the camera yesterday, it can't assume that it still has that right today.

To check if you have a permission, call the Contextcompat.checkselfpermission () method. For example, the following code snippet shows how to check if Activity has permission to write in the calendar:

int permissioncheck = contextcompat.checkselfpermission (thisactivity,        Manifest.permission.WRITE_ CALENDAR);

If the app has this permission, the method returns packagemanager.permission_granted, and the app can continue the operation.

If the app does not have this permission, the method returns Permission_denied, and the app must explicitly ask the user for permissions.

V. Explain why permissions are required

For example, if a user launches a photography app, the user may not be surprised that the app requires permission to use the camera, but the user may not understand why the app wants to access the user's location or contact. Before requesting permission, you might want to provide an explanation for the user.

To help find scenarios that users might need to explain, Android provides a utility method, Shouldshowrequestpermissionrationale (). This method returns true if the app has previously requested this permission but the user rejected the request.

Note: This method returns False if the user has rejected a permission request in the past and has selected the Don't ask again option in the Permission Request System dialog box.

This method also returns false if the device specification prohibits the app from having that permission.

Vi. Request permission

If the app does not already have the required permissions, the app must call a Requestpermissions () method to request the appropriate permissions. The app will pass the permissions it needs, as well as the integer request code that you specified to identify this permission request. This method runs asynchronously: it returns immediately, and after the user responds to the dialog box, the system passes the same request code passed by the application to Requestpermissions () using the result call to the application's callback method.

The following code checks to see if the app has permission to read the user's contacts and requests that permission as needed:

 if   (Contextcompat.checkselfpermission ( Thisactivity, Manifest.permission.READ_CONTACTS) != Packagemanager.permi ssion_granted) { if   ( Activitycompat.shouldshowrequestpermissionrationale (thisactivity, Manifest.permission.READ_CONTACTS)) { Span style= "COLOR: #008000" >//   " else  {//
      No explanation required, direct request   Activitycompat.requestpermissions (thisactivity,  new   string[]{manifest.permission.read_contacts}, my_permissions_request_read_contacts); }}

Vii. handling the response of a permission request

When the app requests permissions, a dialog box is displayed to the user. When the user responds, the system calls the app's Onrequestpermissionsresult () method and passes the user response to it. Your app must replace this method to see if the appropriate permissions have been obtained. The callback passes the same request code that you passed to Requestpermissions (). For example, if an app requests read_contacts access, it might take the following callback method:

@Override Public voidOnrequestpermissionsresult (intrequestcode,string permissions[],int[] grantresults) {    Switch(requestcode) { Casemy_permissions_request_read_contacts: {if(Grantresults.length > 0 && grantresults[0] = = packagemanager.permission_granted) {//Authorized Success}Else{//authorization denied            }            return; }    }}

Learn about Android6.0 permissions