Android Permissions Management – When and How to Ask Users for Information

Many users revoked permissions from applications or removed applications that they’re not using.

But, of course, companies leverage other sources to obtain private information. They can get private information, such as location, SMS’s, contacts, file access, WiFi status, phone status, and much more directly from phones. Users put less trust in brands, so it is getting harder to request private information in apps.

Oftentimes, access to information about your users can be necessary for your app to function properly. So how can you effectively collect information from users in a way that doesn’t make them feel like they are being deceived? This is a small guide on how and where to request permissions to have them granted when you need them to give the best user experience.

Requesting permissions on Android

Permission requests before Android Marshmallow

First, let’s see how the API used to work vs how it works for newer Android versions. Before Android Marshmallow, all permissions were requested before an application was installed, without any explanation of why they were being requested.

This is what Facebook’s Android app used to request. Would you install an application that requests these many permissions on install?

In the beginning, the user really didn’t have control over the permissions. The only choices they had were to install or not to install the application. As always, there are some applications that take advantage of this system. They leverage the users’ ignorance and the fact that they need the app. In the old approach, there was no way to revoke permissions after installing the application.

But this wasn’t a problem just for the users. Many companies also experienced issues with this system. There was no easy way to clarify why specific permissions were needed before requesting them. The lack of context when requesting permissions made it more difficult to obtain a particular permission.

Imagine the situation when you tap on a contact’s profile picture edit button and the application requests a permission from you to access the camera. No need to clarify anything, the context does it for you.

There was one advantage to the request on installation approach: once the application was installed, the permissions couldn’t be revoked. Consequently, there was no extra logic needed to handle cases where the permission wasn’t granted, which is something that should be handled using runtime permissions requests.

Permission requests after Android Marshmallow

The runtime permissions request was introduced in Android Marshmallow (version 6.0). The applications couldn’t request all permissions at once before installation. This allowed the user to accept or deny the permissions requested while interacting with the application running in the foreground. Also, the user can now revoke or grant permissions requested by the application at any time.

Facebook permission request on runtime on Android Marshmallow

There are clear benefits for the user with this change, as the user can deny requested permissions and still install and use the application, at least partially. The permissions can be revoked/granted at any time from the application’s settings.

Best Practices

Let’s now dive into some of the best practices for requesting permissions effectively, in a way where your users will understand your intent and have no problem with giving you access to information on their device.

1. Request permission in a context where the user can understand why it is requested. For example, in the case of Facebook, when trying to upload a picture, it asks for access to the files on the device.

2. Don’t overwhelm users with the number of dialogs requesting permissions, as they can always check the “Never ask again” checkbox. After that, getting the users’ permission will be very difficult because they have to go to the settings to change it.

3. Request only those permissions that are needed at the moment, preventing bad user experience and reducing the risk of losing active users because of this.

4. If the context is not enough to justify the requested permission, an explanation of why it is needed can be shown before the actual permission request. This will reduce the risk of losing potential users because of the friction with permission granting will be lower.

5. Make sure that the application behavior is correct even if not all the needed permissions are granted. If one permission is indispensable for a feature to work, we need to inform the users of the situation and let them choose if they really want to use it. In case that the permission is not granted, we should provide some kind of information explaining why it’s not working. Some TextView or similar on the main screen of the feature will be just right.

6. Provide an easy way of undoing permission denial, providing direct access to the application’s settings on a feature screen if the permission was denied.

Our proposed changes to the API

I think that Android’s permission API is enough as it is, but together with some of Netguru’s designers, we have been thinking about how we could improve it in order to give users more security and better control of their privacy. We came up with two modifications that would be cool to have.

Request a permission for a limited time. Imagine that you open a photo-editing app, and you need to give this app the permission to access your files. Usually, people don’t use such apps every day – only from time to time. Consequently, this kind of request should ask for the permission only for a period of time (until midnight, for n hours, etc..) and then automatically revoke the permission as soon as the time elapses.

Request a permission for a single action. Another idea would to be able to ask for a permission to carry out a single action and then automatically revoke it. For example, an app for recording and uploading videos needs access to the camera and the microphone. Imagine that you provide permission only for recording one video and then the permission is revoked. In this case, users will be sure that the app won’t use the microphone to spy on them.

Of course, the above features would complement the current implementation.

What do you think? What else can be added to Android’s permission API?

Summary

We should be careful when requesting permissions with the current permissions API. We should try to provide the best user experience, and for that we need to convince the users that the application needs the permissions that we are requesting without annoying them and while giving them the maximum amount of information. This should be provided even after the permissions were denied, allowing the users to change their mind and understand the requirements later on.