Protect Android user privacy, start with these things

With the popularization of information technology, mobile applications are rapidly changing people's lifestyles. As the carrier of digital life, the evolution of smart devices has driven the continuous maturity of data processing technology, which has enabled applications to have a deeper control over user information. At the same time, people's awareness of privacy protection is becoming stronger and stronger. They hope to protect their privacy from being violated while enjoying the unlimited convenience brought by mobile applications. Therefore, people will prefer platforms that can protect users and data from the operating system level. This article will introduce you to Android's changes and best practices in privacy, helping you to proactively provide users with excellent privacy protection. At the same time, we also have several conceptual ideas for future Android versions to share with you.

Three Principles of Privacy Protection

△ Three principles of privacy protection

We took user privacy protection into full consideration when designing Android, and have further strengthened this concept in recent versions, making more significant progress in protecting user information security. We continue to care about user privacy, and this persistence is based on the following three core principles:

• Improve data access transparency: let users know what data the application accessed and when;
• Simplify the way users control privacy access: Allow users to easily control whether applications can access more or less user data;
• Focus on minimizing data access: Remove unnecessary data access, reduce the scope of application permissions, and prevent applications from leaking user data.

Privacy Best Practices

△ Three best practices for integrated privacy protection

Based on the three core principles of privacy protection, we will continue to provide you with a variety of tools and guidance to help you integrate privacy protection features into your applications efficiently. Here we share with you three best practices that can be considered in mobile application development. You will learn how to improve the transparency of privacy access, how to provide privacy access options while respecting the user's right to choose, and how to minimize the acquisition of unnecessary user data by minimizing privacy access.

Focus on data access

The first best practice you need to consider is to carefully consider your app's access to user data. On the one hand, this is because Android 12 makes it more intuitive for users to see how their privacy is accessed, and on the other hand, it is out of your consideration of respecting the user's wishes.

System prompts when apps access sensors

△ Android improves transparency when apps access microphone and camera

As Android becomes more transparent, you need to pay more and more attention to when your apps access user data. Android 12 lets users know more clearly when apps access the microphone and camera. Whenever the microphone or camera is accessed, users can pull down from the upper-right corner of the screen to open the quick settings, and then tap the corresponding indicator icon to see which apps are accessing the data in real time. If the user finds that they are unaware of this access, they can easily jump to the app's permission settings interface and revoke the relevant permissions. Therefore, you need to carefully review the code in your app that involves microphone and camera access and remove those unexpected access operations. For example, you should ensure that the app does not obtain data from these devices before the user triggers a function that requires access to the relevant sensors.

Application privacy data access records

We often receive feedback from users who want to know what data apps use. We have made some efforts to this end. The new privacy information center allows users to see which apps have accessed the device's microphone, camera, and geolocation data in the past 24 hours through a simple and clear timeline view. In addition, users can also see whether the app has accessed related data using other runtime permissions in the past 24 hours.

△ Privacy access within 24 hours

We recommend that you carefully review the relevant code paths in your app to ensure that every access to private data can be reasonably explained. Since the third-party SDKs used will also be counted as part of your app, you need to provide a legitimate use case description for their privacy access.

Data usage instructions for the app

△ New data security information added to the Play Store

Users are very concerned about why your app accesses private data, so when users browse apps in the Play Store, they will see a special data security clause, which provides users with intuitive and easy-to-understand information about the use of app data, thereby helping users to make informed decisions about which apps to install. In this way, users will feel more secure and have more confidence that developers will use user data responsibly.

Notification when an app reads the clipboard

△ Notification message when the application reads the clipboard

I believe you must have had this experience: a friend sends you a message, such as a username and password, and you often copy this information and paste it into another application. In this process, these key data will be stored in the clipboard and any application can read this data, creating a potential risk of privacy leakage.

Whenever an application reads data from the clipboard, Android will notify the user. Whenever an application calls the ClipboardManager#getPrimaryClip() method, Android will determine whether the application that writes and reads the clipboard data is the same application. When the two sources are different, the system will prompt the user through a message box; when the two are from the same application, no such prompt will be generated. Therefore, we recommend that your application first call the ClipboardManager#getPrimaryClipDescription() method to obtain basic information about the data in the clipboard, and determine whether further reading is required based on its type, thereby minimizing access to clipboard data. In addition, we also recommend that you do not access the clipboard at will. If necessary, it should be done with the user's knowledge and permission.

Get ready for more transparent access to privacy

To better support the privacy transparency features brought by Android 12, we recommend that you carefully review your app's code for unexpected privacy access operations. You can use the auditing API to better discover potential privacy data reading operations and access to privacy data by third-party SDKs. This API calls an in-app callback function when your app accesses sensitive data and provides it with the type of data accessed, so that you can easily find out when and under what circumstances the app reads private data.

△ Add callback function for data access operation

You can also use the permission intent API to explain to users why your app needs to access the location, camera, and microphone, helping them understand and decide whether to grant these permissions. The information you provide through this API will be displayed to users in the privacy access information panel and the permission management interface of the app.

 <!-- Add an activity that explains to the user at launch why your app is reading a certain type of data -->
 <!-- If your app is built for Android 12, you must also mark the android:exported attribute -->
 <activity android:name="DataAccessRationaleActivity"
 android:permission="android.permission.START_VIEW_PERMISSION_USAGE"
 android:exported="true">
 <!-- VIEW_PERMISSION_USAGE will display a checkable icon in the application's permission management interface; VIEW_PERMISSION_USAGE_FOR_PERIOD will display a checkable icon in the system's privacy access panel. -->
 <intent-filter>
 <action android:name="android.intent.action.VIEW_PERMISSION_USAGE"/>
 <action android:name="android.intent.action.VIEW_PERMISSION_USAGE_FOR_PERIOD"/>
 </intent-filter>
 </activity>

△ Add permission intent

The code above shows the configuration you need to make when adding a permission intent. This code adds an activity to your app that tells the user why they want to access the data when it starts. You need to set the android:permission attribute to START_VIEW_PERMISSION_USAGE. If your app is built for Android 12, you also need to add the android:exported="true" attribute. Then add an intent-filter tag, and then add android.intent.action.VIEW_PERMISSION_USAGE (displayed in the app's permission management interface) and android.intent.action.VIEW_PERMISSION_USAGE_FOR_PERIOD (displayed in the privacy access panel) to this tag as needed. In this way, users can see an icon corresponding to the app's intent-filter next to your app name. If you need to learn more about the data access auditing API and permission intents.

To sum up, when developing applications, you need to pay attention to the following points for data access:

1. Access private data only when necessary. Unnecessary data access will not only confuse users, but also increase the risk of privacy leakage;
2. Pay attention to the permission declarations added when importing third-party libraries. You can check which permissions the imported third-party libraries declare by merging the manifest. Don't let the imported SDK and third-party libraries cause your app to be removed from the shelves! This article provides you with more reference information;
3. Do not access user data excessively. If the reading of user privacy data exceeds the user's needs, it is an infringement of the user's right to know and control.

Respect user choice

The second best practice we want to share is about user choice. Android users can control which apps can access their sensitive data and the extent to which that data is accessed by apps. For developers, it is very important to master this balance.

Research shows that the more users understand why an app needs access to their data, the more likely they are to grant access. You need to balance user control with the access permissions an app grants you by providing secure defaults, so you should give users options that are easy to understand and respect their wishes.

More granular location permission options

△ Selecting the approximate location can reduce the amount of information an app accesses to the user’s location

We introduced a more granular location permission option in Android 12, allowing users to decide whether to provide only coarse location information to apps. We recommend that you carefully review all use cases in your app that require access to location information. If precise positioning is not required, please apply for the ACCESS_COARSE_LOCATION permission instead.

In any case, you should explain to users why they need to access location information, and gradually ask users for access to more precise location information according to specific accuracy requirements. At the same time, you need to consider the situation where users only allow the app to obtain rough location information, and you cannot refuse users to continue using the app just because the location information is inaccurate.

The following sample code contains two functions, one of which only needs to access the approximate location, and the other needs to obtain the precise location. When the user grants the app permission to obtain the approximate location, you need to use the shouldShowRequestPermissionRationale API to check whether you need to display the necessary permission application instructions to the user. If true is returned, you need to display your instructions and display a pop-up box for requesting the approximate location (requesting the ACCESS_COARSE_LOCATION permission).

 // Request ACCESS_COARSE_LOCATION permission
 requestPermissions(
 Context,
 arrayOf(Manifest.permission.ACCESS_COARSE_LOCATION),
 REQUEST_CODE
 )

Request ACCESS_COARSE_LOCATION permission

 if (grantResults[1] == PackageManager.PERMISSION_GRANTED) {
 // ACCESS_COARSE_LOCATION permission is granted.
 }

△ The result of processing the request

When the user uses a feature that requires precise location information in the future, you can obtain the ACCESS_FINE_LOCATION permission by displaying a pop-up window to request more precise location information. You also need to ensure that the user understands your location use case before initiating the request.

 // Request ACCESS_FINE_LOCATION permission
 requestPermissions(
 Context,
 arrayOf(Manifest.permission.ACCESS_FINE_LOCATION),
 REQUEST_CODE
 )

△ Request ACCESS_FINE_LOCATION permission

 if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
 // ACCESS_FINE_LOCATION permission is granted.
 }

△ The result of processing the request

Global permission switch

Android 12 introduces two switches, corresponding to global access to the camera and microphone:

△ Global switch for microphone and camera

These two switches allow users to quickly cut off access to the camera or microphone for all applications on the entire device. If the user uses a feature in the application that requires access to the camera or microphone, the system will ask the user whether to open sensor access immediately. This set of switches is different from directly denying access rights because the entire process of obtaining access rights is handled by the system, and the reminder to the user to enable the device is also displayed by the system, and the application does not need to perform any additional operations.

It is also worth mentioning that we have also added a limit on the motion sensor sampling rate (within 200Hz) in this update.

Notification display permission

We often hear users complain about too many notifications on their devices, so in the new version, we require applications to apply for notification display permissions from users. Applications can only send notifications to users when users want or allow them to receive notifications.

△ Limiting notification permissions can reduce the interference of notification messages

If your app needs to send notifications to users, remember to add the POST_NOTIFICATIONS permission declaration in the manifest file. The following code shows how to apply for notification permissions:

 // Send a notification to the user after requesting permission
 requestPermissions(
 Context,
 arrayOf(Manifest.permission.POST_NOTIFICATIONS),
 REQUEST_CODE
 )

△ Request notification permission

You can use the Notification.areNotificationsEnabled API or PermissionChecker to check whether the app has obtained the notification permission. The method for applying for notification permission is the same as applying for other permissions, and you do not need to make additional adjustments. Here are some additional points to note:

1. Before accessing data, let users fully understand why you want to read the data;
2. Be prepared for when users and the system deny permissions. When a user refuses permission for the second time, you should respect the user's wishes.
3. Obtain private data on a step-by-step basis as needed, and do not apply for all permissions at once;
4. When the user denies or revokes a permission, you need to make it possible for your app to seamlessly fall back to running without the permission.

‍Minimize the use of permissions

The third best practice is to minimize the use of permissions. On the one hand, you should respect the user's wishes and choices, and on the other hand, you can use Android's alternative APIs to simplify access to sensitive data while providing better privacy control. The following solutions can help you minimize data access.

Using the new nearby devices access permission

Wearable devices have developed rapidly in recent years, and a large number of applications need to interact with these devices. In the past, applications had to apply for location access permissions before they could connect to the corresponding devices through Bluetooth. Developers have reported this inappropriate design to us, especially when the application only needs to obtain Bluetooth access permissions but not the device location. Excessive permission requests also make users doubt the legitimacy of the application's behavior. These feedbacks urge us to improve the corresponding relationship between permissions.

△ Permission to access nearby devices

Apps built for Android API 30 and earlier need to apply for BLUETOOTH_ADMIN and BLUETOOTH permissions, as well as location permissions, to discover, pair, and connect to external devices. For example, the following code is the permission declaration your app needs to make on earlier devices:

 <!-- Apply for Bluetooth permissions on older devices-->
 <uses-permission android:name="android.permission.BLUETOOTH"/>
 <uses-permission android:name="android.permission.BLUETOOTH_ADMIN"/>
 <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>

△ Apply for Bluetooth permissions on older devices

When you switch to building your app for API 31, you can add a maxSDKVersion attribute in addition to the above permission declaration:

 <!-- Apply for Bluetooth permissions on older devices-->
 <uses-permission android:name="android.permission.BLUETOOTH" android:maxSdkVersion="30" />
 <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" android:maxSdkVersion="30" />
 <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" android:maxSdkVersion="30" />
 <!-- Request permission to scan nearby Bluetooth devices-->
 <uses-permission android:name="android.permission.BLUETOOTH_SCAN" android:usesPermissionFlags="neverForLocation" />
 <!-- Request permission to communicate with paired Bluetooth devices-->
 <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
 <!-- Request permission to use the current device for discovery-->
 <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" />

△ Apply for Bluetooth related permissions on the premise of compatibility with new and old devices

Then, you need to add the BLUETOOTH_SCAN permission declaration and use the neverForLocation flag to tell the system that you will not use this permission to infer the device's location information. At the same time, you need to declare the BLUETOOTH_CONNECT permission to interact with Bluetooth devices and broadcast the current device information to nearby Bluetooth devices through BLUETOOTH_ADVERTISE.

Set up smart app hibernation for apps

When we released Android 11 in 2020, we also introduced the feature of automatically resetting permissions, and brought this feature to devices running Android 6 and later through an update to Google Play Services. When an app has not been used for several months, Android will automatically revoke certain permissions of the app. From the analysis of the situation after the release of this update, 8.5 million apps have had their permissions revoked due to long-term non-use in just 14 days. Therefore, it is recommended that you always check whether the permissions still exist first to avoid errors caused by system revocation of permissions.

△ The automatic reset function of permissions introduced in Android 11

In 2021, we launched the Smart App Hibernation feature, building on the automatic permissions reset feature. Android automatically puts apps that have not been used for a long time into hibernation, thereby optimizing device storage, improving performance, and increasing security. The system not only revokes the user's previous authorization, but also forcibly stops the app, reclaiming memory, storage space, and other temporary resources.

When an app goes into hibernation, the system will prevent the app from running tasks in the background or receiving push notifications. The way to end the app's hibernation is also very simple. The user only needs to start the app. Similar to the automatic reset of permissions, when an app goes into hibernation, the user will receive a corresponding notification, and the user can also choose to turn off hibernation in the settings.

Make good use of partition storage strategy

Android 10 introduced partitioned storage for the first time, which provides a new storage solution for privacy protection. With the subsequent iterations of the update, other apps can no longer access the external directory of an app. You can also add and edit files of this app without requesting any permissions, or edit files generated by third-party apps with the user's informed consent. If you add files to a shared storage directory, no permission is required.

Using the Photo Picker

In the future, we will release a photo picker that can read photos or videos selected by the user without any request. You can select photos or videos stored locally on the device, or access photos or videos from cloud providers such as Google Photos. This new picker will replace the previous access method of requesting permissions and simplify the permission declaration of the application.

This new photo picker is available on Android 11 and later devices via a Google Play system update. Here’s an example of using this new photo picker:

 //Intent to send
 val intent = Intent(MediaStore.ACTION_PICK_IMAGES).apply {
 putExtra(MediaStore.EXTRA_PICK_IMAGES_MAX, 15)
 putExtra(Intent.EXTRA_MIME_TYPES, arrayOf("image/*", "video/*"))
 }
 // Process the returned intent
 override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent) {
 // Traverse all URI results
 for (i in 0 until data.clipData.itemCount) {
 val uri = data.clipData.getItemAt(i).uri
 val inputStream = contentResolver.openInputStream(uri)
 }
 }

△ Get the intent of the photo selector

If you need to invoke this picker in your app, you need to start the ACTION_PICK_IMAGES Intent and specify the maximum number of media that can be selected and the supported file types. After the user selects the file, you can read the URI of each file through the clipData property, and then use ContentResolver to read the file content. In order to be compatible with earlier devices, we also plan to release a support library that allows apps to use the new photo picker when supported, and use the Storage Access Framework to simplify reading file metadata and content when not supported.

New storage permission division strategy

In addition, we are working hard to bring clearer storage permissions to users and more precise storage permissions to developers through the new storage space feature. For example, the READ_IMAGES permission introduced in the next version allows you to read all images and video files on the shared storage space, while READ_AUDIO can be used to read all audio files (including .m3u playlists). With partitioned storage, your application does not need to apply for access permissions when accessing files in its own partition; non-media files in the shared storage space can still be obtained through the Storage Access Framework. If you want to include these changes in your manifest, you can refer to this example:

 <!-- Requesting permissions on API 31 and earlier devices -->
 <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="31"/>
 <!-- Request image and video access permissions-->
 <uses-permission android:name="android.permission.READ_IMAGES"/>
 <!-- Requesting Audio Access Permissions-->
 <uses-permission android:name="android.permission.READ_AUDIO"/>
 <!-- Request access to all shared files (only for allowed use cases) -->
 <uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE"/>

△ Declare the use of new permissions

Please note that the MANAGE_EXTERNAL_STORAGE permission can be used for applications whose core functionality is to interact with a large number of files. However, this permission is subject to Google Play's policy on the use of "all file access permissions". For more information on the use of this permission, see Manage all files on the storage device: https://developer.android.google.cn/training/data-storage/manage-all-files

The above suggestions are summarized as follows:

1. Minimize location data access and try to access coarse location information only when the app is in the foreground;
2. Use new Bluetooth permissions to provide better privacy protection;
3. Avoid requests for shared storage when possible with the new photo picker.

Developers can downgrade permissions

Some apps may no longer need certain permissions that were previously granted by the user to enable a specific feature or retain sensitive permissions from older Android versions. In Android 13, we provide new APIs that allow your app to protect user privacy by downgrading previously granted runtime permissions.

Thank you for reading. We hope that we can work together to build an operating system and application ecosystem that users can use with peace of mind.