Android-side permission privacy compliance practices

[[419042]]

What is

For the client, permission privacy can be divided into two major aspects: permission and privacy.

• Permissions are permissions that users grant to corresponding apps through pop-up settings within the app or the permission settings of the corresponding app in the phone settings, such as phone permissions, location permissions, camera permissions, etc. This article mainly focuses on privacy-related permissions.

• Privacy refers to personal information related to the user during the use of the app, such as location, Mac address, device ID, etc. On the Android side, most private information requires corresponding authorization to obtain, but there is still some private information that can be obtained without authorization.

Why

• The public's privacy awareness has been awakened, and poor privacy and security of permissions will directly lead to users' reluctance to use it;

• Increasingly strict authority management and privacy security management, strict control by the Ministry of Industry and Information Technology and the market;

• As the most direct interactive information collection portal with users, the client is obliged to collect and use user information in a compliant manner.

Specific Practice

1. Adaptation of permissions in various Android versions

1.1 Early Registration Permissions

In versions prior to Android 6.0 (SDK version 23), the App Installation page lists all permissions registered by the current app. There is no Agree or Disagree button, only Install and Cancel. When developing an app, you only need to register the required corresponding permissions in the manifest file:

 <uses-permission android:name= "android.permission.READ_PHONE_STATE" />
 <uses-permission android:name= "android.permission.READ_EXTERNAL_STORAGE" />
 <uses-permission android:name= "android.permission.ACCESS_FINE_LOCATION" />
 <uses-permission android:name= "android.permission.CAMERA" />

1.2 Dynamic Permission Granting

Since Android 6.0 (SDK version 23), permissions are divided into normal permissions, dangerous permissions, and special permissions. Among them, dangerous permissions require users to manually grant corresponding permissions before calling certain system methods, including multiple permission groups such as PHONE, LOCATION, STORAGE, etc. If the relevant method is called directly without authorization, it will be thrown and the application will crash. The error message is similar to the following:

 java.lang.SecurityException: getDeviceId: has android.permission.READ_PHONE_STATE.

To solve the above error problems, you can encapsulate permission processing tools yourself, or use some open source permission tools to handle them. The core code cannot escape:

 // Check if a permission has been granted
 ContextCompat.checkSelfPermission(context, perm) == PackageManager.PERMISSION_GRANTED)
 //Request a certain permission, and a permission system pop-up window will pop up after calling
 ActivityCompat.requestPermissions((Activity) object, perms, requestCode);

Note: If the user denies permission and does not want the system permission authorization pop-up window to be displayed again, it is best to provide a clickable page in the terminal to enter the mobile phone system's permission setting page so that the user can choose to enable the corresponding permission.

1.3 Changes to the READ_PHONE_STATE permission

1.3.1 Evolution

• READ_PHONE_STATE permission is to allow access to phone status. This permission is mainly concentrated in TelephonyManager class, which controls the acquisition of ids such as imei, deviceId, Meid, SimSerialNumber and other phone status. Most apps will use these fields individually or in combination as device unique codes to identify user devices, and then the server will perform data analysis, distribution and other operations. Before 6.0, you only need to register to use it.

• After Android 6.0, the READ_PHONE_STATE permission becomes a dangerous permission that requires active authorization from the user. Therefore, some apps require the user to authorize the permission before using the app. If the user does not authorize the permission, the app will be exited. This is obviously not a good solution, but it can still be effective in the transition period. Time can be reserved to redefine how to identify specific devices without authorization.

• After adapting to Android 10.0, the READ_PHONE_STATE permission was directly cancelled and replaced with the system permission READ_PRIVILEGED_PHONE_STATE , which can only be used in system apps. If the code still uses the READ_PHONE_STATE permission for authorization, the same permission grant pop-up window will no longer pop up on the phone. At this time, if the getDeviceId method is still called, a SecurityException will be thrown directly. The source code can be reflected in the annotations of the corresponding methods:

 @RequiresPermission (android.Manifest.permission.READ_PRIVILEGED_PHONE_STATE)
 public String getDeviceId()
 @RequiresPermission (android.Manifest.permission.READ_PRIVILEGED_PHONE_STATE)
 public String getImei()

1.3.2 Adaptation

• The maximum permission set for READ_PHONE_STATE in the manifest file is 28, which means that devices running Android 10 or higher do not obtain this permission.

 <uses-permission
    android:name= "android.permission.READ_PHONE_STATE"
    android:maxSdkVersion= "28" />

 getDeviceId
 getImei
 Build.VERSION.SDK_INT < Build.VERSION_CODES.Q

• Since these IDs cannot be obtained by mobile phones running Android 10.0 and above, the precise push of domestic advertisements has also had a certain impact. Therefore, major manufacturers have launched the OAID logo, which was originally intended for precise push of advertisements, but is also a choice for the unique identification of client apps. For specific acquisition methods, please refer to the alliance's integration document.

1.4 Storage Partition Processing

Since Android 10.0, Google has started to use storage partitions, the main purpose of which is to change the existing apps that use the phone storage indiscriminately, causing garbage and other security issues. After adapting to Android 11, storage partitions are mandatory. The specific partitions are as follows. The extended external storage has no permission to read. Other private storage will be cleaned up after the app is uninstalled:

The specific code changes are as follows:

1. Photo storage path:

Environment.getExternalStorageDirectory().getAbsolutePath() is modified to getExternalFilesDir(Environment.DIRECTORY_DCIM) ;

2. The original storage path /storage/emulated/0 is changed to /storage/emulated/0/Android/data

The specific call modification is:

Environment.getExternalStorageDirectory() is changed context.getExternalFilesDir() ;

3. If the App has important storage in the sdcard, you can copy the previous data to the new storage partition during the transition period of adapting to Android 10.0.

2. Compliance processing of privacy information

The first part briefly reviews some changes and corresponding modifications related to permissions. Next, let's talk about the compliance processing of privacy information. Of course, permissions are the premise of privacy processing. If permissions are not reasonably modified, then the compliance of privacy processing is out of the question. After all, a lot of privacy depends on permissions.

2.1 Direct and transparent notification of privacy information

• When opening the App for the first time, the user agreement and privacy protection pop-up window or page needs to be displayed to the user before initialization. Only after the user agrees can the App be used. For sensitive information such as mobile phone number, MAC address, IMEI, location information, mobile phone storage permissions, album access permissions, mobile phone traffic usage, etc., users need to be able to see it on the first screen. And provide a link to the user agreement and privacy policy so that users can click to view the specific detailed terms. After the design is completed, the legal department should confirm whether it is compliant.

• When handling dynamic permissions in 1.2, you need to explain the reason why the user needs to grant the permission in the system pop-up window or before. For example, before obtaining location permission, you need to inform the user that the permission is for obtaining location information and then accurately pushing relevant content. The purpose of obtaining camera permission is to use the camera to take pictures.

• The legal terms and privacy policy entrances can be seen within three steps of entering the App. The normal processing method is to add the corresponding entrances to the App's settings page . At the same time, on the registration and login page, the legal terms and privacy terms entrances need to be clearly displayed, and they need to be unchecked by default. Users need to actively agree to the account before they can register and log in. As shown below:

• Apps that distribute ads need to pay attention to the logic of ad downloading. After the user clicks on it, they need to display the information of the downloaded app, the required permissions and privacy terms, so that users can clearly know whether the downloaded app is what they want, and automatic download is not allowed. This can effectively solve the problem of users unconsciously downloading a lot of useless apps on their phones, which is very helpful for many elderly people to use mobile phones.

2.2 Security of Acquisition and Transmission of Private Information

• Avoid frequent calls to system methods to obtain private information. You can use global variables to cache the data after launching the App once. You can then directly call the global variables each time you use it, without having to call the system methods every time. This includes getDeviceId , getMacAddress , etc.

• Sensitive information such as IMEI, MAC, and positioning latitude and longitude should not be transmitted multiple times in the network. They can be processed as a separate interface to collect relevant information once and save it on the server without each transmission. In addition, it is necessary to avoid transmitting it in plain text in the data interface. For example, IMEI can be encrypted using the MD5 encryption algorithm, which will not affect the distinction between users.

• Since the READ_PHONE_STATE permission is upgraded to the system permission READ_PRIVILEGED_PHONE_STATE , some information such as imei will be reported as an error or empty when directly calling it through native method (C code). It is recommended to use java method to call this part as much as possible. If there is a change, the error can be clearly perceived and modified, without the need to modify the C code again and then compile it with jni.

2.3 Strictization of some privacy API calls

• In the case of unauthorized use, it is necessary to ensure that the functions in the App that are not related to the permission can be used normally. Therefore, it cannot be simply handled as mentioned in 1.3.1, where the App cannot be used if the permission is not granted.

• There is still some privacy on the Android side that can be obtained without dynamic authorization, such as the list of applications installed on the user's phone. This information can be used to analyze user preferences, such as novel products or video products; it can also be used to analyze whether some users have not installed certain apps, so as to facilitate the push of advertisements to attract new users. However, the domestic market has begun to regulate it. If there is a situation where the list of applications in the mobile phone is obtained, it will be removed from the shelves or not put on the shelves.

• At present, the Ministry of Industry and Information Technology and various application markets have strict requirements for App listing. The use of third-party detection tools can carefully detect any unreasonable system method calls in the App, such as: making network requests before agreeing to the agreement and privacy; obtaining the Mac address before agreeing to the agreement and privacy; obtaining the base station information of the mobile phone without obtaining positioning permission.

3. Some problems and pitfalls encountered

Here is a summary of some hidden points encountered during the development process, I hope it can help everyone.

• The early Tencent X5 kernel will obtain the MAC address when displaying the privacy agreement, as shown in the figure below. You can try to update to a new version to continue viewing. Since we do not have a high demand for the X5 kernel, we directly deleted it.

• The initialization of integrated open source libraries or third-party SDKs must be processed after agreeing to privacy. Most SDKs will call related API methods that do not require authorization during initialization. For example, the voice-related iFlytek SDK will call MAC address information during initialization.

• Some statistical libraries such as umeng and talkingdata sdk need to be upgraded to the new version of access method. The old version of talkingdata sdk will still call the mobile phone base station information api (positioning) when it is initialized without the location permission.

• The acquisition and assignment of relevant privacy information in the own code logic must also be carried out after privacy consent, so as little code logic processing as possible should be performed before the user agreement and privacy consent.

Summarize

The development trend of permission privacy will only become more strict and standardized. In daily client development, we need to always be aware of privacy security and ensure privacy security from the user's perspective. We should keep up with the development of privacy security and make arrangements in advance. This will avoid being in a hurry to deal with temporary problems.

This article only roughly records some situations and practices related to permission privacy. If there is anything inappropriate, please feel free to correct me.