[MUSIC PLAYING]
SVETOSLAV GANOV: So I'd like to share a little bit how
I got here today.
I had to set up an alarm at 5:30.
I had to snooze it several times before I woke up.
After that, I took my dog for a walk.
And I like to listen to some music while I do this.
Huge trance fan, by the way.
After I finished walking my dog, I
had to check my calendar so I know
exactly where I need to be so I don't go on the wrong stage.
And lastly, I had to check my bus schedule.
And I realized I was late.
So I ran real fast and I made it.
It's funny-- my wife still thinks I'm a runner.
And actually I am.
I run every day to catch the bus.
[LAUGHTER]
CHARMAINE D'SILVA: And good morning, everyone.
My name is Charmaine D'Silva, and I'm
a product manager on Android.
Like Svet, I spend my days driving to meetings.
Some days I get to travel to meet all of you
and find my way to new cities.
And after all the excitement of my days,
I get to say good night to my boys
before I end my day with my favorite TV shows.
Of course, my favorite TV shows have dragons these days.
Now, pausing to think about both our stories,
you must have guessed by now that all of this
was achieved on our smartphones.
But our stories are in no way unique.
Every day, billions of people around the world
use the applications that you've built
to connect with people around the world
and do incredible things.
However, our users tell us that they want more transparency
and control over their data.
They expect Android as a platform
to give them tools for that transparency and control.
This responsibility to our users is something
that you've all taken very seriously.
And that's why we're here today.
We're here to talk to you about the new privacy features
in Android Q and how you can leverage them
to build privacy-forward apps.
SVETOSLAV GANOV: Over the years, Android has matured.
We've added a wide range of features
to protect our users, like file-based encryption,
runtime permissions, lockdown mode, Google Play
Protect, and many more.
On Android, we embrace privacy as a way to innovate.
And Android has always been designed with security
and privacy at its core.
In Android Q, we wanted to go further.
We added almost 50 features related
to privacy and security.
So these features are designed to provide more protection,
user control, and transparency.
To develop these features, we worked very closely
with many of you.
We shared our ideas, our designs, our prototypes.
We heard your feedback and we embedded this back
into our products.
We couldn't have done this without you.
So thank you all so much.
CHARMAINE D'SILVA: As Svet mentioned,
you've spent countless of hours with us
through workshops, filing bugs, and testing our betas,
helping us understand the issues you face
and enabling us to serve you better.
We will continue to build apps that matter.
None of this could have been possible without all of you
all.
Thank you all for your support.
SVETOSLAV GANOV: We're so grateful to have developers
like you help us build a better platform.
So now we want to help you build privacy-forward apps that
delight your users.
CHARMAINE D'SILVA: Through the rest of this journey,
we will share with you best practices
and introduce you to the new features in Android Q.
Let's get started.
SVETOSLAV GANOV: So starting with permissions.
As you already know, applications
run in their own sandboxes.
So your application to access user data
needs to request specific permissions.
In Android 6.0, we introduced the concept
of front-end permissions.
This allows your application at runtime to prompt the user
[INAUDIBLE] private data.
And the user can choose to deny or approve the request.
CHARMAINE D'SILVA: As Svet mentioned,
users have the ability to approve or deny requests.
We're always curious to understand
what users do with our devices.
When we survey our users to understand why they actually
deny permission, these are the top three reasons we see.
One, the app should not need the permission.
Two, they expect the app to still work without permission.
And three, they feel like they can grant permission later.
All of this tells us one thing.
Users who deny permissions do not understand the value
when the app is asking for it.
With this in mind, let's talk about how
best to deal with permissions.
OK, step 1.
Determine if there are alternate APIs
to give you the data that you need.
If there are alternate APIs, choose
to use them instead of asking for permission.
Alternate APIs tend to be narrow in scope, which makes
them a better privacy choice.
Let's go through a few examples.
Let's assume the app needs to do SMS verification.
Instead of asking for the SMS runtime permission,
you could instead use the SMS retriever API.
SVETOSLAV GANOV: SMS verification
is a common use case for which developers
ask for the SMS permission.
Fortunately, Google Play services
has dedicated API for exactly this use case.
The entry point is the SMS Retriever Client and domain
method is startSmsRetriever.
CHARMAINE D'SILVA: Here's another example.
What if your app need to know if the user was in a phone call?
Instead of asking for the READ_PHONE_STATE permission,
you can instead call the Audio Focus API to see call state.
SVETOSLAV GANOV: Detecting whether the user is in a phone
call are common reasons apps are asking
for the phone permission.
But there is a better way.
You can use the Audio Focus API.
If the user is currently in a phone call,
you will not be able to gain Audio Focus.
All you need to remember is to use the audio manager compact
and request Audio Focus method.
CHARMAINE D'SILVA: Last example.
What if your app needed access to external storage?
You do not necessarily need to ask for the read
external storage permission.
You can instead leverage your app's private app storage
or use a system file picker.
SVETOSLAV GANOV: Apps often request the storage permission
without taking advantage of their dedicated folder
on external storage, which does not require holding the read
and write storage permission.
The way you get this folder, you call
context.getExternalFilesDir.
Also, the system provides ways for you
to bring trusted system UI for the user
to pick a file or directory so you can work with it.
The way can bring the chooser UI is to fire
the ACTION_OPEN_DOCUMENT.
And the way to bring the UI to pick a folder
is to fire the ACTION_OPEN_DOCUMENT_TREE.
These are just a few examples how you can use APIs
without asking for permissions to provide better user
experience.
Please go to the Android Developer website
to learn more.
CHARMAINE D'SILVA: OK.
So now you've done your research and realize
there are no alternative APIs to give you
the data that you need.
You're now at step two--
determining the scope for the permission
and how you'd ask for it.
In speaking to many developers like yourself,
you'll believe that you will get higher acceptance rate if you
ask for permissions upfront.
However, when we poll our users, we see that only 18% of users
accept every permission of the device.
Most users make deliberate choices.
SVETOSLAV GANOV: Now that I think about it,
I'm one of those people that always approves permissions.
But if I think a little bit more,
I do it only if I understand the use case
and there is an immediate value for me as a user
if I grant a permission.
CHARMAINE D'SILVA: And Svet's experience
is not unlike our users.
When we ask a user why they choose to give an app access
or permission, the top reason they say
is because they wanted to use a specific feature off an app.
This tells us that they were intentional with their choice.
Users are more likely to give your app access to permission
if they understand the purpose and the perceived benefits
feels logical.
Let's go through examples of where
the benefit of the granted permission is very clear.
SVETOSLAV GANOV: So, if the context is clear,
ask for permission directly.
And this way users will know exactly why
the permission is needed.
They have context and there is an immediate value
for the user.
And there is a higher probability
of the user granting the permission to the application,
thus using your feature.
For example, if you're in a chat application
and you want to share a photo, and you click the Camera
button, the user will not be surprised
if they're asked for the camera permission.
And they'll probably grant you the permission, because they
want to use your feature.
CHARMAINE D'SILVA: So, in this scenario
that Svet ran you through, the use case is pretty obvious.
But that's not always the case.
There are situations where you need
to educate the user of your feature benefit
before the runtime prompt is shown.
It's better to present the use case right
before the runtime prompt.
Here's an example from Nest Home/Away Assist feature.
This dialog precedes the location runtime prompt.
In Android P, this is what the location runtime prompt
looks like.
The user choice is binary.
Users can choose to either approve or deny
the location request.
If a user provides location permission to an app,
the app can now access location in the foreground
or in the background.
In Android Q, we're introducing more granular controls
to the app.
Users can give the app the choice
to have only foreground access to the location or foreground
and background access to location.
As an app developer, only ask for background app access
if you only have a clear need for it.
SVETOSLAV GANOV: Now that the location permission
can be requested while in access and all the time,
you need to choose the right scope that best
fits your feature.
Our recommendation is whenever possible,
use while in use location.
The way you ask for while in use location is exactly the same.
You ask for location, as always.
You ask for the coarse or fine location permission.
However, if you want to access location in the background,
you need to add an additional modifier permission called
access background location.
So this permission needs to be combined
with the existing fine and coarse location permissions.
And this is a signal to the platform to show UI to the user
where they have choices between while in use, all the time,
and deny the request.
Scope is also relevant to storage.
In Android Q, we add in the concept of scope storage.
Scope storage provides better application data isolation
and also protects the collections
of videos and audio.
Later today, we have another talk which goes in details.
And please attend that.
CHARMAINE D'SILVA: OK.
So now at this point, you've got your app's
get runtime permissions.
You now have a responsibility to use the data.
Step three, ensure users are not surprised with your data usage.
Here are some best practices.
One, collect only the data that you need.
Two, only share the data once you get explicit user consent.
Three, if you're transferring data off the device,
ensure that it is encrypted and secure.
Four, only keep data for as long as you need it.
By following these best practices,
your users will feel more comfortable with how
their data is being used by your application.
Now, this concludes our section on permissions.
Let's talk through other areas in Android Q.
SVETOSLAV GANOV: Now that we're finished with permissions,
another area we focused our attention
was device identifiers.
In Android Q, we're locking down hardware-based device
identifiers.
So, instead of hardware device identifiers,
you need to use software-based, user-resettable device
identifiers.
This is a much more privacy-friendly solution.
We also randomize the MAC address.
This feature shift in Android P, as an experimental feature
under developer options, where we use different random MAC
address when the device connects to different networks.
Now we're bringing this feature mainstream
available to all apps all the time.
CHARMAINE D'SILVA: Another area we focused on
was app launching and notifications.
This area is important to build user trust
that users feel like they're in control of their device.
Apps launched into the foreground
can sometimes feel intrusive and disruptive
to the user experience.
Notification APIs can be used to notify
the users without interrupting their user flow.
There are two main benefits.
One, the users maintain context.
And two, do not disturb rules that are actually maintained.
For cases of alarms and incoming calls,
you can ensure a full-screen experience when the device is
locked or heads-up notification, like in this example, when
the device is in use.
This is why it's completely interrupting the user.
So I will explain to you how you can implement this in your app.
SVETOSLAV GANOV: So the recommended way
to involve the user is to use a notification
API you're all familiar with.
The only thing to remember is the setFullScreenIntent API,
which allows you to set an intent, which
will be fired off if the user is not actively using the device.
So if the device is locked, the user
will see a full-screen experience.
If the user is currently using the device,
they will see the heads-up notifications Charmaine
mentioned.
And this will not interrupt the user flow
while still letting the user know there is something
requiring their attention.
CHARMAINE D'SILVA: An Android Q background app launching
will be blocked.
Apps will no longer be able to launch themselves
from the background to the foreground.
This ensures that users are appropriately interrupted
and respects their context and do not disturb settings.
We're now on our last leg of our journey--
foreground services.
Foreground services are a lightweight way
to run an application when it is not visible in the foreground.
But foreground services can be noisy.
Try to limit your use of foreground services
to tasks that are a continuation of an ongoing activity,
like navigation.
SVETOSLAV GANOV: To improve the user experience, in Android Q,
we're introducing the concept of service types.
And we'll be limiting permission usage
based on the service type.
For example, if your application has while in use location
permission and you want to use location in a foreground
service, you need to annotate your service
as being location type.
The way you do this is using the foreground service type
attribute in the declaration in the manifest of your service.
And if you don't do this, you will not
get location delivered to your application
while this service is running.
So, we've covered a lot of privacy features and best
practices.
And there is a lot more you can learn on the Android Developer
website.
CHARMAINE D'SILVA: If you want to learn more
about these features, please attend these other privacy
sessions.
Or come talk to us in the sandbox.
Thank you all for joining us today and giving us
this opportunity to work together.
Let's continue the conversation and keep
building privacy-forward apps.
Thank you, all.
[MUSIC PLAYING]