Posted by Sara N-Marandi, Product Manager, Android Platform Product
People want an operating system and apps that they can trust with their most personal and sensitive information. Data protection is at the core of Android’s product principles. As shared in the “What’s new in Android data protection?” Session, Android 12 is expanding this existing foundation by making the platform even more private.
This version gives users more visibility into the data apps are accessing and provides simple controls to help them make informed decisions. Android is also investing in reducing the scope of permissions so that apps can only access the data they need for the functions they provide. Let’s take a look at some of these important changes we made in Android 12 to protect user privacy.
Privacy dashboard: Users often tell us that they want to understand what data apps are using. With the new data protection dashboard, users get a simple and clear timeline view of the last 24-hour access to location, microphone and camera. You can also share more context with your app’s data usage with a new Permission Intent API in Android 12. The data protection dashboard can be tested in Beta 2.
We encourage all developers to review their code and understand the data access requirements, including those in third-party SDKs, and ensure that all access has legitimate use cases. To support this, we’ve added data access monitoring APIs in Android 11 to make it easier for you to monitor your current data access. Use the APIs to untangle your code mapping by keeping track of which part of your code is accessing private data. The data protection dashboard can be tested in Beta 2.
Figure 1. Timeline for the privacy dashboard and location access over the past 24 hours.
Microphone and camera indicators: In Android 12, we’re adding transparency to access to microphones and cameras. Going forward, users will know in real time when an app is accessing their microphone or camera feeds. Just by going to quick settings, users can see the apps that are accessing their data. If access is not warranted, users can quickly navigate to the app permissions page to revoke permissions.
Developers should review microphone and camera usage and proactively remove unexpected access. For example, you should make sure that your app isn’t accessing these sensors before the user clicks on a feature that needs access. The microphone and camera displays can be tested in Beta 2.
Figure 2. Microphone and camera indicators and switches.
Microphone and camera toggle: You may have seen people put stickers on cameras or put audio blockers on their phones. In Android 12, we’re introducing two new controls that will make it quick and easy for users to block apps from accessing the microphone and camera on the device. To ensure user safety, emergency calls are excluded.
If an app with permissions tries to access the microphone or camera but the user has turned off the sensors, the system displays a message to inform the user that they need to turn the sensors back on in order to use the app’s functionality to be able to use. If your app follows permissions best practices, you don’t need to do anything else to incorporate the toggle status. The microphone and camera can be tested in Beta 2.
Approximate location: In the last two versions, we made the location permission fine-grained. First we separated the background and foreground access. We then added the “This Time Only” option to further restrict access to the background location. We see that users respond positively to these controls and select them more often. When enabled, about 80% of the time, users will choose to share less about access to the foreground location.
In Android 12, we’re giving users more control over their location data. Users have a clear choice as to the accuracy of the location made available to the app by choosing the approximate location.
We recommend that you check your use case for location and request
ACCESS_COARSE_LOCATION When your functions don’t require the exact location of the user. You should also be prepared for users to decrease location accuracy. Please make sure your app continues to work when users choose approximately. The approximate location can be tested in Beta 1.
Figure 3. Location Permission Request dialog box with approximate and precise choices
Notification when reading the clipboard: Content copied to the clipboard can contain sensitive information because users often copy emails, addresses, and even passwords. Android 12 notifies users every time an app reads from their clipboard. Users see a toast at the bottom of the screen every time they access an app
getPrimaryClip() . The toast will not appear if the clipboard data is from the same app. You can minimize access by checking it first
getPrimaryClipDescription() to learn more about the nature of the data on the clipboard. It is recommended that you only access the clipboard if the user understands why it was accessed. A clipboard read notification is available to test in Beta 2.
Device authorizations nearby: Android 12 minimizes data access by adding a new runtime permission for nearby users who are not using a location. Previously, apps like watch and headphone companion apps required location permission to search for nearby Bluetooth devices to pair. We heard from users and developers that this was confusing and resulted in permission to access location data when it wasn’t needed. With apps for Android 12, you have the option to decouple device detection near the exact location permission for use cases such as device pairing using the new option
BLUETOOTH_SCAN Permission and by explanation
usesPermissionFlags=neverForLocation . Once the device is paired, apps can use the new one
BLUETOOTH_CONNECT Permission to interact with it. Apps that search Bluetooth by location must still have location permission. Nearby device entitlements can be tested in Beta 1.
App hibernation: Last year we started automatic permissions reset. If an app is not used for a long time, Android automatically revokes the permissions for the app. In the last 14 days, the permissions for 8.5 million apps have been reset. This year we’re building on permissions that are automatically reset by intelligently hibernating apps that have not been used for an extended period of time – optimizing for device storage, performance, and security. Not only does the system revoke permissions previously granted by the user, but it also stops the app and reclaims memory, storage and other temporary resources. Users can wake apps up simply by launching the app. App hibernation can be tested in Beta 1.
Android 12 is our most ambitious privacy release to date. Along this path, we’ve worked closely with our developer community to create a platform that puts privacy first while taking into account the impact it has on developers. We thank you for your continuous feedback and support in keeping our platform private and secure for everyone. Please visit the developer page for more information on these changes.