Note to developers: Android M's permission mechanism

Introduction

Before the release of Android M, the permission model in the Android system has always been handled in a relatively simple and crude way - that is, users have to make a binary choice of allowing all or not allowing all at the time of installation. This means that if users want to use an application, they must first accept all the permission requirements contained in it or simply give up the installation. This has led to many developers' programming results being abandoned by users at the time of installation, and it is impossible to truly achieve a trust relationship between users and developers or other privacy protection measures.

Under the new permission model, users will be able to review various permissions at runtime according to their actual needs and close some of them at any time. In today's article, we will learn how to deal with new changes in the permission mechanism and understand their actual impact on developers and even users.

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

1. Which parts require corresponding permissions ?

Although Android M still requires developers to declare permissions in AndroidManifest.xml, users can now review or revoke permissions used by apps at runtime. The most important change in this new version of Android is that android.permission.INTERNET and android.permission.WRITE_EXTERNAL_STORAGE have been restored from a dangerous rating to a normal rating. This means that we no longer need to apply to users for these two permissions.

When making a permission review request, users will need to authorize it based on the permission group, rather than reviewing each individual permission within the group. This means that if our application needs to send and receive SMS messages at the same time, the user only needs to approve the SMS permission group. The following is a list of supported permission groups that can be viewed directly from the system settings in Android M Developer Preview 2.

Another thing to note is that Android is a powerful Intent system that allows developers to get data from other applications. Instead of requesting camera permissions and developing an application that can use the Camera API, you can now ask the user to take an image with an existing trusted camera application to help your application get the image material you need. These camera-related permissions will be handled by the camera application, not the application itself.

2. How do I request permission?

When you need to use a feature that requires permission, the system will execute a series of events. First, we need to check whether the permission has been granted by the user.

If the user has not approved this permission before, 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 rejecting and accepting.

However, if the user has previously rejected the request for the relevant permissions and faces the same request again, they will see an additional option - to never show such permission requests again.

You can check whether the user has previously granted permission by calling checkSelfPermission before requesting a permission. This method returns an int value depending on whether the permission is granted.

If the result is PackageManager.PERMISSION_GRANTED, you can continue to move forward according to the established design ideas. However, if the permission has not been approved before, we need to use requestPermissions to make a request to the user, pass an array of permission strings, and use a custom int request code to track the logic flow of the application.

   int hasLocationPermission = checkSelfPermission( Manifest.permission.ACCESS_FINE_LOCATION );
 int hasSMSPermission = checkSelfPermission( Manifest.permission.SEND_SMS );
 List<String> permissions = new ArrayList<String>();
 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 a permission group prompt for the permission items required by the application. This is the best practice to request required permissions. Now you should not ask the user to accept all corresponding permissions at once when the application is launched.

After the user selects the option in the dialog box, we will then call onRequestPermissionsResult and access it in the Activity. In this way, our application will be able to continue to run the remaining functions after the user denies one or more permission requests.

The following code shows how we can query the result when a permission is approved or denied. If the user denies the necessary permission request, we should disable the corresponding function 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 ; i++ ) {
                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 apps in Android M

Although apps built for Android M must use the new permissions dialog and implementation, apps built for earlier versions of Android will still display a list of permissions to the user at install time and ask them to accept or deny them all at once. However, in Android M, users can invoke permissions at any time after making their selections.

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

Closing Statement

In today's article, you've learned about the new Android M permissions model and how to support it in your apps. We've also explored how to adjust apps developed for earlier versions of the system to ensure they work smoothly with new versions of Android. With this information, you should be able to ensure that your apps are ready for the next major version of Android.