Android 6.0 Marshmallow has been out for almost two months now and presents some new features and concepts for developers to contend with, one of which is runtime permissions. While Apple has used this concept for a while, Android had previously asked for all permissions at install time rather than ask the user to grant permissions as needed. Granting permissions at install time is easier for a developer, who can then assume all permissions are granted at any point during runtime. However, it can be concerning for a user to grant a long list of permissions before even opening the app. Android has also provided a hierarchy of app permissions to achieve better user privacy. Some less dangerous permissions such as bluetooth and internet are granted implicitly at install time, while others such as the permission to access the contact list must be granted in-app or at runtime.
Before Marshmallow, our app mCent asked for Contacts permission at install time in order to drive many of our social features and improve the user experience. We show apps that a user’s contacts have tried and whether they found the apps useful, as well as allowing users to message their contacts. We also notify our users when their contacts join mCent so that they can interact with them. Without the Contacts permission some of our features are unusable and others are less exciting. A user who does not allow access will only see their own activity, will miss out on new app recommendations, and can only send messages to contacts who message them first.
Many of our features rely on making user connections, so it is important that users allow access to their contacts before trying to use these features. If they don’t allow access, we need to help them understand why these features are not available. For that reason we decided to ask for the contacts permission right when a user logs in.
Some users are willing to grant permission to access their contacts without context but for many, an understanding of how the contacts will be used is important. For these users our first prompt will be denied. Luckily, Android allows us a guaranteed second attempt and we can provide an explanation of why we need the permission.
This prompt will only be seen if the user logs in again or attempts to use mCent messaging. We chose to tie this prompt to messaging because it provides the most obvious value of using their contact list. Once the user has seen our explanation, they will see the system prompt to allow the contact permission. If the user chooses not to allow the permission for a second time they can also decide to block us from asking again. If this happens, there’s one last way for a user to enable contact permissions through our Contacts List view. In this screenshot we show an explanation of why the user is unable to use messaging (Surprise! It’s because we can’t access their contacts.) and a button for them to grant permission.
From here the user will either be able to accept the permission from the system dialog or, if they have blocked the dialog, they will be directed to Android settings for the mCent app where there are individual sliding switches for each permission. In the spirit of modularity, the code that checks for and requests the contacts permission can be used for any other one of the runtime permissions.
We spend a lot of time on providing a great user experience in mCent, and part of that is providing a clear explanation for why we request specific permissions. By being clear about our access, we hope to give our users a sense of security, and another reason to love mCent.