Hi. My name is Sara N-Marandi.
And I'm a Product Manager on the Android privacy team.
Welcome to week three of 11 Weeks of Android:
Privacy, Trust, and Security.
I'm sure many of you have already seen the video
on All things privacy in Android 11.
If not, make sure to check it out
to hear about all the new features in this release.
Today, I want to talk about how you can develop privacy forward apps
with the latest features in Android 11.
With each release, we're making Android a more private platform
by reducing the scope of permissions
and bringing more users user control.
We believe building privacy forward apps
should be core to app development and not just an afterthought.
And many of our developers feel the same way
as they strive towards building privacy-friendly apps for their users.
But developers also tell us that it's not always easy
to incorporate all the new features and changes
that we introduce in every release.
That is why we're dedicating this session to bringing you
best practices, tips, and guides on building privacy-centric apps.
When it comes to product development,
we're guided by a set of principles
that pivot around control, transparency, and data minimization.
Specifically, we focus on five principles.
Number one, request the minimum permissions
that your app needs.
Number two, request permissions only when your feature needs it.
In other words, in context.
And be transparent with what you're accessing.
Number three, plan for users to deny your permissions,
either in runtime or in settings.
Number four, only access data when the user is expecting it.
And number five, pay attention to permissions
required by libraries.
For the remainder of this session,
we'll talk about how to apply each principle
in the context of the Android privacy infrastructure.
Let's start with the first one.
We ask that you only use the permissions necessary
for your app to work.
Every time you ask users for permission, you're forcing them to make a decision.
Reduce the burden on the user.
If your app absolutely needs permissions,
ask in increments so the user is not overwhelmed.
Look for alternatives to common use cases
that could help you limit the number of permissions you ask.
For example, system intents, identifiers, and background for phone calls.
Be cognizant of your deny rate.
If your app is distributed on Google Play, within the Play Console,
Android Vitals tells you the percentage of users
who deny your permission in your app.
Use this to assess whether or not you should be rethinking your permissions,
and instead finding alternative ways.
Second is to request permissions only when your app's feature needs it.
And be transparent with what you're accessing.
Let's walk through an example of what this might look like.
Let's say you have a messaging app
that allows a user to share their location with another user.
Wait until the user actually taps on the feature
that needs access to location.
If you notice, in this mock,
we're letting enough space between the buttons
to avoid accidental clicks that could prompt unnecessary permissions.
Our goal is to ensure the user is willing to give the permission.
It should never feel forced or accidental.
So now, once the user actually clicks on the feature that needs the permission,
check if the permission's granted
by passing the permission into the checkSelfPermission method.
This method will either return permission granted or permission denied.
If the permission returned is denied,
then call shouldShowRequestPermissionRationale
to check whether your app should show a UI to the user.
In this UI, you should clearly explain
why this feature needs access to the permission.
Be transparent about why you're accessing, so the user can make an informed decision.
It's also important that you give the user the choice
to deny the feature within your own UI before they actually see a runtime prompt.
The runtime prompt should never be used to capture the user decision
on whether or not they want to grant the permission.
But instead, it should be used as a confirmation
that they want to use a specific feature,
and thus, willing to give you access to their private data.
So, this brings us to our third best practice.
Always plan for the user or the system to deny your permissions.
In Android 11, we have made a few changes to the deny option.
First, users will no longer see the option Deny and Don't Ask Again.
Second, we have introduced Only This Time permission option
for mic, camera, and location.
Once the user selects this option,
the app will have access to the permission as long as it remains in the foreground.
But as soon as the user moves your app to the background,
after a short period of time,
the permission will automatically be revoked.
In this scenario, the deny state will be reset,
which allows you to reprompt the user when they launch your app again.
Third, we have also introduced a new feature
for apps targeting Android 11
that automatically revoke all runtime permissions
if your app has gone on use for an extended period of time.
Again, the deny state in this scenario will be reset,
which then allows you to reprompt the user when they relaunch your app,
and tap on the feature that needs the permission.
Therefore, it is absolutely critical that you do the following.
First, expect that the user will deny your permission,
and gracefully degrade when that happens.
For example, you can disable your app's voice input feature
in a scenario in which the user declines microphone permission.
Second, you should also expect that the user may permanently
deny the permission.
To prevent this from happening, again, as we mentioned,
make sure that you ask for the permission in context,
and you allow the user to decline the feature within your own UI.
Third, make sure you use shouldShowRequestPermissionRationale API
properly, in case the user has selected Only This Time,
or the system automatically revoked the permission.
Let's talk about our fourth best practice.
Pay attention to the time and frequency in which you're accessing users' data
to make sure that it's aligned with what the user is expecting.
For mic and camera accesses,
you must provide continuous indication
whenever you're accessing these sensitive capabilities.
In Android 11, we're introducing new APIs
that will make it significantly easier for you to audit your current data access,
to assess whether or not it should be acceptable by the user.
The first API is a callback when data is accessed.
The second, a more advanced API,
permits developers to attribute access to logical features within their app.
So, you can use the first API, the callback APIs,
to track which part of your code is accessing private data.
The API instructs the system to back trace into an app's specified callback
each time the app accesses sensitive data.
The callback provides information about the type of data being accessed,
but it can also record valuable details,
such as stack trace, the frequency, and timing of accesses.
This should hopefully make it much easier for you
to untangle the mapping of your code to data access.
Finally, our fifth best practice,
pay attention to the permissions required by third-party libraries.
You inherit the permissions every time you include a library into your code.
And users will generally attribute this to your app.
You can actually use the stack traces described in the previous section
to attribute your app's code to third-party libraries.
This should make it much easier for you to track and control access by libraries,
which could ultimately help build trust with your users.
To summarize, the five principles that guide our product development
are, number one, minimum permission requests;
number two, permission requests only in contexts
when you truly need it with appropriate explanation to the user;
number three, expectations that the user will deny permissions,
either during runtime or in settings;
number four, data access that is aligned with the user expectation;
and number five, awareness of permissions required by libraries.
Finally, we are introducing a new way to request permissions.
When using the latest AndroidX activity version,
you can request permissions using an activity result registry
with the request permission activity result contract.
This removes the need for request codes and overwriting activity APIs.
As a result, it's delivered directly to your custom activity result callback.
We hope you've found this session helpful.
You can find a lot more details and documentations
at the developer.android.com site.
Thank you, everyone. Stay safe and healthy.