Android 6.0, also known as Marshmallow,
has a new permissions model that streamlines the app install
and auto update process.
This new model gives your users great flexibility
but you need to make sure that your app behaves
as expected when they allow or deny specific permissions.
Hi.
I'm Laurence Moroney and I'm here
today to take you through the steps that
will ensure your apps give your users the best possible
experience in Marshmallow.
Step one, set your API level and target SDK
to at least version 23.
You can see them in your gradle code here.
Also, make sure that you are using the V4 support
library to verify and request permissions.
Add it to your gradle file, if you don't already have it.
Step two, go back to your code.
When you connect to Google Play services,
you first connect to a Google API client.
It's a common step that you may have seen a hundred
times before, but before you skip over this,
it's extremely important to set your code
to handle Google API client connection failures gracefully
using the proper resolution process.
For details and code samples, take a look at the link here.
Step three, at this point you've likely
connected to Google Play services.
And it's easy to assume that once you've done this,
that you can just go ahead and call the APIs.
Well, that's mostly true.
Prior to Marshmallow, users had to agree to your permissions
before installing.
So by the time your code was running,
you could assume that you had the permissions
to do what you needed to do.
In the new model, that's not necessarily the case.
Before calling any of the APIs that require permissions,
you need to check that you have those permissions
every single time because users may have changed
the privileges granted to your app
and you may need to re-request the permissions again.
You do this by calling the check self permission
method on the activity compact fragment or contacts compact.
You can see it here.
If this call returns false, then the requested permission
is no longer available.
It might have been previously, but it isn't now.
So don't call the API.
The good news is that this request permissions method
that you can use to inform your user that you
need those permissions and that they can choose to grant them.
In the previous step, you requested the permission again
and the system would call you back with an on request
permissions result function.
So step four is to implement this callback function.
The callback gives you a request code parameter,
which you can check against the particular API call types
that you want to access.
And if it gives you the go ahead by passing
the permission granted constant, then you
can safely call the API, knowing that it's permitted.
Step five, if your user has explicitly denied a permission
to your app but your app needs that permission to continue,
you will need to manage their expectations
and help them understand what your app needs
for that specific permission to function.
You can do this with the should show request permissions
rationale method on an activity fragment or context.
So for example, here you can see that a permission has
been granted for fine location.
So UI can be generated to tell the user that.
What this UI is is up to you.
It can be as simple as a toast notification or an entirely new
activity.
It's entirely up to you.
From there, you can go into the user flow
to request permissions again but be
sure to be respectful and clear in the message that you give.
And that's it.
Android Marshmallow is the latest, greatest version
of this mobile operating system and while the permissions model
has changed quite a bit, it's pretty straightforward
to get your apps ready to use it.
By allowing users to choose their permissions when they're
relevant and in context, instead of
being overwhelmed when they first install the app,
their experience with your app will be much better.
We have some great samples that you
can look at and to see how to handle user
permissions in Marshmallow.
Thank you.
I'm Laurence Moroney and you're going to go build better apps.
[MUSIC PLAYING]