Explain Android 6.0 runtime permission management

Since the release of Android 6.0, great changes have been made in permissions. It is no longer that you can obtain permissions arbitrarily as long as you set the manifest. Instead, you pay more attention to the user's privacy and experience. You will no longer force users to refuse permissions that they should not have, and you will no longer ask for user authorization, You can access user privacy arbitrarily, and you can change permissions in time even after authorization. This is a great embodiment of the more support and attention to users made by version 6.0.

1、 Cognition

Today, let's learn about permission management in Android 6.0.

The Android 6.0 system divides permissions into two levels:

One is normal permissions, that is, ordinary permissions. Such permissions will not potentially infringe on users' privacy and security, such as access to the network, access to WiFi, etc;

The other is dangerous permissions, which will directly threaten the user's security and privacy, such as access to SMS, photo album and so on.

But what are ordinary permissions and dangerous permissions? Here are the classifications for your reference.

1. Normal permissions

Using the above permissions will not threaten user security, so such permissions can be used directly in the manifest, and will take effect directly after installation.

2. Dangerous permissions

SMS (short message)

Storage (memory card)

Contacts

Phone (mobile phone)

Calendar

Camera (camera)

Location

Sensors

Microphone

There are also differences between dangerous permissions and ordinary permissions. Ordinary permissions are single permissions, while dangerous permissions are displayed in groups. That is, when you accept a dangerous permission, you not only accept the permission displayed on the interface, but all other access permissions in the group in which it belongs will also be automatically obtained. For example, once you write_ Contacts is authorized and app has read_ Contacts and get_ The permissions of accounts. It is worth noting that such permissions also need to be registered in the manifest.

OK, just talking without practicing is not our style. We write things based on the problems we encounter, and then write them down after serious study. On the one hand, consolidate your knowledge, on the other hand, hope to help others provide some solutions.

2、 Actual combat

The actual combat part is divided into several situations, because there will be different scenarios according to our target SDK version and Android real machine version. We are familiar with ordinary permissions, so we won't introduce them. The usage scenarios of dangerous permissions are introduced one by one below:

Before introducing the usage scenario, let's take a look at my development and the Android version of the real machine.

Let's take reading SMS as an example to explain the use of the whole permission:

1. Without access rights:

First, let's design the layout as follows:

Look at the code. It's very simple. Just read the short message directly:

Then, click "read SMS in inbox" on the interface. I believe everyone will know what happened. Sure enough, the program crashed directly and logged:

The log clearly tells us that this exception is caused by lack of permission, so let's directly add the permission to read SMS to it.

2. Added permissions in manifest:

Add the permission to read text messages in the manifest. You should be happy to wait for how many text messages appear on our interface. However, the fact is very crashing:

The exception without permission appears again. Why?

Before we solve this problem, let's imagine a practical situation. If many of your existing apps use dangerous permissions, sometimes you don't know exactly where to use them, but your target version points to 6.0 like my version, and it is possible that the user's mobile phone is more than 6.0, At this time, this may happen to your app. How can you solve it if you haven't found out where dangerous permissions are used?

Then you can solve this problem:

Modify the targetsdkversion target version number in your build.gradle:

Then, the mobile phone version is still above 6.0. Let's see the results:

OK, ha ha, you're very happy. It's really OK.

So smart, you may realize something. Yes, with version 23, that is, Android 6.0 bit split line, we can draw a small conclusion:

When targetsdkversion > = 23 and the real machine version > = 23, even if the corresponding dangerous permission is added to the manifest, when the corresponding processing is not done (I will talk about how to deal with it later), the permission restriction exception will appear. At this time, the dangerous permission in the manifest does not work, but it must be declared.

When targetsdkversion < 23 and the real machine version > = 23, we get the desired access permission without any relevant processing, which indicates that the dangerous permission applied in the manifest works.

We are looking at another situation, that is, if my mobile phone is old and the 6.0 system has not been updated, what should be the situation?

This time we use a 4.4.4 simulator

The target targetsdkversion is 21 to see the result:

It's OK. 0 messages are because there are no SMS messages on my analog machine. This number has nothing to do with us. If targetsdkversion is 23, let's see the results:

It is clear that we have got the right result again.

From this, we also get a small conclusion:

When our real machine system version is < 23, whether our targetsdkversion value is greater than 23 or not will not affect the permissions we apply for in the manifest, that is, at this time, the real machine system version plays a leading role.

From the above conclusions, we should clearly know the use of access rights in the real machine, but our mobile phone is upgrading and the version will be higher and higher. Therefore, our current applications can not always support the use of low versions and do not consider giving consideration to high versions. So now app permission upgrade is an inevitable trend.

So now come back and solve the above problems. How can we solve the permission exceptions when both the real machine and the target version are greater than 6.0?

It is mainly divided into three steps:

1: Check for permissions

2: If you do not have permission, apply for permission

3: Handle permission callback

Let's take a look at these steps.

1: Check for permissions

Check whether you have permission. You can use contextcompat.checkselfpermission (context, string permission);

There are two parameters in the checkselfpermission method: the context and the requested permission.

If you have permission, please let it directly read SMS information. If you don't have permission, apply.

2: Apply for permission

To apply for permission, use:

public static void requestPermissions(final Activity activity,final String[] permissions,final int requestCode) {}

Three parameters are required in the requestpermissions method. The current activity and the requested permission can be multiple. Finally, the request code. Since there is a request code, it will have a callback, that is, the processing callback we will talk about below.

3: Handle permission callback

To handle the permission callback, you need to override the onrequestpermissionsresult method in the activity:

Then judge whether the user has authorized the permission group or refused authorization in the method. If authorized, go to get the SMS information. Otherwise, I just display a toast prompt box here.

Here again, as long as one permission in the permission group is authorized, other permissions will have permissions, which is why grantresults [0] = = packagemanager. Permission is directly used_ Granted's reason.

OK, the following is the specific interface display:

We can see that when we click to read the SMS for the first time, it will first check whether the application has permission. If not, apply. Here, an authorization dialog box is displayed on the interface. The first time we choose to refuse authorization, and then a toast will be printed in the callback to remind us that we have refused authorization, However, when we need to read the SMS again, it will also apply for authorization. At this time, we allow authorization, and then we see that the textview that displays the number of SMS displays the number of SMS. (0 here is because the simulator used does not have SMS, which is not the point.)

It's worth reminding. When we choose to refuse authorization for the first time, when we click read SMS again, there will be an additional prompt of "no more reminder" in the authorization dialog box. What happens when we refuse authorization and choose not to remind again? See the demo:

If you refuse for many times and choose not to remind, you will not apply for authorization the next time you read, but directly indicate in the callback that the user has refused authorization.

At this time, if the user has to authorize the application for some need, what should he do? In fact, it is very simple. In the callback, remind the user to manually authorize the application in the "Settings", or send a broadcast to open the setting interface, etc. it is basically the same as the reminder "permission has been rejected" I displayed. It only needs to be slightly optimized, not demonstrated here.

In fact, we have almost finished here. However, there is one method we can leave behind, that is shouldshowrequestpermissionrational. This method returns false by default, but when the user needs to apply for the permission again when he has rejected the permission application last time, it will return true. Its moral is that you have rejected it once, As a result, an authorization box pops up. You need to explain to me why you want to authorize, that is, explain why you have authorized this permission many times, so that users can know why they must authorize to complete their operations.

Let's take a look at its use:

I'll simply pop up a dialog box here to explain why this permission is used, and then call the method of the applied permission again. You can encapsulate it with the callback method for better application.

See the following interface operation:

It's almost finished here. It's just a single application permission, and multiple applications together are OK. You can try it yourself. Basically, the operation is the same. In addition, we may need to use more dangerous permissions in one application, which makes it inconvenient for us to rewrite the same code many times, Therefore, there are a lot of open source code about the permission framework on the Internet, which can be used by ourselves.

OK, it's over here. I hope you can learn some knowledge and practice more. I wish you a happy life.

The above is the whole content of this article. I hope the content of this article can bring some help to your study or work. At the same time, I also hope to support a lot of programming tips!