JOANNA SMITH: Hey everybody.
I'm Joanna Smith, and I'm here with Android Development
Patterns to walk you through our new runtime permissions model
with Android Marshmallow.
So let's take a look.
It's pretty frightening to install an app
that requests 14 different permissions.
But if your app targets Android Marshmallow,
it can now prompt users to grant permissions at runtime
instead of install time.
Now hopefully, this will help you avoid a terrifying install
dialog like this one.
Because runtime permissions are actually required for all
apps targeting Marshmallow, so there
are a few extra steps that will help you avoid those dreaded
runtime exceptions.
Because hey, it happens to all of us.
So first, check the platform.
Runtime permissions are backward compatible with older SDKs
by reverting to the original install time request.
So if your user is on an older SDK,
then you know the permission was granted
when the app was installed.
However, if your user's on Marshmallow,
then you can't be so certain.
Which brings us to the second step,
checking the permission status.
A simple call to checkSelfPermission
with the permission that you care about
will let you know whether the permission has been granted.
If it has, you're good to go.
But if not, you're going to want to request it.
Note that you want to make this check every time, because users
can also revoke permissions now.
And this is ultimately a very good thing for developers,
even if it requires a bit of extra work.
Because users will get your request for permission
in a context that provides a clear justification and benefit
to them.
And that builds user trust.
And letting them say no thanks to a specific feature
might actually make them like you a little bit more.
So moving on in our flow.
If you don't already have permission,
you can take a moment to explain why
that permission is necessary.
Paint your user a clear picture of how great this feature will
be if they grant you access to that resource.
To help you do this, there is the shouldShowReques
tPermissionRationale method.
This will help you figure out whether you have some
"'splaining" to do.
The method returns false if the user asked
not to be asked anymore or if the permission
is disabled on the device.
But the method will return true if the user previously rejected
the permission and is now trying to access the feature again.
Because this is a signal that your user
might be confused about the app behavior.
So make it clear for them.
And with that, you're ready to request the permission.
The requestPermissions method needs
the permission list that you care about, and a request code.
This asynchronous call will then pop a dialog to the user,
and their response will trigger your callback,
which is why the request code that you specify
is so important.
It'll help you identify where in your app the user is
and how to pick up the app behavior.
Which brings us around to the final step,
handling that permissions result.
In onRequestPermissionsResult, you can
check the result of this call.
So if the permission was granted,
you can use your request code to get back
to making that API call and creating
magic moments for your user.
But if the permission wasn't granted,
you're going to need to fail gracefully.
The easiest solution is to disable the feature
with some sort of clear visual signal
that this is because of the permission thing.
So you could present a dialog or update the UI text.
But you probably want to keep the UI
layout functional in case they change their mind.
So don't disable that button.
Let them get back into the flow when they care about it.
And that's how you update your app
to handle runtime permissions in Marshmallow.
One final piece of advice I have is actually
about testing these changes, because it isn't super fun
to keep bouncing between your app and the Settings app.
So check out the PackageManager's grant command
to programmatically grant and revoke permissions
on the device.
And as always, check the documentation to get started.
And keep in mind that these changes
are intended to help your users understand your app's behavior.
So don't overwhelm users by asking for several permissions
all at once.
Put these requests into context and build better apps.
[MUSIC PLAYING]