Android6.0 Rights Management and usage rights where to pay attention

For the first time, Android 6.0 marshmallow increased execution-time rights management, which gives users a better understanding and control over the permissions that the app involves. However, it is a more painful thing for the developer. Need to be compatible and ensure the normal execution of program functions.
What do you call permission management at execution time? Under Android 6.0, when we install the app, the app will prompt us with the permissions that the app needs, assuming you want to install it. That must be allowed to give all permissions, but if not allowed, it can only cancel the installation, a bit rogue. And after installation, you will not be able to recover this permission.
And 6.0 will do when the implementation of Rights management. Even when the installation gives permission, it can be in the system settings. To close the permission.
In several cases, because the execution of the permissions only in Android6.0 and above the mobile phone version number only, so here only consider the device version number is greater than 6.0 of the phone. The lower version of the phone has been given full access at the time of installation. It is not possible to take back, not to consider, the following situation is only divided targetsdkversion:

1. Targetsdkversion is greater than or equal to 23, then the permission is able to be recycled (revoke). This is also a privilege to be divided. Google divides permissions into two types, one is normal permission, and the other is dangerous permission.

   Normal permission refers to permissions that are not related to user privacy. Can be understood as insignificant permissions, such as access to the network. It doesn't matter to users. Dangerous permission is a privilege that will involve user privacy. such as reading user phone contacts, text messages and so on. If it is normal permission, then it will be given at the time of installation, and the interface will not be opened to allow the user to reclaim the permission. The app will always have that permission, so you don't have to consider such a type of permission. Assuming that it is dangerous permission, the permission is not granted at the time of installation. The system open interface allows users to reclaim or grant permissions. The following is the permission for an app, and the first picture is dangerous permission. Capable of being recycled and endowed.

   
   
   Click All permissions above to see all of the permissions for the app.
   
   For dangerous permission, it is necessary to check if the permission has been granted before use.

checkSelfPermission(Manifest.permission.READ_PHONE_STATE) == PackageManager.PERMISSION_GRANTED

Assuming that the permission has been granted, you can continue to execute your code, assuming that it is not granted, and that you need to ask the user if the permission needs to be granted. The popup box is the system interface, the interface such as the following:

Calling code:

requestPermissions(newString1);

The system asks if permission is granted when the page ends with a callback

 @Override  public  void   Onrequestpermissionsresult  (int  requestcode, string[] permissions, int  [] grantresults) {super .    Onrequestpermissionsresult (Requestcode, permissions, grantresults); if  (Requestcode = = 1 ) {if  (Grantresults[0 ] = = packagemanager.permission_granted) {//your implementations }else  {toastutil.show (this , ); }    }}

1. Assume that the targetsdkversion is less than 23. Then will feel that the app is not practical 23 new permissions to test, then continue to use the old rule: the system will be installed by default to the app to give full permission, the app can be executed as usual. But! But! But!

   Users are still able to reclaim permissions, but this collection is not recycled. Take a look at the page that bounced when the permission was closed:
   
   Did you see that. Assuming that targetsdkversion is less than 23, when the permission is closed. Will play a warning box to tell you that this is an older version of Android, the shutdown will be problematic, assuming you press reject. Then the permission will be closed. and the interface. The switch of the permission will show off. But this privilege has not been recycled (Nexus 5x's mobile phone is tested.) Of course, other machines I do not dare to pack tickets). Checkselfpermission returns granted. I looked down. Suppose Targetsdkversion equals 23. The System log is:
   
   Assuming that targetsdkversion is less than 23, the log is:
   Permission related app op changed.

I just assumed that if you were to support runtime permission, you'd have to set Targetsdkversion to 23. Assuming your targetsdkversion is less than 23, then add Checkselfpermission, just in case. Who knows what kind of hole Google will make.

There is the notion of a grouping, for example to:

Assuming that one of the groups is granted, the group will also be granted by default.

and also support the same time to apply for multiple permissions, details of the Android developer official website.

Here is the URL to the StackOverflow issue:
http://stackoverflow.com/questions/36328151/ive-revoke-the-android-permission-but-checkselfpermission-still-return-granted

Please state if there are any problems or errors.

Here are some things to note about Authority management.
For permissions, activity and fragment have their own requestpermissions and onrequestpermissionsresult callbacks, but activity is checkselfpermission. But fragment is not, so fragment assume that you want to check permissions, but also to call the host activity checkselfpermission.
By the way, the usual direct call checkselfpermission and Requestpermissions will report what API error, although the compilation will not pass, but look is annoying ah. able to call Activitycompat.checkselfpermission (in the SUPPORTV4 package).
First look at the requestselfpermission of the activity:

publicfinalvoidrequestPermissionsint requestCode) {    Intent intent = getPackageManager().buildRequestPermissionsIntent(permissions);    null);}

Look, here's a direct open. There is also an activity to operate, and Startactivityforresult, the callback will pass through the Onrequestpermissionresult, I think this callback should be handled in Onactivityresult. And then tune the Onrequestpermissionresult function.
So the question is, suppose I apply for a certain permission in the Onresume function, call requestpermissions, then what is the phenomenon?
The first time you enter the page, pop up the Request Permission dialog box, assuming click Allow. is normal, the dialog box no longer appears. However, assuming the first click on the rejection, click on the Reject and then re-pop the dialog to apply for permission, assuming you always point to reject. The dialog box pops up, which is why? Since the first time you enter the page and execute the Onresume function, request permission to enter a page. Pop-up dialog box, assuming you click Reject. First callback Onrequestpermissionresult, and then execute the Onresume function, then again to check the permissions, because found no permissions, then once again request, if, into a loop, unless you point to allow, otherwise is an infinite loop.

So apply for permission may not be written in Onresume, or add a flag bit inference.

Next, let's talk about fragment request permission.

publicfinalvoidrequestPermissionsint requestCode) {    ifnull) {        thrownew IllegalStateException("Fragment "this" not attached to Activity");    }    mHost.onRequestPermissionsFromFragment(this, permissions,requestCode);}

This is actually the method of invoking the Mhost request permission. Mhost is the fragment host activity, so the fragment request permission is actually through the host activity, when the permission result callback, activity inference is from the fragment or from their own activity, And then distribute the results.

There are also some more useful libraries on GitHub: Https://github.com/hotchemi/PermissionsDispatcher

Android6.0 Rights Management and usage rights where to pay attention