Android 6.0 Marshmallow brought a major change
to Android's permission model.
Instead of asking for all permissions at install time,
it introduced a runtime permission model,
letting you control when your app asked for a permission.
When and how you ask for a permission is critical.
It's kind of like asking someone out on a date.
Doing it too soon, too often, or in the wrong way
isn't going to go well for you.
I'm Nick Butcher, and in this video
I'll walk you through the details of Android's
runtime permission model and show you
how to design a UX for asking for permission
that's appropriate to your app's needs.
Now, the purpose of permissions is
to protect your users' privacy.
When you ask for a permission, you're
asking them to give up a little bit of that privacy,
and as such, you need to offer a clear and equal benefit
in exchange for that access.
Runtime permissions allow you to choose the right time
to ask for a permission when the user has more context about why
you're requesting it and the benefits of granting.
You might be familiar with runtime permissions
from other platforms, such as the web,
but the way that Android implements
them makes it incredibly important to ask
for them in just the right way.
You see, Android's permission model
favors protecting the user, so when your app requests
a permission, Android shows a dialog letting the user accept
or deny it, but it also lets them say never let this app ask
me for this permission again.
Now you want to avoid this outcome,
so we've designed the system to effectively let
you ask for permissions without having to be overly defensive.
The very first time you request a permission,
we don't show that dreaded "never ask again" checkbox.
We'll only show it after a user's denied a permission
request at least once.
You can check if you've been denied before
and be smart about when to provide more education.
This lets you build a smooth journey for your app,
only adding extra steps or information when needed.
In particular, you don't need to be too defensive, like always
screening for interest before actually requesting
a permission, essentially, asking twice.
This double prompting can be unnecessary and annoying,
and you can achieve the same effect
by asking at the right time and in the right way.
We broke down the different approaches
to asking for permissions across two dimensions.
Firstly, how important is the permission
to your app's operation?
And secondly, how clear is it why you are asking for it?
Depending on these two factors, we
recommend different approaches to how you ask for permission.
If the need for permission is both critical to your app
and obvious why it's needed, then we
recommend asking up front.
For example, if you are making an SMS app,
then the SMS permission is absolutely critical for you
to function, and it's crystal clear why you're asking for it.
Don't bother your users with any unnecessary explanations.
Just request the permission straight away.
If a permission is really important to your app, but not
immediately obvious why, then we recommend
educating before asking.
If your app uses some kind of user onboarding,
then this would be a great opportunity
to tell them about this killer feature,
then go ahead and ask for the permission.
So, for example, if a key part of your note-taking app
is that it logs the location where you made a note,
you'd want to educate your users about that up front,
and then ask for the permission.
Next up, if a secondary feature of your app needs a permission
but it's clear why, then ask in context.
For example, if your note-taking app
lets you dictate an audio note, then it's
pretty clear why this feature would need
the record audio permission.
There's no need to bombard your user too early
with this request.
Better to wait until they try to use the feature when
it will be immediately obvious why you're prompting for it.
Finally, if a feature is not core to your app's purpose
and not immediately obvious why it's requested,
then you should educate in context.
So, for example, if your note-taking app
lets you collaborate with friends,
then requesting access to your contacts might be reasonable,
but it isn't immediately obvious and would benefit
from some user education.
When the user invokes the feature,
offer some explanation of the benefits
it allows, like autocompleting email addresses,
and then let the user opt into it, only
then asking for permission.
By using the right approach, it should be clear to the user
why you're requesting a permission
and what they get for it in return.
This doesn't, however, mean that they'll grant the permission
100% of the time.
So how should you handle denial?
Now remember, Android lets you know if the user has previously
denied a permission so that you can show more
rationale to educate them on why you are asking
and the benefits of granting.
If a user denies a critical permission,
then explain why you can't proceed without it
and link to your app's settings page,
where they can rectify it.
Don't just shut down.
Now, this is especially important
as the user may have checked that "never ask again" box.
So your app may receive the permission denial
without the user seeing the permission dialog,
and it could seem like the interaction was just ignored.
Another pro tip is to always show
the user immediate benefit when they grant your permission.
Like we said, this is a trade-off
of access for functionality.
So, for example, if you are granted access
to the user's contacts, then you could immediately
present a list of their favorite contacts for quick selection.
Finally, while you're taking stock
of the permissions your app uses,
perhaps revisit if you need the permission at all.
Android offers facilities for apps to talk to each other,
letting you delegate tasks to other apps.
For example, if you want to allow users to take a photo
but it isn't a core part of your app,
consider using intents to ask the camera
app to take the photo and share it back to you.
Voila.
No need for the camera permission.
So that's Android's runtime permissions model
in a nutshell and some approaches
to asking for permissions.
Now that you understand how it works,
you can craft the perfect flow for whether, when,
and how to ask for permissions, maximizing
your chance of your users agreeing
to hook up with your app.
Thanks for watching.
For more information, check out these links.
[MUSIC PLAYING]