Hello, my name is Narayan Kamath,
and I'm a Tech Lead on the Android Framework's team.
Today, I plan to talk about some of the privacy improvements
we made in Android 11.
Why is privacy so important?
It's because smartphones and smart devices
have become an integral part of our lives.
We rely on them for a lot of things:
to perform our jobs, to educate our children and our pets,
to record and relive the happier moments of our lives,
and last but not least, to stay healthy and fit.
Our smart devices remain exposed to a lot of information about our lives
and therefore, it's important that we trust them.
It's also important that we remain in control of our data,
so we can maintain the level of privacy we want.
At Android, we take privacy very seriously.
With each release,
we're building an increasingly privacy centered platform.
We believe that the onus for making privacy sensitive decisions
must not lie entirely on our users.
Instead, it must be shared between the users,
the Android system, and apps.
Our goal is to help users understand that they are in control of their data,
to help them make informed choices about the data they grant access to
and whom they share their data with.
In Android 10, we introduced numerous features
to help protect our users' privacy,
and we've received tons of excellent feedback
from users and app developers since then.
One of our main focuses in Android 11
has been to build upon the successes of Android 10,
based on that feedback.
The features I'm going to talk to you about today
aim to provide our users more control over how their data is used
and to make the usage of that data by the platform and app developers
more transparent to them.
Let's start with an interesting statistic about Android 10.
When users were given the option to access location
only while an app is in use, users selected about half the time.
So in Android 11,
we're evolving the permission system to give our users even more control.
We are now giving users the options to temporarily grant permission
valid for only a single use by an app.
The permission grant remains valid while the app is in the foreground,
either as a visible activity or as a foreground service.
The grant expires a short period after the app is moved to the background.
And app developers won't have to make any new changes
to remain compatible on Android 11,
provided, of course,
they are following permissions best practices.
I'd like to quickly segue into these practices
because I believe they're worth repeating even if you already heard them before.
First, we recommend that apps always check whether they hold a given permission
before performing any action that requires it.
This stage should not be cached or persisted to storage
as it can get out of sync with the system state.
Furthermore, apps should fail gracefully enough
within an appropriate subset of their functionality
in cases where the user declines a permission.
Now that the permissions best practices are done with,
let me present another interesting piece of statistical trivia to all of you.
When users were reminded
that apps were accessing their location in the background,
more than two-thirds of them decided to restrict access to background location.
Based on that, we made some changes to Android 11
to make background location use clearer and more actionable for our users.
To access background location in your app,
you must first obtain a foreground location permission,
that is, one of
If you try to request access background location
and any other permission at the same time, the system throws an exception.
For apps targeting Android 11,
we've also removed the ability to grant the background location permission
from an in-app dialog.
To obtain the permission,
apps must clearly explain the features that require background location
via an in-context UI.
This UI should explain
why a particular feature needs background location access.
If the user chooses to permit access,
the user is then directed to the system settings
to complete the process.
It's important to note though
that even after an app has granted the background location permission,
users can change their mind and deny access from the settings UI.
Time for the next useful statistics, and this one is about app usage.
The average smartphone user has about 75 apps in their device
but regularly interacts with only about a third of these apps.
The remaining two thirds of these apps
may not be providing much value to the user
but are still able to access data from previously granted permissions.
We believe the system can do more to help protect our users' data
under these circumstances.
By default, for apps targeting Android 11,
the system will automatically revoke all runtime permissions
if the app has not been used for a certain amount of time.
To apps, this would have the same effect
as a user denying a permission via the settings UI.
Apps following the permissions best practices that I talked about earlier
shouldn't have to make any changes.
Users will be informed about these permissions revocation
via notification
and can navigate to the settings UI to take further action,
for example,
by uninstalling an application that they no longer intend to use.
This is a great example of something I talked about a little earlier.
Moving the onus of making privacy decisions
away from the users.
Users should not have to remember to uninstall an app they don't use
or revoke a permission they don't want an app to use permanently.
Instead, the system should make these choices for them
when it has enough data to do so.
All right, I am going to round up my summary of permissions related features
by introducing two more improvements we made in Android 11.
As I mentioned earlier, one of our objectives in this release
is to build upon the things that work well in Android 10
and to extend those successful patterns to other parts of the system.
The first improvement is to foreground services.
In Android 11, we are adding two new foreground service types
for camera and microphone access,
by making these changes to better protect the sensitive data
and to provide users more transparency about how this data is accessed.
If your app targets Android 11,
any foreground service that accesses microphone or camera data
must declare these types
using the
And if your foreground service needs access to different data,
such as both the microphone and the camera,
as shown in the example here,
you can declare them together in the
The second improvement is the scoped storage.
As many of you know,
we first launched scoped storage in Android 10.
Since then, we've listened to all of your feedback
and made changes to the feature
that makes it clearer for users to understand
and easier for developers to adapt to.
First off,
scoped storage will be mandatory for all apps targeting Android 11.
Apps and scoped storage can contribute to certain well-defined collections
without any permissions.
However, they cannot modify or delete files they don't own
without explicit user consent.
Apps with the files in media permission
can read media,
not just using the MediaStore or SAF APIs,
but now also using file paths and native libraries.
All apps running on Android 11
are restricted from accessing the contents of external app storage directories
outside of their own.
Finally, we will introduce a special app access permission
for certain qualifying apps
that permits them to manage all files in shared storage.
There is far too much to cover here, though.
My colleague Roxana
will go into more details in this topic in a separate video,
so please make sure you tune into that if you want more detail
on how scoped storage works in Android 11.
Cool. I'd now like to introduce an Android 11 feature
to better scope application access
to the list of apps installed on a given device.
On Android 10 and earlier,
apps could query the full list of installed apps in the system.
In most cases,
this is far broader access than is necessary
for an app to implement its functionality.
Therefore, apps targeting Android 11
will now have to specify the list of apps they need visibility to.
They will not be able to query any apps outside of the specified list.
The list is specified
by the queries manifest tag we've introduced in Android 11.
As shown in this example, one way of specifying queryable apps
is by explicitly listing that package name.
The PackageManager methods that return results about other apps,
such as
are filtered based on the calling app's declaration.
Explicit interactions with other apps, such as starting a service or an activity,
also require the target app to match one of the declarations
in the queried element.
As another slightly more flexible example of queries usage,
apps can specify a broader category of apps they need visibility into
based on matching an intent further.
The example here permits the declaring app
to enumerate the list of installed apps that permit JPEG image sharing.
The query style can also be used in many other ways,
so please head over to
In addition, we've also introduced a Query All packages tag
for apps that really need access to every installed package
in a given device.
However, we expect that the vast majority of apps
will not need this level of access.
In addition to declaring the set of packages an app needs to query,
we've also added a few intent flags to Android 11,
then what having to make the queries in the first place.
Let me explain one of them now.
Let's take a View intent as an example,
and assume the app firing the intent wants to take users directly to a native app
that can handle it, assuming one's available, of course.
If the app was to use the code snippet shown here,
the user may get to choose a dialog
as a browser could also handle this intent just as well.
This may not be desirable as it adds friction to this user flow.
In Android 11, apps can now use the
to optimize this experience.
In this example, the
if no default native apps can handle this intent.
This permits the sender to handle the intent differently,
for example, by displaying content in an in-app or a custom tab.
I'd like to end the session today by talking about a feature we built
to help developers better understand their patterns of data access.
The feature is complimentary to the general team of better scoping
or restricting access to sensitive data,
because by understanding how their apps use sensitive data,
developers can be more transparent to users about their accesses
and even the wide access all together in some cases.
We've identified several challenges that app developers face
in understanding their use of sensitive data.
For starters, apps may use several SDK libraries from third parties.
These libraries might then access sensitive data
based on a permission granted for an entirely different purpose.
Such access is not easy for developers to identify.
Second, large apps often have large teams of developers working on them,
and like most software projects,
they can suffer from fragmented ownership and abandoned code.
Therefore, we're providing two new APIs
to help developers control how their apps access sensitive data.
The first API is a callback whenever data is accessed,
and the second more advanced API permits developers to attribute access
to logical features within their app.
In this picture, each blue line represents a piece of code in the app
and the green lines symbolize access to sensitive data.
As you can see,
it's quite possible for multiple pieces of code or functionality
to access a particular piece of sensitive data,
and it's not always easy to tell where and how that's happening.
On Android 11, we've introduced a new API that instructs the system
to call back into an app's specified handler
each time the app accesses sensitive data.
The handler is provided information about the type of data being accessed
and can record other details--
for example, the stack trace of code accessing the data
or can even compute the frequency and timing of these accesses.
This example shows a callback being set up by the
The callback can notify different classes of access from your app.
For example, access via a synchronous call to the
or permission guarded methods,
and also access via asynchronous callbacks to the app,
for example,
when a callback listener in the app is provided with sensitive data.
There's a lot more, though,
so please do head over to
for more details.
We also recognize that complex apps often contain multiple distinct features.
For example, a mapping app might have a navigation
and a Find Friends feature.
Each of these features use a subset of sensitive data.
For example, the Find Friends feature might not need to use the microphone.
In Android 11, we allow for an app to attribute a subset of its code
as belonging to a specified feature.
This can be done by creating an
via a specified
and using that consistently throughout a given feature area.
The system will then provide the attributed tag
on all data access callbacks from that feature area.
We hope this will make it much easier for developers
to better track and control data access within their apps
and help provide transparency, build trust, and protect user data.
Well, that's pretty much all I have for you today.
I hope I managed to give you some insights
into the principles that guide the evolution of Android
as a privacy-centric OS.
In the interest of time,
I have only covered a subset of features we built for Android 11.
We will cover others in follow-up sessions and on
Please be sure to read more about them
and provide feedback via the public bug tracker.
As I said, many of the changes we made in Android 11
were based on user and developer feedback, so we'd really like to hear from you.
Rest assured we will continue to work hard to protect our users' privacy,
and there's more to come in future Android releases.
Thank you, everyone. Stay safe and stay healthy.