Hello, my name is Narayan Kamath, and I'm a Tech Leadon the Android Framework's team.
Today, I plan to talk aboutsome of the privacy improvements we made in Android 11.
Why is privacy so important? It's because smartphonesand 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 relivethe happier moments of our lives, and last but not least, to stay healthy and fit.
Our smart devices remain exposedto a lot of information about our lives and therefore, it's important that we trust them.
It's also important that we remainin control of our data, so we can maintainthe level of privacy we want.
At Android, we takeprivacy very seriously.
With each release, we're building an increasinglyprivacy centered platform.
We believe that the onusfor making privacy sensitive decisions must not lie entirely on our users.
Instead, it must be sharedbetween the users, the Android system, and apps.
Our goal is to help users understandthat they are in control of their data, to help them make informed choicesabout the data they grant access to and whom they share their data with.
In Android 10, we introducednumerous features to help protect our users' privacy, and we've receivedtons of excellent feedback from users and app developers since then.
One of our main focuses in Android 11 has been to build uponthe successes of Android 10, based on that feedback.
The features I'm goingto talk to you about today aim to provide our users more controlover how their data is used and to make the usage of that databy the platform and app developers more transparent to them.
Let's start with an interestingstatistic about Android 10.
When users were giventhe 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 systemto give our users even more control.
We are now giving users the optionsto temporarily grant permission valid for only a single use by an app.
The permission grant remains validwhile the app is in the foreground, either as a visible activityor as a foreground service.
The grant expires a short periodafter the app is moved to the background.
And app developers won't haveto make any new changes to remain compatible on Android 11, provided, of course, they are followingpermissions best practices.
I'd like to quickly segueinto these practices because I believe they're worth repeatingeven if you already heard them before.
First, we recommend that apps always checkwhether they hold a given permission before performingany action that requires it.
This stage should not be cachedor persisted to storage as it can get out of syncwith the system state.
Furthermore, apps should fail gracefully enough within an appropriate subsetof their functionality in cases where the userdeclines a permission.
Now that the permissionsbest practices are done with, let me present another interesting pieceof statistical trivia to all of you.
When users were reminded that apps were accessingtheir location in the background, more than two-thirds of them decidedto restrict access to background location.
Based on that, we madesome changes to Android 11 to make background location use clearerand more actionable for our users.
To access background location in your app, you must first obtaina foreground location permission, that is, one of ACCESS_COARSE_LOCATIONor ACCESS_FINE_LOCATION.
If you try to request accessbackground 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 grantthe background location permission from an in-app dialog.
To obtain the permission, apps must clearly explain the featuresthat require background location via an in-context UI.
This UI should explain why a particular featureneeds background location access.
If the user chooses to permit access, the user is then directedto the system settings to complete the process.
It's important to note though that even after an app has grantedthe background location permission, users can change their mindand deny access from the settings UI.
Time for the next useful statistics, and this one is about app usage.
The average smartphone userhas about 75 apps in their device but regularly interactswith only about a third of these apps.
The remaining two thirds of these apps may not be providingmuch value to the user but are still able to access datafrom previously granted permissions.
We believe the system can do moreto help protect our users' data under these circumstances.
By default, for apps targeting Android 11, the system will automatically revokeall runtime permissions if the app has not been usedfor a certain amount of time.
To apps, this would have the same effect as a user denying a permissionvia the settings UI.
Apps following the permissionsbest practices that I talked about earlier shouldn't have to make any changes.
Users will be informed aboutthese permissions revocation via notification and can navigate to the settings UIto take further action, for example, by uninstalling an applicationthat they no longer intend to use.
This is a great example of somethingI talked about a little earlier.
Moving the onusof making privacy decisions away from the users.
Users should not have to rememberto uninstall an app they don't use or revoke a permissionthey don't want an app to use permanently.
Instead, the system should makethese choices for them when it has enough data to do so.
All right, I am going to round upmy summary of permissions related features by introducing two more improvementswe made in Android 11.
As I mentioned earlier, one of our objectives in this release is to build upon the thingsthat work well in Android 10 and to extend those successful patternsto other parts of the system.
The first improvementis to foreground services.
In Android 11, we are addingtwo new foreground service types for camera and microphone access, by making these changesto better protect the sensitive data and to provide users more transparencyabout how this data is accessed.
If your app targets Android 11, any foreground servicethat accesses microphone or camera data must declare these types using the foregroundServiceTypemanifest attribute.
And if your foreground serviceneeds access to different data, such as both the microphoneand the camera, as shown in the example here, you can declare them togetherin the foregroundServiceType.
The second improvementis the scoped storage.
As many of you know, we first launchedscoped storage in Android 10.
Since then, we've listenedto all of your feedback and made changes to the feature that makes it clearerfor users to understand and easier for developers to adapt to.
First off, scoped storage will be mandatoryfor all apps targeting Android 11.
Apps and scoped storage can contributeto certain well-defined collections without any permissions.
However, they cannot modifyor 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 pathsand native libraries.
All apps running on Android 11 are restricted from accessing the contentsof external app storage directories outside of their own.
Finally, we will introducea special app access permission for certain qualifying apps that permits them to manageall files in shared storage.
There is far too muchto cover here, though.
My colleague Roxana will go into more detailsin this topic in a separate video, so please make sure you tune into thatif you want more detail on how scoped storage works in Android 11.
I'd now like to introducean Android 11 feature to better scope application access to the list of appsinstalled on a given device.
On Android 10 and earlier, apps could query the full listof installed apps in the system.
In most cases, this is far broader accessthan is necessary for an app to implement its functionality.
Therefore, apps targeting Android 11 will now have to specifythe list of apps they need visibility to.
They will not be able to queryany apps outside of the specified list.
The list is specified by the queries manifest tagwe've introduced in Android 11.
As shown in this example, one way of specifying queryable apps is by explicitly listingthat package name.
The PackageManager methodsthat return results about other apps, such as queryIntentActivities, are filtered based onthe calling app's declaration.
Explicit interactions with other apps, such as starting a service or an activity, also require the target appto match one of the declarations in the queried element.
As another slightly more flexibleexample of queries usage, apps can specify a broader categoryof apps they need visibility into based on matching an intent further.
The example here permits the declaring app to enumerate the list of installed appsthat permit JPEG image sharing.
The query style can also be usedin many other ways, so please head over todeveloper.
com to learn more.
In addition, we've also introduceda Query All packages tag for apps that really need accessto every installed package in a given device.
However, we expect thatthe vast majority of apps will not need this level of access.
In addition to declaring the setof packages an app needs to query, we've also addeda few intent flags to Android 11, then what having to makethe 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 wantsto take users directly to a native app that can handle it, assuming one's available, of course.
If the app was to usethe code snippet shown here, the user may get to choose a dialog as a browser could also handlethis intent just as well.
This may not be desirableas it adds friction to this user flow.
In Android 11, apps can now usethe REQUIRE_NON_BROWSER activity flag to optimize this experience.
In this example, the startActivity callwill now throw an exception if no default native appscan handle this intent.
This permits the senderto handle the intent differently, for example, by displaying contentin an in-app or a custom tab.
I'd like to end the session todayby talking about a feature we built to help developers better understandtheir patterns of data access.
The feature is complimentaryto the general team of better scoping or restricting access to sensitive data, because by understandinghow their apps use sensitive data, developers can be more transparentto users about their accesses and even the wide accessall together in some cases.
We've identified several challengesthat app developers face in understanding their useof sensitive data.
For starters, apps may useseveral SDK libraries from third parties.
These libraries might thenaccess sensitive data based on a permission grantedfor an entirely different purpose.
Such access is not easyfor developers to identify.
Second, large apps often have large teamsof developers working on them, and like most software projects, they can suffer from fragmented ownershipand abandoned code.
Therefore, we're providing two new APIs to help developers controlhow their apps access sensitive data.
The first API is a callbackwhenever data is accessed, and the second more advanced APIpermits developers to attribute access to logical features within their app.
In this picture, each blue linerepresents a piece of code in the app and the green linessymbolize access to sensitive data.
As you can see, it's quite possible for multiplepieces of code or functionality to access a particular pieceof sensitive data, and it's not always easy to tellwhere and how that's happening.
On Android 11, we've introduceda new API that instructs the system to call back intoan app's specified handler each time the app accesses sensitive data.
The handler is provided informationabout the type of data being accessed and can record other details– for example, the stack traceof code accessing the data or can even compute the frequencyand timing of these accesses.
This example shows a callbackbeing set up by the appOpsManager.
The callback can notify different classesof access from your app.
For example, access via a synchronous callto the appOpsManager or permission guarded methods, and also access viaasynchronous callbacks to the app, for example, when a callback listener in the appis provided with sensitive data.
There's a lot more, though, so please do head overto developer.
com for more details.
We also recognize that complex appsoften contain multiple distinct features.
For example, a mapping appmight have a navigation and a Find Friends feature.
Each of these featuresuse a subset of sensitive data.
For example, the Find Friends featuremight not need to use the microphone.
In Android 11, we allow for an appto attribute a subset of its code as belonging to a specified feature.
This can be done by creatingan attributionContext via a specified attributionTag and using that consistentlythroughout a given feature area.
The system will then providethe attributed tag on all data access callbacksfrom that feature area.
We hope this will make itmuch easier for developers to better track and controldata access within their apps and help provide transparency, build trust, and protect user data.
Well, that's pretty muchall I have for you today.
I hope I managedto give you some insights into the principles that guidethe evolution of Android as a privacy-centric OS.
In the interest of time, I have only covered a subset of featureswe built for Android 11.
We will cover others in follow-up sessionsand on developer.
Please be sure to read more about them and provide feedbackvia the public bug tracker.
As I said, many of the changeswe 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 hardto protect our users' privacy, and there's more to comein future Android releases.
Thank you, everyone.
Stay safe and stay healthy.
See More Android: https://zika-news.com/category/android/