Permissions – Part 4

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 the mechanism for determining missing permissions and requesting them at runtime. We’ve looked at required permissions (i.e. those that are core to the primary function of your app), but what we have yet to discuss is non-essential permissions – those which are require for some nice features your app, but are not part of the core function. For example a camera app which is denied the “Camera” permission will be pretty useless for its main function of taking pictures; but if it can also geotag pictures (for which it requires “Location” permissions), but the geotagging feature can simply be disabled if the user does not grant the permission.

Unfortunately there are no hard and fast rules regarding non-essential permissions as the correct time an place to request such permissions will be governed by the organisation and information architecture of your app. Once important thing to remember is that it is best to request such permissions in the context within which they are required. For example, to use the geotagging example, when the user has just taken a picture at the point where the geotagging would occur would be the perfect time to ask the user for the necessary permission.

It is also worth considering how obvious the need for a particular permission is. For geotagging it is pretty obvious why the “Location” permissions would be required to be able to tag a picture with the location at which it was taken. However the reason for the “Record Audio” permission that we’ll need to the next series of articles is somewhat less obvious so we need to explain why the permission is required so that the user can make a more informed decision about whether to grant or deny the permission. If the user doesn’t understand why a particular permission in needed then there is a higher chance that they will simply deny it.

Another thing to consider is overwhelming the user. It may seem tempting to simply ask for all permissions up-front because it’s easier to code it that way. This is a mistake, in my opinion. If the user’s first impression of your app is simply being asked for one permission after another then there is a high chance that they may simply exit your app and uninstall if they don’t see any immediate value from your app. It is much better to ask for the bare minimum up-front and request other permissions in context. Not only will this help the user to understand why each permission is needed (and therefore increase the likelihood of them granting the permission), but will also enable them to perceive some value from your app much sooner than if they have to wade through a number of permission requests before they even get to your app on first launch.

Another related point is to only actually ask for the permissions you need. Although this may seem pretty obvious sometimes. as software evolves over time, permissions which were once required can sometimes go out of scope and no longer be required. It is worth periodically having a review of your app’s permission requirements and remove any redundant permissions requests.

Some may be wondering why I have not incorporated shouldShowRequestPermissionRationale() check in my example code. The simple reason is that I feel that the flow of the implementation that I have is sufficiently well structured to provide further explanation of why the requested permission is required. However, for non-essential permissions which are requested in the correct context this mechanism may be a little more useful.

One final thing to bear in mind is that if the user performs a “Clear Data” on your app it will not only clear all of the data but will also reset all of the permissions. The next time the user launches your app all previously granted permissions will now be denied. While this can be useful when testing your permission implementation, it is worth bearing in mind if you are responding to customer support questions where users may have done precisely this and are complaining that they keep having to grant the same permissions.

That concludes our look at the Marshmallow permissions model. In the next series of articles we’ll be making use of the techniques that we’ve covered here.

Although no code has been added in this article, the code for the previous article is available here.

© 2016, Mark Allison. All rights reserved.

Copyright © 2016 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at http://blog.stylingandroid.com/license-information.