With Marshmallow a new permissions model was added to Android which requires developers to take a somewhat different approach to permissions on Android. In this series we’ll take a look at ways to handle requesting permissions both from a technical perspective, and in term of how to provide a smooth user experience.

Previously we looked at how we can incorporate the logic for checking that we have the required permissions, but next we’ll look at how we can actually request the permissions that haven’t been granted.

The happy flow (for us as developers, at least) for this is that we ask the user to explicitly grant us a required permission, the user grantes it and everyone is happy. But, as we discussed previously, we need to cover the cases where the user denies us the permission we’ve requested.

Let’s first look at the logic for the happy path as this is relatively straightforward:

We have a startActivityForResult() method which is a simple utility method which other Activities must use to start the PermissionsActivity with a given set of required permissions. So the flow is pretty straightforward once we have the required permissions. However, you may be wondering why we need this – surely we launched the Activity because we already determined that we don’t have the required permissions? The reason that we need this is for some of the following edge cases – if the user leaves this Activity temporarily, and grants the permission in Settings, then returns then this flow will be followed.

But what about when we don’t have the required permissions – we’ll need to request them:

This is the core of the process. We call requestPermissions() which passes control to the OS to request the permissions that we require. I always make a point of passing both normal and dangerous level permissions here even though we get automatically granted normal permissions. The reasoning behind this is that if what is now considered a normal permission was changed to a dangerous permission in the future then everything would still work.

requestPermissions() operates in a similar manner to startActivityForResult() – we pass control to another Activity and then get a callback once that Activity completes. In this case the callback method is onRequestPermissionResult(). This checks that all of the requested permissions have been granted and either passes control back (either through finish() or invoking MainActivity, as before), or things become a little more complex: We have requested the required permission, and the user has denied it.

The first time we ask the user for a particular permission following installation the user will be given with a simple choice: Allow or deny. If they deny us permission and we request it again they will also have a checkbox labelled “Never ask again”. If the user checks this and taps “Deny” then any subsequent requests that we make for the same permission will automatically be denied. Unfortunately we have no way of knowing if this has happened we will just get a PERMISSION_DENIED response. Bearing in mind that this particular permission is critical to the operation of this app we need to further inform the user of why this permission is required and, if they still refuse to grant it, exit the app:

I have deliberately kept the actual text used here somewhat vague because every app will need to explain its precise reasons for needing the permission in question. Also, for the sake of clarity, I have no way of providing different information for different permissions as only one dangerous permission is being requested. However is a real app you will probably need to determine which permission is missing and provide appropriate information for each.

So here we can see the flow when the user initially denies the permission, exits and subsequently grants the permission:

If the user permanently denies permission (by checking “Never ask again”) the flow becomes a little more complex for the user because we cannot provide a link directly to the Permissions Settings page for our app so we need to provide some instructions to help the user:

It would be nice if we could alter the flows between the two kinds of denial. The first video shows that we have to tell the user to alter things through Settings even though we subsequently see that exit and re-launch prompts them once again to allow or deny. Unfortunately we have no way of knowing if the user has selected “Never ask again” so we have to work against the worst-case scenario.

That said we now have a relatively simple, reusable method of requesting the critical permissions for our app. In the final article in this series we’ll look at non-critical permissions and consider some best practise.

The source code for this article is available [here](https://github.com/StylingAndroid/Permissions/tree/Part3).

With Marshmallow a new permissions model was added to Android which requires developers to take a somewhat different approach to permissions on Android. In this series we’ll take a look at ways to handle requesting permissions both from a technical perspective, and in term of how to provide a smooth user experience.

Previously we looked at how we could check whether we had already been granted our required permissions, but we had no mechanism in place to request any missing permissions. In this article we’ll look at how we can include the necessary permissions checking and requesting in all of our Activities without having large amounts of duplicate code.. Please bear in mind that everything that follows is specific to Marshmallow and later (earlier OS levels have permissions granted implicitly from the Manifest declarations) but that you’ll need to implement this kind of checking if you are specifying targetSdkVersion=23 or higher in your builds.

So the first thing we need to understand is how the permissions request model works. As we have already discussed, normal permissions will be granted implicitly but dangerous permissions will require the user to explicitly grant that permission. Things are easy enough when the user grants us the required permission but we need to defend against instances where the user denies us permission. For the app we’re going to eventually be developing it may not be obvious to the user why we require the RECORD_AUDIO permission, so we need to make some provision to inform the user of why this will be needed.

From the users’ perspective, the way this works is that the user will be asked for the require permission the first time they run the app:

If they allow the permission then everything is fine and we can carry on. However, if they deny the permission then we can repeatedly ask them for the required permission:

But note that if the user has previously denied the permission being requested they will be given the option to never be asked for the permission again. If the user selects this option then any further attempts by our code to request the permission will automatically be denied without prompting the user. Clearly this can be problematic for us as developers, so we need to make allowance for it.

This can further be compounded because the user can, at any time, go in to the Settings page for our app and grant or deny any permissions required by our app. This is why it is important to check that required permissions have been granted not only at app startup, but also in each Activity as the permissions could potentially change at any time.

So the pattern that we’re going to use to manage this is to have a separate Activity which is responsible for requesting permissions, and all of the other Activities within our app will need to check that they have the permissions they require, and pass control back to the PermissionsActivity if they have not been granted.

So let’s update our *MainActivity* slightly:

We’ve moved the actual permissions check to onResume(). This is to cover the case where the user might pause our app, switch to Settings, deny a permission, and then resume our app. OK this is something of an edge case but it’s worth defending against crashes which could occur from this.

So the basic pattern that we’re implementing here is that whenever our Activity is resumed we confirm that we have the required permissions for that Activity to operate. If we don’t then we pass control to the PermissionsActivity which is responsible for obtaining the required permissions. Although this feels like a really defensive approach I feel that it really is a sensible approach which doesn’t actually require an awful lot of code. All of the checking logic in encapsulated within PermissionsChecker, and the request logic is handled in PermissionsActivity.

Having the permissions check as a relatively lightweight component is important because we can check for required permissions relatively cheaply and only make the rather more expensive Activity change to request missing permissions where absolutely necessary.

In the next article we’ll take a look at PermissionsActivity to see how we actually handle the permission requests and explore how to further inform the user why a permission is required if they deny a permission that we’re requested.

The source code for this article is available [here](https://github.com/StylingAndroid/Permissions/tree/Part2). There’s a placeholder PermissionsActivity in the code which we’ll expand upon in the next article, so it’s not fully functional code, I’m afraid.