Android 6.0 – Runtime Permissions – Facebook Case Study

With Android 6.0 Marshmallow, permissions have moved from an up-front approval model to a runtime model.

This is great for users, as they now have fine-grained control over what information apps can access, but it introduces new challenges when designing interactions that involve those permissions.

Installation

First, let’s take a look at the experience downloading an app fresh from the Google Play Store.

Here’s what installing Facebook looks like on KitKat (5.x):
KitKat Google Play Store

Here’s what the user experiences on Marshmallow (the dialog is only shown the first time a user installs an app post-upgrade):

App Store Training

There’s less friction during install since users don’t need to guess why the app might need access to the Phone permission in some situation.

Requesting Permissions

To illustrate how the new permission model works on Marshmallow, let’s walk through an example in the Facebook app. Imagine we want to share a picture. Let’s tap the “Photo” button.

The user is immediately shown this system dialog which formally asks for permission to access the device’s storage.

Tapping “ALLOW” will let the user proceed to select a photo. Tapping “DENY” does not allow the app access and makes subsequent requests more complicated as we’ll see shortly.

The “Second Ask” 

In an attempt to avoid an app constantly popping the system dialog, Marshmallow surfaces a “Never ask again” checkbox on subsequent “official” requests for a given permission.

second request part two two

A poorly designed app might let the user get to this state too quickly without providing additional context why the permission is required.

If that happens, it’s unlikely an average user will be able to reactivate the permission, as it’s hidden behind the “Permissions” screen for that app in settings:


Fortunately, Facebook is not a poorly designed app – the design team has figured out a sequence of interactions to ensure the permission is granted before entering this bad state.

Ask Before You Ask

In the situation where a user declines the first official request for a permission, Facebook explains to the user why it’s needed before invoking the second official request.

Summary

Overall, there are some interesting nuances to requesting permissions with the new model introduced in Marshmallow. Here’s a final diagram attempting to document the possible flows.

Flow Overview
(click to enlarge)

As you can see, there are progressively more steps the user must complete the longer the permission is withheld.

Further reading:

Brenden Mulligan wrote a fantastic reference in the art of asking for permissions on iOS.

Official documentation:


Disclaimer: I have no affiliation with Facebook, I choose it as a case study since it’s a very popular app that handles the corner cases nicely.

Advertisements