Shulou(Shulou.com)06/02 Report--

This article introduces what is the authority mechanism of Android M, the content is very detailed, interested friends can use it for reference, I hope it can be helpful to you.

Content introduction

Prior to the release of the Android M version, the permission model in the Android system was handled in a relatively simple and crude manner-- that is, binary choices that were all allowed or not allowed by the user at the time of installation. This means that if users want to use an application, they first need to accept all the permission requirements contained in it or simply abandon the installation. As a result, the programming results of many developers are abandoned by users when they are installed, and it is impossible to really realize the trust relationship between users and developers and even other means of privacy protection.

Under the new permission mode, users will be able to audit various permissions at run time according to their actual needs, and turn off some of them at any time. In today's article, we will learn how to deal with new changes in permission mechanisms and their actual impact on the developer and user experience.

It is worth emphasizing that this article was written before the official release of Android M, so some of this information may change in the future.

1. Which parts require corresponding permissions?

Although AndroidM still requires developers to declare permissions in AndroidManifest.xml, users can now audit or revoke the permissions used by the application at run time. The most important change in this new version of Android is that android.permission.INTERNET and android.permission.WRITE_EXTERNAL_STORAGE have recovered from dangerous ratings to normal ratings. This means that we no longer need to apply to users for both before using it.

When issuing a permission audit request, the user will need to provide authorization to them based on the permission group, rather than auditing individual permissions within the group. This means that if our application needs to send and receive SMS messages at the same time, then users only need to approve SMS permission groups. The following is a list of supported permission groups in Android M developer Preview 2 that can be seen directly from the system settings.

It is also important to note that Android is a powerful Intent system that allows developers to access data from other applications. Instead of applying for camera access and developing an app that can use Camera API, you can now ask users to take an image using an existing trusted photo app to help their app get the image material they need. These camera-related permissions will be handled by the photo app, not the application itself.

two。 How do I ask for permission?

When you need to use a function that requires a permission audit mechanism, the system executes a series of event processes. We first need to check to see if the permission has been allowed by the user.

If the user has not previously approved this permission, you can prompt the user in the form of a permission request dialog box. When the permission request dialog box pops up, the user needs to choose between reject or accept.

However, if users have previously rejected the relevant permission request and face the same request again, they will see an additional option to stop displaying such permission request requests forever.

You can check whether the user has previously passed the permission by calling checkSelfPermission before requesting a permission. This method returns an int value based on whether the permission is approved or not.

If the return result is PackageManager.PERMISSION_GRANTED, then you can continue to follow the established design ideas. However, if this permission has not been granted before, then we need to use requestPermissions to make a request to the user, pass it with an array of permission strings, and use a custom int request code to track the logical flow of the application.

Int hasLocationPermission = checkSelfPermission (Manifest.permission.ACCESS_FINE_LOCATION); int hasSMSPermission = checkSelfPermission (Manifest.permission.SEND_SMS); List permissions = new ArrayList (); if (hasLocationPermission! = PackageManager.PERMISSION_GRANTED) {permissions.add (Manifest.permission.ACCESS_FINE_LOCATION);} if (hasSMSPermission! = PackageManager.PERMISSION_GRANTED) {permissions.add (Manifest.permission.SEND_SMS) } if (! permissions.isEmpty ()) {requestPermissions (permissions.toArray (new String [permissions.size ()]), REQUEST_CODE_SOME_FEATURES_PERMISSIONS);}

After requestPermissions is called, the user will see a dialog box containing permission group prompts for the permission items required by the application. This is a practical way to request the necessary permissions. Now, please do not ask the user to accept all the corresponding permissions at once when the application is launched.

After the user has clicked on the options in the dialog box, we then call onRequestPermissionsResult and access it in Activity. In this way, our application will be able to continue to run the rest of the functionality after the user has rejected one or more permission requests.

The following code shows how we can query the results when a permission is granted or denied. If the user rejects our request for the necessary permissions, we should disable the corresponding feature and allow the user to understand why it does not work properly in the application.

@ Override public void onRequestPermissionsResult (int requestCode, String [] permissions, int [] grantResults) {switch (requestCode) {case REQUEST_CODE_SOME_FEATURES_PERMISSIONS: {for (int I = 0; I < permissions.length; iTunes +) {if (grantResults [I] = = PackageManager.PERMISSION_GRANTED) {Log.d ("Permissions", "Permission Granted:" + permissions [I]) } else if (grantResults [I] = = PackageManager.PERMISSION_DENIED) {Log.d ("Permissions", "Permission Denied:" + permissions [I]);} break; default: {super.onRequestPermissionsResult (requestCode, permissions, grantResults);}

3. Legacy applications in Android M

Although applications developed for Android M must adopt new permissions dialogs and related implementation methods, applications built for earlier versions of Android will still display a list of permissions directly to the user at installation and ask for one-time acceptance or rejection. However, in Android M, the user can invoke the relevant permissions at any time after making a choice.

Because the underlying structure responsible for handling permission invocation tasks is not applicable to earlier Android versions of applications, when the relevant permissions are not accepted, any function that requires the relevant permissions to cooperate will return null, 0, or null values. This can lead to unexpected application behavior, so it is recommended that developers upgrade their existing applications to ensure that they support the new permissions model in Android M as soon as possible.

About what the permission mechanism of Android M is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.