There are some cases where we as users have felt almost forced to install an application, giving in due to previous encounters. Take Facebook for example, a lot of users know and love Facebook. Whilst the permission list is huge, Facebook has already built a good level of trust with their users, so they’re going to install the app regardless of the number of permissions it’s asking for at the time of install.

Whilst some of these are genuinely needed as part of Facebook’s main functionality, there are likely to be some things in that list that you may just not want to grant permission to.

With Android-M, this list can be greatly reduced by

asking for permissions as and when they are required.

For example, asking for the camera permission when the user reaches the point of taking the photo would make sense. That way, if the user is never going to make use of that functionality within the app then they won’t need to grant that permission to the Facebook application at the time of install.

Permission Groups

Permissions are now collated into one of eight different groups

With Android-M, permissions will now be grouped together under a parent category, this category is what will be used when requesting a certain permission from the user. So for example, if you request access to the READ_CALENDAR permission then the user will be prompted to grant you the Calendar permission.

Many of these categories contain several permissions, which can be broken down into the following sets:

Each permission category contains a number of individual permissions

You’ll notice here that there is no longer an internet permission - great! One of the nice things is that you’re no longer required to ask for this permission, meaning you can make network requests without prompting the user to ask if it is OK to do so. This is due to this permission (along with many others) now being designated as PROTECTION_NORMAL, these are all automatically granted to the application if they are declared in the manifest.

Runtime Permissions

The install flow of apps on the play store has always felt a little broken. Clicking Install would never actually install the app, you first have to accept a number of permissions before the actual install can take place. Thankfully, permissions will no longer be asked for at this point. So when you click Install in the Google Play Store it really will install the app, rather than prompting you to accept these numerous permissions first.

At runtime, there’ll be points in your application where you need to request permissions to use certain features. At this point, you’ll need to check with the system whether you have this required permission. As shown below, the system will make a number of checks before giving you, or the user, a path on which to continue.

The system will need to make a number of checks to allow you, or the user, to continue

To begin with (1) we need to check if we have the permission(s) we require to perform an operation.

we need to check if we have the permission(s) we require to perform an operation. Next ( 2 ) the system checks whether we have the permission we need, this is done when we call the checkSelfPermission() method.

) the system checks whether we have the permission we need, this is done when we call the method. We can continue and handle the result ( 6 ) if we have the required permission, otherwise the system will next need to check if the user has already been asked to be granted this permission (3) . The standard permission dialog will be displayed to the user ( 4 ) if they have not previously been asked to grant the permission.

) if we have the required permission, otherwise the system will next need to check if the user has already been asked to be granted this permission . The standard permission dialog will be displayed to the user ( ) if they have not previously been asked to grant the permission. Otherwise, if the user hasn’t asked for the permission not to be asked for again (5) then the dialog will still be displayed to the user, this time with an additional checkbox to set this flag.

then the dialog will still be displayed to the user, this time with an additional checkbox to set this flag. However, if the flag has already been set at this step then the result will just be returned to the onRequestPermissionsResult() method (6) and the result handled within the code.

When we request a permission the user is shown a simple dialog, prompting them to either allow permission to the specificed feature or to deny it.

Permission dialog upon first request of a permission group

This is the dialog that the user will be shown the first time that the permission is requested. If they accept the request then you are granted permission to execute the desired task. However, as briefly explained above, denying the request can result in two different outcomes.

The first time the user denies the request for permission, the dialog is dismissed and you will need to handle this in some way visually. For example if you have requested access to Contacts in order to show the users contacts, then showing an error placeholder in place of the contact list would make the outcome of denying this permission clear.

Note: There is no penalty for the permission being denied the first time, so there is no need to carry out any form of double prompting.

If desired, you can use the shouldShowRequestPermissionRationale() method to check whether the application has previously requested the specified permission and been denied. This will allow error states to be correctly displayed on the screen before requesting the permission, allowing the explanation of why the permission is needed before requesting access again.

The next time that you request the same permission after it being denied for the first time, the user will be granted the option for this request not to occur again.

Permission request dialogs on subsequent appearances show an opt-out checkbox

If the user selects this option, then you will not be able to request access to that permission again for the current install. There is nothing you can do about this, so if this is a permission that is crucial to the operation of your app then it is important that you make it clear as to why you need this permission the first time access is denied.

This is another reason as to why it is important to make it really clear to users as to why your app will require certain permissions to function. One approach to do so is providing some form of walkthrough or welcome screen, outlining the functionality of your application. This will really help users to be aware of why they will be asked for permissions, whilst also hopefully being given more trust to grant them.

It is also possible to request multiple permissions during the same request. In most cases this won’t be necessary and should not used unless it is really crucial. A good use-case for this is at app launch where the app can’t function without the required permissions. For example, an SMS app that requires access to contacts in order function would be able to ask for both the SMS and Contacts permissions when the app is launched.