[MUSIC PLAYING]
SARA N-MARANDI: Hello, I'm Sara, and I'm joined today
by my colleague Yacine.
We're excited to be here, and thank you for being with us.
We appreciate the time you have invested in talking to us,
sharing your experiences, and providing us with feedback.
Over the next 20 minutes, we will
provide an overview of the privacy
changes we introduce in Android 12,
share best practices on how you can make
your apps private by design, and provide
a look at a few concepts we're considering
for future release of Android.
Users care deeply about privacy.
They consistently tell us that they
want to know us that protects their privacy
and treats their data with care.
And it's no surprise.
As more of our day to day core functionalities
move to the mobile device, people
will naturally seek out devices that will keep them
and their data safe.
And from day one, on Android, we have
designed privacy for everyone.
Particularly over the last several releases,
we've made significant strides in keeping
users' information safe.
We've done this by relentlessly focusing
on three core principles.
First, by adding transparency around what data
is accessed by apps and when.
Second, providing simple controls for users
so they can make informed choices
about enhancing or limiting apps' access to their data.
And third, focusing on data minimization,
to reduce the scope of permissions
so users are not surprised by the data that
leaves their device.
As the Android platform evolves, it
continues to provide tools and guidance
to help developers integrate privacy friendly features
into their apps.
For the remainder of this presentation,
Yacine and I will provide best practices
on how to confidently provide more transparency by making
sure your users aren't surprised that you've accessed
their data, how to provide controls while respecting
users' choice, and how to reduce access to data by minimizing
use of permissions.
So let's start with the first best practice, paying attention
to data accesses.
As Android adds more and more transparency to the OS,
it is increasingly more important for developers
to pay attention to their data accesses.
In Android 12, we're adding transparency
to microphone and camera accesses.
Going forward, users will know in real time
every time an app accesses their mic or camera.
By simply swiping down in Quick Settings,
users can click on the indicators
to view the apps accessing their data.
If the access is unwarranted, users
can quickly navigate to the app permission page
to revoke the permissions.
You should review your code of microphone and camera,
and proactively remove unexpected accesses.
For example, make sure your app is not accessing these sensors
before the user has clicked on the feature that needs access.
Users often tell us that they want
to understand what data apps are actually using.
With the new privacy dashboard, users
will have a simple and clear timeline
view of the last 24 hour accesses by mic, camera,
and location.
For the remaining runtime permissions,
users will see whether or not an app accessed their data
in the last 24 hours.
We encourage all of you to review your code path
and make sure all accesses can be justified for your use
cases, including third party SDKs, which
will be attributed to your app.
Users care deeply about why apps access their data.
The Play Store will include a data safety section
to provide users with easy to understand information
about app data usage, allowing them
to make more informed decisions about which
apps they want to install.
Users can feel safer and more confident
that developers will use their data responsibly.
Please make sure you check out our ADS talk,
Get Prepared for Data Safety Section, to learn more.
We know how sensitive content copy to clipboard data can be.
Users frequently copy emails, addresses, and passwords.
Android 12 notifies users every time
an app reads from their clipboard data.
Users will see a toast at the bottom of the screen each time
an app calls Get Primary Clip.
The toast doesn't show if clipboard data originates
from the same app.
You can minimize access by first checking
Get Primary Clip Description to learn about the type of data
that is in the clipboard.
The recommended best practice is to only access the clipboard
when the user understands why.
Now, to prepare for the new transparency features
on Android, we recommend developers
to first do an audit of their code for unexpected accesses.
You can use the auditing APIs to untangle
the mapping of your code by tracking which
part of your code is accessing private data,
and track and control data access by third party SDKs.
The API instructs the system to invoke
an app specified callback each time the app accesses
sensitive data.
The callback provides information
about the type of data being accessed,
and lets you record the stack traces
and timing of the access.
You can also provide a rationale for users
to help them understand why your app accesses location, camera,
and microphone information.
The rationale can appear on the privacy dashboard
UI, your app's permission screen, or both.
In order to implement, you first need
to add an activity that, when started,
provides some rationale for why your app accesses the data.
Within this activity, set the Android permission attribute
to Start View Permission Usage.
If your app targets Android 12 or higher,
you must explicitly define a value for the Android exported
attribute.
Then add the intent filter to the activity.
You can add Android Intent Action View Permission
Usage for your app's permission page,
and/or you can add Android Intent Action View Permission
Usage for period for the privacy dashboard.
Depending on which intent filter you add,
users will see an information icon next to your app's name.
For further information about data access auditing
APIs and permissions intent, please reference a recent blog
published titled "Increasing User Transparency
with Privacy Dashboard."
OK, so a few takeaways for developer
when it comes to permission accesses.
First, make sure your app is only accessing data
when a feature needs it.
Second, pay attention to permissions
added by libraries in your merge manifest.
For example, you could merge manifests
to see what permissions are used by what library dependencies.
Please refer to our blog post titled,
"Getting to Know the Behaviors of Your SDK Dependencies."
And third, make sure you're not excessively accessing users'
data.
Moving to our second best practice,
it's to respect the user's choice.
Android offers users control that provides means for them
to make informed decisions about who
can access their private data and how much access
they're willing to share.
It's about balancing choice with safe defaults.
It's important that you provide the users choice
and respect their decision.
Our research shows that the more informed users are
about why apps need access to their data, the more likely
they are to engage.
For example, one recent study showed
users are less likely to deny permissions when
requests include a rationale.
It is critical that you explain to users why you need access
to their data.
In Android 12, we've added additional controls
for location.
Next time an app needs location, users
will have a clear choice to reduce the accuracy provided
to the app by selecting an approximate location.
We encourage all developers that need location
to review your use case and only request Access Course
Location if your feature doesn't need the user's
precise location.
It's important that you explain to users
why your feature needs access to a location
and progressively request fine.
Always be prepared for the users to only grant you coarse.
Your app should still work.
Here's an example of an app that has two features, one that
needs access to coarse location only,
and another that needs access to fine location.
If a user taps on a feature that needs coarse,
check to see if you should present a rationale by calling
Should Show Request Permissions Rationale API.
If the API returns true, then present the user
with a rationale, followed by approximate location
permission dialog by requesting Access Coarse Location.
If later, the user clicks on a feature that needs fine,
then you can present the user with an upgrade dialog
by requesting Access Fine Location.
As always, make sure users understand your location use
case before requesting access.
In Android 12, we're adding two new controls,
which allows users to quickly cut off
all access to microphone and camera on the device.
In case users launch an app that needs access to the sensors,
they will be notified to quickly turn the sensors back on.
This is not the same as permissions being denied.
The system will take care of the end to end flow
and will let users know if toggles are muted.
Apps don't need to do anything differently.
And as part of this launch, we're
also limiting motion sensor sampling rates to 200 hertz.
Users also tell us that they're overwhelmed by the number
of notifications they get.
They want to have more control over which apps
get to communicate with them.
In the future release of Android,
we're adding a new notification permission.
This permission will work like all other permissions,
and it will require the user to grant the app
access before an app can send user notifications.
If your app needs to send users notifications, going forward,
please declare post notifications in your manifest.
You can check access to notifications
using the existing notification manager,
our notifications enabled method.
Please note that this is consistent with how
you request all other permissions on Android.
So takeaways for developers.
Number one, please make sure users
understand why your app needs access to their data.
Second, always be prepared for the user or the system
to deny permissions and respect user's choice
when they deny the permission the second time.
Third, don't ask for all permissions at once.
Gradually request based on the feature user has invoked.
And finally, gracefully degrade when the user denies or revokes
a permission.
I'll now hand it over to Yacine to tell you
more about best practices for minimizing user permissions.
YACINE REZGUI: Thanks, Sara.
Being respectful of the user's choice in terms of permissions
is always a recommendation for good user experience,
and Android offers alternative APIs
to access sensitive information with less friction and better
privacy control by the user.
Here's a highlight of the main ones.
One way you can minimize data access in Android 12
is by adding a new runtime permission
for nearby connection.
Up until now, companion apps for devices such as watches
and headphones required the location permission
to scan for nearby Bluetooth devices.
We heard from users and developers
that this was confusing and, not to mention,
over granting location when apps just wanted Bluetooth.
Going forward, companion apps can
connect to the associated devices
by requesting the new nearby permission.
Up until API level 30, your app had
to request the Bluetooth admin permission
to discover and pair Bluetooth devices,
along with the Bluetooth permission
to connect with paired devices and the location permission.
When targeting API 31, you can set a max SDK to API 30
to these existing permissions in your manifest.
And at the Bluetooth scan permission,
with the user's permission flag never for location,
which tells the system that your app
won't be using it to infer the device location.
You'll also need to add the Bluetooth connect
permission to interact with Bluetooth devices.
And finally, add the Bluetooth advertise permission
if you need to make the user's device
visible to other Bluetooth devices.
Last year, we launched permissions auto-reset
on Android 11 and made it available to Android
6 and up devices via Google Play services.
If an app isn't used for an extended period of time,
Android automatically revokes permissions for the app.
Since the launch, permissions have been reset
from 8.5 million apps.
Make sure you're always checking permissions
as the system can reset your permission grants when your app
isn't used in a few months.
This year, we're building on permissions auto-reset
by intelligently hibernating apps
that have gone unused for an extended period of time,
optimizing for device storage, performance, and safety.
The system not only revokes permissions granted previously
by the user, but it also force stops the app
and reclaims memory storage and other temporary resources.
In this state, the system also prevents apps
from running jobs in the background
or receiving push notifications.
Users can bring apps out of hibernation
by simply launching them.
Similar to permissions auto-reset,
the user will be prompted when an app
has gone into hibernation, and can disable hibernation
in settings.
On the storage side, we've introduced scoped storage
on Android 10, which initiated a privacy preserving
storage approach.
With improvements on the following versions,
apps external directories aren't accessible to other apps,
and you can add and edit your own files
without requesting any permission,
while editing third party files require explicit user consent.
So if your app only adds files to shared storage,
you do not need to request any runtime permissions.
In the upcoming months, we'll release a new feature
called photo picker, which allows
you to read images and videos selected by the user
without requesting any permission.
Selectable media includes the photos and videos
stored on the device, but also from cloud providers
like Google Photos.
By using this feature instead of custom made photo picker,
you can stop requesting any runtime permissions to access
all photos and videos.
The photo picker will be available on Android 11
plus devices through a Google Play system update.
To invoke the photo picker, you'll
need to launch the action pick images intent
and specify both the max number of selectable media
and allow types, whether photos and/or videos.
Once the user has selected files,
you'll get back their URIs through the clip data property
and can read them via the content resolver.
We will release a support library as well
to help strike the media selection by using
the photo picker when available, and the storage access
framework as a fallback on older devices, file content
reading, and metadata fetching easier for developers.
We're also working on bringing more clarity
for users and granularity for developers with new storage
permissions.
On the next version of Android, the new permissions,
read images, will allow you to read all images and videos
on the shared storage, while real audio will allow
you to read all audio files including playlists files
like [INAUDIBLE] and 3u.
Thanks to scoped storage, adding and editing your own files,
whether they are media files or not,
does not require any permission.
Non-media files in the shared storage
are still accessible through the storage access framework.
To apply these changes in your manifest,
set a max SDK to API 31 on the Read External Storage
permission, and add the new permissions
based on your app's features.
Manage External Storage can be used
for apps that have a cool use case, requiring a broad access
to files on a device.
Keep in mind that this permission
is subject to the all files access policy on Google Play.
To sum up these recommendations, request as little
as possible location access, and always
prefer coarse then fine permission.
Use the new Bluetooth permissions,
as they don't require the location permission,
if you don't need to derive physical location.
And prepare your app for the photo picker,
which avoids requesting any storage permissions by instead
allowing users to choose specific images to share
with your app.
Thank you for watching this talk,
and feel free to ping us on Twitter to share your feedback.
Bye.
[MUSIC PLAYING]