Talk about Android 6.0 runtime permissions understanding

Google in August 2015, released the Android 6.0 version, codenamed "Marshmallow" (Marshmallow), which is a large part of the change in the user rights authorization, perhaps the feeling before the default authorization is unreasonable, Now 6.0 come out, make the user authority authorization becomes reasonable. This may also refer to the iOS system, only when the user needs permission to authorize the request, the purpose is to improve the user experience, of course, the user feels good, the suffering is our developers, the original rules do not apply, and now we go to adapt to the new rules, after all, Google this big tree to eat.

Original Permission Model

Before the Android 6.0 version, the permissions are all-in-one service, as long as the user installs, the Androidmanifest list of permissions will be the system default authorization, and the authorization will not be revoked. What is the disadvantage of this? Some of the permissions may not be required by the user, such as he does not want to have notification of the rights, do not want to be notified of interference, then he can not block the notice, is not required permission, he will not go away, autonomy is not his side. In some cases, malicious programs will use this permission by default to authorize malicious access to user data and attacks. So Android version 6.0, on the one hand, makes it easier for users to control their privacy, on the one hand need to re-adapt the application permissions.

Android 6.0 Permissions Model

With the new permission model, only when the permission is required to inform the user whether the authorization is authorized at runtime, not at the time of the original installation, and by default each time the page is opened at run time, you need to check whether you need permission to apply. Such a user's autonomy improved a lot, such as the user can give the app camera permissions, but can refuse to record the location of the device permissions, is afraid of location information upload and so on.

Permission Flow

In API 23, the standard process by which permissions are met:

But here is a problem, that is, in the system authorization pop-up window link, the Reminder box will have a no longer prompt check box, if the user clicks not too prompt, and refused to authorize, then the next time the authorization, the System authorization popup box will not be prompted, so we need to customize the permission pop-up popup box, Then the flowchart becomes as follows.

Permission types

In the diagram, we can see the entire permission, can be divided into system permissions and special permission authorization. System permissions are divided into normal and dangerous types. Normal: This permission type does not directly threaten the user's privacy, can register directly in the manifest list, the system will help us to authorize by default. Dangerous: This can directly to the app to access the user some sensitive data, not only need to register in the manifest list, while in use, you need to request authorization to the system. It is worth noting that there are special authorization differences, respectively, System_alert_window and Write_settings, although these two permissions are also dangerous permission types,   However, these two authorization requests are not the same as other dangerous permissions and require special handling. Normal list:

• ACCESS_LOCATION_EXTRA_COMMANDS
• ACCESS_NETWORK_STATE
• ACCESS_NOTIFICATION_POLICY
• ACCESS_WIFI_STATE
• BLUETOOTH
• BLUETOOTH_ADMIN
• BROADCAST_STICKY
• CHANGE_NETWORK_STATE
• CHANGE_WIFI_MULTICAST_STATE
• CHANGE_WIFI_STATE
• DISABLE_KEYGUARD
• EXPAND_STATUS_BAR
• GET_PACKAGE_SIZE
• INTERNET
• KILL_BACKGROUND_PROCESSES
• MODIFY_AUDIO_SETTINGS
• NFC
• READ_SYNC_SETTINGS
• READ_SYNC_STATS
• RECEIVE_BOOT_COMPLETED
• REORDER_TASKS
• REQUEST_INSTALL_PACKAGES
• SET_TIME_ZONE
• SET_WALLPAPER
• SET_WALLPAPER_HINTS
• TRANSMIT_IR
• USE_FINGERPRINT
• VIBRATE
• WAKE_LOCK
• WRITE_SYNC_SETTINGS
• SET_ALARM
• INSTALL_SHORTCUT
• UNINSTALL_SHORTCUT

Dangerous list:

Permission Group	Permissions
CALENDAR	READ_CALENDAR WRITE_CALENDAR
CAMERA	CAMERA
CONTACTS	READ_CONTACTS WRITE_CONTACTS GET_ACCOUNTS
LOCATION	ACCESS_FINE_LOCATION ACCESS_COARSE_LOCATION
MICROPHONE	RECORD_AUDIO
PHONE	READ_PHONE_STATE CALL_PHONE READ_CALL_LOG WRITE_CALL_LOG ADD_VOICEMAIL USE_SIP PROCESS_OUTGOING_CALLS
SENSORS	BODY_SENSORS
SMS	SEND_SMS RECEIVE_SMS READ_SMS RECEIVE_WAP_PUSH RECEIVE_MMS
STORAGE	READ_EXTERNAL_STORAGE WRITE_EXTERNAL_STORAGE

Version compatibility of course, Google is also considering that if it was compiled in the version prior to API 23, running on a 6.0 system, or compatible.   If it is a version of the app before 23, then the permission model goes the old mode, that is, in the Dragon mode, in the manifest list registration, the system will help us to default authorization, and can also run. However, if it is compiled in the version of API 23, it must be a new permission model, when encountering dangerous permissions, must be authorized, if not authorized, the system will prompt the crash information. Therefore, based on the development of the 6.0 System program, in the open page, you must consider whether the page needs to be authorized permission, page detection has been authorized. Implementation first step: Detect Permissions

Assume Thisactivity is the current activityint Permissioncheck = Contextcompat.checkselfpermission (thisActivity,        Manifest.permission.WRITE_CALENDAR);

Step Two: Request permission

//Here, thisactivity are the current activityif (Contextcompat.checkselfpermission (thisactivity, Manif    Est.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 respons E!    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 a//app-defined int constant.    The callback method gets the//result of the request. }}

Step Three: Process permission request results

@Overridepublic void Onrequestpermissionsresult (int requestcode,        String permissions[], int[] grantresults) {    Switch (requestcode) {case        my_permissions_request_read_contacts: {            //If REQUEST is cancelled, the result arrays is 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-check for the other        //permissions This app might request    }}

In particular, it is important to note that if the

"Android.permission.SYSTEM_ALERT_WINDOW"

"Android.permission.WRITE_SETTINGS"

These two permissions are implemented in a way that follows the previous work, encountering a situation where  If it is run on the 6.0 version of the need to go to the new permissions model, if it is running on the old version, you need to make a judgment, at this time encountered a problem is, in Google's official recommendation, in determining whether the app running system on Android M, its judgment is as follows: Build.VERSION.CODENAME.equals ("MNC"); However, in my actual adaptation, found that this sentence is invalid, and then use Build.VERSION.SDK_INT >= 23. , special treatment is required. For System_alert_window permissions, you need to send the system a ACTION_MANAGE_OVERLAY_PERMISSION. Such an action can be used at the same time Settings.canDrawOverlays() 方法进行判断之前是否已经授权过了。For write_settings permissions, you need to send the system a Action_manage_write_settings Such an action can also be used Settings.System.canWrite() . 方法进行判断之前是否已经授权过了。 具体代码：

Intent Intent = new Intent (Android.provider.Settings.ACTION_MANAGE_WRITE_SETTINGS); Intent.setdata (Uri.parse (" Package: "+ getpackagename ())"); Intent.addflags (Intent.flag_activity_new_task); startactivity (intent);

Watch out.

Before in the work, encountered a situation, if it is run on the 6.0 version of the need to go to the new permission model, if it is running on the old version, you need to make a judgment, at this time encountered a problem is, in the official recommendation of Google, in determining whether the app running system on Android m, It is judged as follows: Build.VERSION.CODENAME.equals ("MNC"); However, in my actual adaptation, found that this sentence is invalid, and then use Build.VERSION.SDK_INT >= 23.

Summarize

1. The first thing to know is that the 6.0 version of the permission model is different from the original version, is no longer unified in the manifest default system authorization, but when necessary, to the system to request authorization, improve the user experience.
2. Understand the permission detection process, a little note is that if the system permissions pop-up box is no longer reminded, we need to customize the popup window to guide users to authorize.
3. Understand the type of authority, divided into normal and dangerous type, at the same time, in dangerous also need to pay attention to, System_alert_window and write_settings These two special authorization request way, with general authorization request way different.
4. In determining whether the app is running on Android m, you can use the version number to determine the exact point.

Refer to a specific Demo:https://github.com/spikeking/wcl-permission-demo flowchart: http://blog.csdn.net/caroline_wendy/article/ details/50587230

Talk about Android 6.0 runtime permissions understanding