An example of Android applying for permission when the program is running

Here we write a small example by calling to apply for permission, that is, call_ Phone is listed as a dangerous permission because calling involves the tariff of the user's mobile phone. Before the Android 6.0 system appeared, the implementation of the call function was actually very simple. Modify the activity_ The code in mainxml is as follows:

Only one button is defined in the layout file. When the button is clicked, the logic of making a call will be triggered, and then the code in mainactivity will be modified as follows:

You can see that in the click event of the button, we build an implicit intent, and the action of the intent is specified as intent.action_ Call, which is a built-in phone call action of the system, and then the protocol is Tel and the number is 10000 in the data part, which means that the dialing interface is opened. This does not need to declare permission, but intent.action_ Call can make calls directly, so the permission must be declared. In addition, in order to prevent the program from crashing, we put all operations in the exception capture code block.

Next, modify the androidmanifest.xml file and declare the following permissions:

In this way, we have realized the function of making calls and can operate normally on mobile phones lower than Android 6.0 system. However, if we run on mobile phones with 6.0 or higher system, clicking the make call button will have no effect. At this time, observe the log in logcat and the following error will be reported:

We are prompted with permission deny in the error message. It can be seen that it is caused by permission being prohibited, because systems 6.0 and above must handle runtime permissions when using dangerous permissions.

Let's try to fix this problem and modify the code in mainactivity as follows:

The above code covers the completion process of the running permission. Let's analyze it in detail. To put it bluntly, the core of the running permission is that the user authorizes us to perform some dangerous operations during the program running. The program can't perform these dangerous operations without authorization. Therefore, The first step is to judge whether the user has authorized us. With the help of the contextcompat. Checkselfpermission() method, the checkselfpermission() method receives two parameters. The first parameter is context. There is nothing to say. The second parameter is the specific permission name. For example, the permission name of the caller is manifest.permission.call_ Phone, and then use the return value of the method and packagemanager.permission_ Compared with crane, equality means that the user has been authorized, and inequality means that the user has not been authorized.

It's easy to perform the logical operation of making a call directly if it has been authorized. Here, we encapsulate the logic of making a call into the call () method. If there is no authorization, we need to call the activitycompat. Requestpermissions () method to apply for authorization from the user. The requestpermissions () method receives three parameters, The first parameter is required to be an instance of activity. The second parameter is a string array. We can put the permission name to be applied in the array. The third parameter is the request code. As long as it is a unique value, pass in 1 here.

After calling the requestpermissions() method, a dialog box for permission application will pop up, and then the user can choose to agree or reject our permission application. No matter which result, it will eventually be recalled to the onrequestpermissionsresult() method, and the authorization result is encapsulated in the grantresults parameter, Here, we only need to judge the final authorization result. If the user agrees, we will call the call () method to make a call. If the user refuses, we can only give up the operation and pop up a failure prompt.

Now run the program again and click the make call button. The effect is as follows:

Since the user has not authorized us to make a call, a dialog box for permission application will pop up for the first time. The user can choose to agree or refuse. For example, click deny here, and the results are as follows:

Since the user does not agree to authorize, we can only pop up a prompt of operation failure. Next, click make call again to pop up the permission application dialog box. Click allow this time, and the results are as follows:

As you can see, we have successfully entered the call interface this time. Since the user has completed the authorization operation, then clicking the make call button will not pop up the permission application dialog box, but can call directly. You may be worried. What if I regret it in the future? It doesn't matter. The user can relate the dangerous permissions granted to the program at any time, and enter settings -- > apps -- > runtimepermissiontest -- > permissions. The interface is as follows:

Here we can close any dangerous permission granted.

The above example explanation of Android applying for permission when the program is running is all the content shared by Xiaobian. I hope it can give you a reference and support more programming tips.