Android M Permissions Review

Currently, Android users running Lollipop or below, take an all-or-nothing approach when installing or updating an app. When users attempt to install an app on the Play Store, they often find themselves faced with a wall of permissions that the app must be granted prior to being installed on the device

This approach to granting permissions presents a number of problems for the user:

Often the sheer quantity of permissions required is overwhelming
The application hasn’t had a chance to explain how it intends to use each of these permissions
Some high level permission buckets are still too vague for the average consumer to understand such as “Device & app history” in the above screenshot

Given these problems, the user typically makes a split second decision to either hit “accept” and proceed with the download or cancel the install process and make a mental note to revisit the app install at a more leisurely time.

With its announcement of Android M at Google I/O 2015, , Google is revamping its app permission model to make it more competitive with Apple’s iOS. The new permissions model is more streamlined and granular. To begin with, the user no longer sees a permission dialog during the install process. Apps are installed seamlessly with baseline permissions (such as the ability to connect to the internet) while the remaining permissions will need to be presented to and approved by the user during runtime. A nice side-effect of this is that all app updates are now seamless and can happen in the background without requiring user intervention. By asking for the permissions at runtime the user is given more context and can make well-informed decisions on which permissions to grant.

Let’s dive into the code and understand what this change in Android M means for app developers:

First, in order to use the new permission model, you must target Android M. This is done by setting the targetSDKVersion to “MNC” and the compileSDKVersion to “android-MNC”. On the preview release you must also set the minSDKVersion to “MNC”. On devices running older versions the permissions declared in the Android Manifest are granted at install time and cannot be granted at runtime. There are a few permissions that are automatically granted on install. These permissions fall under PROTECTION_NORMAL. Internet and alarm clock are examples of some of these permissions, but it is not clear what other permissions fall under this label.

Before your app needs to perform an action that requires a permission it should check if it has already been granted the permission with checkSelfPermission(String permission). This is important because the user can revoke the permission at any time. If permissions have not been granted, permissions can be requested with a call to

requestPermissions(String[] permissions, int requestCode). This is an asynchronous function where you supply an array of permissions and a request code for the callback. It generates a dialog box for the user and returns right away. You can check the response by overriding the callback method onRequestPermissionsResult(int, String[], int[]). Below is a code snippet asking to read a user’s contacts.

private static final int PERMISSIONS_REQUEST_READ_CONTACTS = 1;
private static String[] PERMISSIONS_CONTACT = {Manifest.permission.READ_CONTACTS}
 
if (checkSelfPermission(PERMISSIONS_CONTACT)) {
   Log.i(TAG,
           "Contact permissions have already been granted. Displaying contact details.");
} else {
   Log.i(TAG, "Contact permissions has NOT been granted. Requesting permission.");
   requestPermissions(PERMISSIONS_CONTACT, PERMISSIONS_REQUEST_READ_CONTACTS);
}
 
…
 
@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
   switch (requestCode) {
       case PERMISSIONS_REQUEST_READ_CONTACTS: {
           if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
               // permission was granted, yay! do the
               // calendar task you need to do.
               Log.d(TAG, "permission granted");
           } else {
               // permission denied, boo! Disable the
               // functionality that depends on this permission.
               Log.d(TAG, "permission denied");
           }
           return;
       }
   }
}

If a permission is denied by the user, the app should handle it gracefully. For a permission that is not integral for the app to function then that part of the app can be disabled to the user. If the permission is integral then all functionality might be disabled and the user notified that they need to grant that permission to use the app. The user also has the option to tell the system not to ask for that permission again. If that happens when the app calls requestPermissions(String[] permissions, int requestCode), the request is immediately denied without any user interaction. The app cannot assume any user interaction took place in the callback.

It it required to keep these checks in place because now the user can revoke any permission at any time by going into the device settings. The app is not notified when this happens. According to Google, if a permission is revoked while the app is in use the process is immediately killed, but I ran a test and the process isn’t killed at all. This may be put in a future iteration of the M preview. Users running M can also disable permissions on legacy apps. When installing a legacy app the user will see the old wall-of permissions at install/update time but they can still revoke individual permissions in the device settings. When a legacy app tries to use a permission that is revoked the app may get empty data, a null response or other unexpected behavior. For this reason it is important for developers to test their apps with the M preview and update as soon as possible. With 1.5 million apps in the Play Store, I expect some strange behavior with some of your favorite apps until they are upgraded.

For more information, visit the M documentation at developer.android.com. You can also view sample code at github.com/chap19150/AndroidMSandbox.

Filed under: Product Engineering | Topics: android, mobile apps