Android Target 31 Upgrade Raiders - Remembering the Ups and Downs of Ali's First Super App

Author: Yang Xikai, Zhang Jiongxuan

Briefly

The Android Target version, as the "agreement" and "bridge" between the application and the system version, is an important measure in terms of manufacturer's pre-installation cooperation, application store exposure, and openness. In recent years, Google and mobile phone manufacturers have promoted the speed of Target upgrade. and intensity increased significantly. The higher the Target version, the better the security of the system and users, but the changes, constraints and unclear pits to the application also increase, especially for the use of a wide range of system APIs, complex business, and high stability requirements. The super application challenge is great.

AutoNavi Map has been upgraded from Target 28 to the latest Target 31 in one go, becoming the industry's first head application to be upgraded to the latest version, meeting the requirements of the application market and manufacturers' pre-installation compliance, and cooperating with the follow-up market for pre-installation and pre-installation. Wait to win the time window. The first "eat crab", stepped on a lot of pits, so we summarized the problems, principles, solutions and operation methods encountered in the upgrade process, hoping to help you achieve more with less in upgrading Target.

1.1 Definition: What is the Target version

Target version, which in vernacular means "inform the system that I have met the compliance requirements for the specified system version and am willing to be bound". Specifically:

• In terms of constraints, unlike general mandatory constraints (for example, a user must meet a certain condition to upgrade to Android 12), the Target version provides us with a "soft, buffered adaptation" approach that allows users to upgrade to Android 12. , temporarily not subject to the constraints of the new system (Target is an old version), but to upgrade the Target version to meet the constraints after "ready", which is more flexible;
• In terms of strength, the higher the Target version, the more constraints and the stronger the binding force. The version here is the "system API version number", which corresponds to the Android version one by one. For example, 28 corresponds to Android 9, and 29 corresponds to Android. 10, and so on.

1.2 Challenges: reasons for rapid change and high cost

Why is the recent Target upgrade fast and expensive? From an industry development and technology perspective:

Looking at the trend from the development of the industry :

• Manufacturers follow up quickly: In recent years, the requirements for Target's upgrades have shown "tightening" and "tightening". Through this method, each app can be constrained from the system level to meet the requirements of privacy compliance and unified user experience; among which:

a. For pre-installed applications, as a necessary part of CTS (Compatibility Test Suite, Google's Compatibility Test Suite) integration, if Target cannot respond to Target's upgrade requests in a timely manner, it is likely to cause pre-installed applications to be removed from the shelf, and further cooperation with manufacturers, Serious impact due to the amount of application tape;

b. For market applications, through TAF's "Convention on the Self-discipline of Mobile Application Software High API Level Preset and Distribution" and other conventions, from experience, the conditions will be extended to the application store within 1-2 years, even if pre-installed applications are not involved, still plan ahead

• Strong privacy : Whether government regulators, manufacturers, or Google, they meet the requirements of "privacy compliance" more and more frequently, and the once "extensive" App permissions are a thing of the past. In the long run, such restrictions will have a significant impact on users. Profitable, but for application developers, it is necessary to respond in a timely manner, clarify trends, and fully understand and implement;
• There are many fragmented devices : Google and various manufacturers/ROMs have different understandings of privacy, API adjustment, etc., and the implementation effects of different versions and different devices are quite different, and the "fragmentation" is becoming more and more intense. Such as "approximate location", "startup map", etc., each manufacturer will do secondary development according to their own needs, resulting in Google's native adaptation method, there are problems in other ROMs

From a technical point of view:

• Frequent changes : Take Android 12 as an example, there are at least 5 document changes (including startup map, fuzzy positioning, file storage, etc.) after the release of Release, and Release Patches have been issued to manufacturers, and manufacturers will then look at their own needs and rhythms. Whether or not to "implement" the patch will cause the cost of adaptation to increase exponentially; coupled with the fragmentation of each ROM, the focus needs to be continuously adjusted during the process
• Incomplete materials : At that time, there were no good analysis documents in the industry, and mainstream apps were not adapted to 31. Many of them needed to be explored by themselves, such as the judgment of new permissions, the use of external storage, the startup map, etc. The official either did not mention it, or only said that Probably, you need to analyze the source code + continuous practice to make it clear.
• Difficulty in adaptation : Each permission adjustment involves many APIs, high user influence, and a large amount of adaptation. Taking us as an example, compared to the 20+ system APIs of Target 21 → 26 in the past, this time involves 300+ system APIs , thousands of calls, covering multiple technology stacks, the high cost of transformation and a wide range of influence have brought a lot of challenges to our adaptation

As a fast-growing super app, AutoNavi needs to maintain internal "sustained business growth" while digesting external "high requirements, rapid changes, and great difficulty". After everyone's unremitting efforts, the upgrade of Target 28 → 31 has been successfully completed.

1.3 Benefits

1. In order to meet the compliance requirements of the application market and manufacturers' pre-installation, the government, manufacturers, and telecommunications terminal industry associations should set a good amount in advance, so as to win the time window for the follow-up market first-mover and pre-installation cooperation, so as to avoid getting stuck;
2. In the special process, the experience in upgrading and compliance has been accumulated, and the system isolation layer has been designed and implemented to reduce the impact of subsequent changes on the business and improve the efficiency of subsequent responses to the new system, Huami OV ROM, Hongmeng, etc.;
3. Through source code analysis + self-developed script, 13 changes not mentioned by Google were successfully identified, and 119 potential crashes and unavailability risks were reduced.

Privacy Rights

2.1 External storage, partition storage and limitations [29,30]

background

In order to better protect user data and limit the increase of redundant files on the device, if the app is upgraded to Target 29, it will be granted partition access to the external storage device by default (that is, partitioned storage), and the app can only see this app's special There are sandboxed directories as well as specific types of media (via MediaStore).

Status (SDK=28 is the target platform application)

When the user grants the "storage" permission, it is allowed to read and write the contents of the external non-sandbox directory, and it will not be cleared after uninstalling and reinstalling; in addition, some user albums and sensitive information can also be read after the permission is granted.

Performance of different access methods after Target upgrade

premise:

• Set requestLegacyExternalStorage=true and PreserveLegacyExternalStorage=true
• APK targetSDK upgraded to 31
• Reinstall APK after new/uninstall

Table of contents:

• Shared directory: store files accessible to other applications, including media files, document files and other files, corresponding to the DCIM, Pictures, Alarms, Music, Notifications, Podcasts, Ringtones, Movies, Downloads and other directories;

• Inside the sandbox:

  • /sdcard/Android/data/{packagename}
  • /data/data/{packagename}
  • /sdcard/Android/media/{packagename}
• Other directories: directories created by the system or other applications on the external SD card;

Suggestions for pits & pit avoidance (verified on mainstream models such as Xiaomi and ov):

• Pit: When Android 11+, Target is 30+ and the user is newly installed/uninstalled and reinstalled, even if there is no storage permission, writing to two subdirectories of sdcard (for example: /sdcard/xxx/yyy) The system returns "Read/Write" " is still true, which is not as expected; the system does not throw a write exception until the file content is read and written, resulting in failure.
• Suggestion for pit avoidance: Since it is no longer trustworthy to rely solely on the results returned by the system, double check the results returned by the system. For example, after Android 11 and above and "read-write" returns true, a temporary file is written, and if the writing fails, it is still placed in the sandbox.

Summary & Adaptation Suggestions

• Overlay installation will not automatically open partition storage, and the original storage access rights will not be affected;
• The application can complete the data migration by disabling the partition storage mechanism through the two attributes of requestLegacyExternalStorage and PreserveLegacyExternalStorage, but these two attributes are only valid for upgrades, and the new installation/reinstallation of the machine after android 11 will force the partition storage mechanism to be enabled;
• After partition storage is enabled, you can normally access the directories in the sandbox without applying for storage permission;
• After partition storage is turned on, the access to non-sandbox directories will be limited. For details, see the table above;
• After partition storage is enabled, you still need to apply for storage permission, otherwise access to shared directories will be restricted.

2.2 Bluetooth permissions and different strategies [29,30,31]

Bluetooth API involving permissions

It can be roughly divided into the following three categories:

Requirements for bluetooth permissions in different versions

• When Target ≤ 28: You can use connection APIs and broadcast APIs with BLUETOOTH and BLUETOOTH_ADMIN permissions. Scanning APIs need approximate positioning permissions (ACCESS_COARSE_LOCATION).
• When Target is 29 and 30 : the connection API and broadcast API permissions do not change, and the scanning API requires additional precise positioning permission (ACCESS_FINE_LOCATION).

• When Target is greater than or equal to 31: Subdivision Bluetooth permissions are added to replace BLUETOOTH and BLUETOOTH_ADIMIN, providing applications with a more flexible way to apply for permissions. Specifically include:

  • BLUETOOTH_SCAN: Allows scanning and discovering devices. The scanning API needs to have both this permission and the precise location permission (ACCESS_FINE_LOCATION).
  • BLUETOOTH_CONNECT: Allows connecting and accessing paired devices. This permission is required for connection APIs.
  • BLUETOOTH_ADVERTISE: Allows broadcasting to nearby Bluetooth devices. Broadcast APIs need this permission.

For the pop-up performance of these three newly added permissions, we have actually tested it, and the phenomenon is as follows:

The corresponding relationship between Bluetooth API and permissions in different versions is finally summarized as follows:

Adaptation scheme

• In different Android versions, the usage of the Bluetooth API has not changed, so it is only necessary to adapt the permissions accordingly to avoid crashes caused by unauthorized access;
• If the Bluetooth scanning, connecting and broadcasting APIs are used at the same time, the corresponding permissions need to be applied for. Considering that these three types of Bluetooth operations are often closely connected, for example, after scanning and discovering, the connection will be made. If you apply for all the Bluetooth permissions required for scanning, connecting and broadcasting at one time, it can better meet the usage scenarios, and also Avoid repeated pop-up permission pop-ups to make the interaction more concise. Therefore, we finally adopted the method of combined application;
• When applying for Bluetooth permission in combination, the system permission pop-up window on Vivo IQOO 5 is shown as follows:

The following are the adaptations that need to be done to upgrade the Target SDK from 28 to 31:

1. Declare different permissions for different Android versions

• In order to continue to be compatible with SDK 29-30, the BLUETOOTH and BLUETOOTH_ADMIN permissions declared in the Manifest should be retained, and the maxSdkVersion should also be declared as 30, and the ACCESS_COARSE_LOCATION should also be retained, such as:

 <!-- Request legacy 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" />

• Added BLUETOOTH_SCAN, BLUETOOTH_CONNECT and BLUETOOTH_ADVERTISE permission declarations. like

 <uses-permission android:name="android.permission.BLUETOOTH_SCAN" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" />
    <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

• Added ACCESS_FINE_LOCATION permission declaration (if you are sure that the application will not deduce the user's location, you can skip this declaration and the following dynamic application. But you need to add the android:usesPermissionFlags="neverForLocation" declaration in the BLUETOOTH_SCAN permission declaration)

2. Dynamically apply for runtime permissions

• SDK 29-30, need to apply dynamically to get ACCESS_FINE_LOCATION
• SDK ≥ 31, first dynamically apply for ACCESS_COARSE_LOCATION+ACCESS_FINE_LOCATION (new requirements introduced by fuzzy positioning, see below for details), and then combine BLUETOOTH_SCAN, BLUETOOTH_CONNECT and BLUETOOTH_ADVERTISE to apply for Bluetooth permissions. If you directly apply for Bluetooth permission without obtaining ACCESS_FINE_LOCATION, it may cause an abnormal result that the request is ignored.

3. Do permission verification before using the API

Before using the Bluetooth API that involves permissions, you need to perform permission verification. Make sure that you have the corresponding permissions, and then continue to call; otherwise, stop the call, otherwise the application may crash directly.

• SDK 29-30, you can judge whether you have the ACCESS_FINE_LOCATION permission
• SDK ≥ 31, because of the combined application method, we can directly judge whether we have ACCESS_FINE_LOCATION and BLUETOOTH_SCAN at the same time

2.3 Approximate location [31]

(The manufacturer calls it "fuzzy positioning", which is unified below)

background

After upgrading to Target 31, in the positioning permission setting page and authorization pop-up window of the Android 12 system, precise positioning and fuzzy positioning are clearly distinguished, and users are allowed to choose to use only fuzzy positioning. Accurate positioning" permission is disabled. Previously, some Android 11 models of Xiaomi/Vivo have adopted this method to provide users with more flexible positioning options, and the Android target 31 upgrade is a reference to the same idea. It can be understood that, on the basis that only Xiaomi/Vivo supported "fuzzy positioning" (turning off precise positioning), Target has extended it to all Android 12 systems of other manufacturers such as Oppo/Huawei/Samsung after the upgrade.

Different Vendor/Version Strategies

Map location permission settings page

Figure positioning authorization pop-up window

The following is a comparison of fuzzy positioning before and after the Target 31 upgrade:

As you can see, if the app only uses fuzzy positioning, it will not be affected in any way. However, for applications that are highly dependent on precise positioning, corresponding adaptations are required to ensure accurate positioning permissions.

Adaptation scheme

1. Determine whether the application has the precise location permission

• For models with Target ≤ 30 that support fuzzy positioning (Xiaomi/Vivo), you need to use the API provided by the manufacturer for judgment. For details, please refer to the relevant documentation of each manufacturer's adaptation (official website or internal release document)
• For models with Target ≥ 31, you can directly use the system API, that is, Context.checkSelfPermission() to determine whether ACCESS_FINE_LOCATION is available.

2. Guide users to enable precise positioning: Before the authorization pop-up window pops up, or before going to the application permission setting page, a guiding pop-up window or copy can be displayed to the user, prompting them to enable precise positioning.

2.4 Permission to access location information in the background [29,30]

background

In order to allow users to better control the access rights of applications to location information, the management and control of background location permission applications have been strengthened since Android 10. Before introducing the change, you need to understand the background positioning scenario, unless one of the following conditions is met, the application will be considered to be accessing location information in the background:

• Activity belonging to the application is visible;
• A foreground device on which the application is running has declared the foreground service type as location.

Changes after upgrade

• When Target = 29: The ACCESS_BACKGROUND_LOCATION permission is introduced, and the app needs to declare the ACCESS_BACKGROUND_LOCATION permission in the AndroidManifest, and then dynamically apply for this permission and the user selects "Always Allow" to obtain the background positioning capability;

• When Target ≥ 30 : The app needs to declare the ACCESS_BACKGROUND_LOCATION permission in the AndroidManifest, and then the user selects "Always Allow" on the system settings page to obtain the background location capability.

Note: To dynamically apply for the ACCESS_BACKGROUND_LOCATION permission through requestPermission, the system will ignore the request and will not pop up the window. If you request both foreground and background location permissions, the request will be ignored and your app will not be granted either permission.

Adaptation suggestion

• Due to the inconsistent acquisition methods of background location permissions for different targets, if you need background access location permissions, it is recommended to guide users to the system settings from the product side to add
• Do not apply for front-end and back-end access location permissions at the same time, otherwise the authorization pop-up window will not be displayed

2.5 Precise alarm clock permissions [31]

background

To encourage apps to conserve system resources, Android 12 requires the "Alarms and Reminders" special app access for apps that target Android 12 and set precise alarms. To get this special app access, request the SCHEDULE_EXACT_ALARM permission in the manifest. The precise alarm clock can only be used for user-oriented functions, and both the user and the system can revoke the access permission of the "Alarm Clock and Reminder" special application, so it is necessary to add permission judgment when necessary, otherwise an Exception will be thrown.

Adaptation suggestion

Those who need an accurate alarm clock must apply for the SCHEDULE_EXACT_ALARM permission, and make permission judgment when using it.

2.6 Some telephony APIs, Bluetooth APIs, and WLAN APIs require precise location permissions [29]

background

If an app targets Android 10 or higher, it must have the ACCESS_FINE_LOCATION permission to use some methods in the Telephony, Wi-Fi, Wi-Fi Sense, and Bluetooth (described in the Bluetooth section above) APIs. The main classes involved are:

1) Phone: TelephonyManager, TelephonyScanManager, TelephonyScanManager.NetworkScanCallback, PhoneStateListener

2) WLAN: WifiManager, WifiAwareManager, WifiP2pManager, WifiRttManager

Adaptation suggestion

APIs involving "location" via wireless can only be called after granting the ACCESS_FINE_LOCATION permission.

Security Compliance

3.1 Package Visibility [30]

background

Android 11 changes the way apps query and interact with other apps a user has installed on a device. Using the <queries> element, an application can define a set of other packages that it can access. This element helps encourage the principle of least privilege by telling the system what other packages should be exposed to your app. Additionally, this element helps app stores such as Google Play evaluate the privacy and security an app offers users.

Status & Impact

The main affected system APIs found through identification include but are not limited to: queryIntentActivities, getPackageInfo, getInstalledApplications, getInstalledPackages, etc. Let's take the API of getInstalledPackages and getInstalledApplications as an example:

• Before Target upgrades, you can get installed applications directly through getInstalledPackages and getInstalledApplications

• When Target is upgraded, if it does not hit the whitelist, it will not be able to obtain the package name. The whitelist mentioned here mainly includes:

  1. Your own app, which is your own app
  2. Certain system packages that implement core Android functionality, such as media providers.
  3. The application when opening its own application through startActivityForResult (note that startActivity is invalid) (only valid for this time)
  4. Apps that have your app installed (such as the app market when you installed your own app at the time)
  5. The application when the own application is opened through bindService/startService/Provider (only valid for this time)
  6. List of package names/signatures/IntentFilter/ProviderAuthorities declared by yourself in the Manifest (see "Recommendations")
• In addition, the above restrictions can be temporarily ignored by declaring the QUERY_ALL_PACKAGES permission, but Google Play has required that in April 22, except for necessary applications such as security, browsers, and files (no navigation applications), the rest should be offline this permission, otherwise you will face The risk of delisting, so it can only be used as a bottom-line solution.

Suggest

1. If there are non-current App application components that need to be queried or interacted with, you need to add the queries element to the AndroidManifest. There are several suggestions below. You can choose according to your actual usage scenarios. It is best to follow the principle of minimum usage. Consider adding package name, android:authorities declared by Provider, general Intent-Filter, etc.
2. [Not recommended] Add QUERY_ALL_PACKAGES to Manifest to avoid crashes, but you should consider the limitations of Google Play and overseas markets.

Replenish

Regarding package visibility, in addition to Google's requirements, major domestic manufacturers are requiring apps to add manufacturer-defined permissions: com.android.permission.GET_INSTALLED_APPS, which requires user authorization, which means that an app wants to obtain application software in the future List information requires user authorization before it can be obtained normally.

3.2 Restrictions on the configured WLAN network [29]

background

To protect user privacy, only System Apps and Device Policy Controller (DPC) support manual configuration of WiFi network list (including adding, deleting, connecting to WiFi, etc.). If the application upgrades Target to 29 and the application is not a system application or DPC, some methods will not return useful data, as described in the next section.

Changes after upgrade

The behavior of acquiring/manipulating the WIFI list after Target is upgraded to 29+ is as follows:

• Get WiFi list;
• Scan the WiFi list (startScan), which can be obtained normally after granting the "FINE_LOCATION" permission, which is the same as before the upgrade;
• If the user only grants "fuzzy location" (COARSE_LOCATION), it cannot be obtained and returns null;
• The network saved by the user (getConfiguredNetworks) cannot always be obtained, and returns empty;
• Add WiFi (save network).

A new API (addNetworkSuggestions) needs to be replaced. When adding a new WiFi, the system will pop up a window waiting for the user to confirm (as shown in the figure below), and the user can refuse to add it; other behaviors are the same as before the upgrade.

• Remove/modify saved WiFi: need to be replaced with the new API removeNetworkSuggestions;
• Actively connect to WiFi: Disabled (enableNetwork), it can only be handled by the system policy or the user can go to the system to set the connection.

Adaptation suggestion

• Get WiFi list: adapt to the situation when the user only grants "fuzzy location" to return Null; remove the dependency on the saved network (getConfiguredNetworks) interface;
• Add/Remove/Modify Saved WiFi: Replace with new API. Considering that there is a system pop-up window, the user can be guided to complete it if necessary.

3.3 Safer component export [31]

background

If your app targets Android 12 or higher and contains activities, services, or broadcast receivers that use intent filters, you must explicitly declare the android:exported attribute for these app components.

Warning: If an activity, service, or broadcast receiver uses an intent filter and doesn't explicitly declare a value for android:exported, your app will fail to install on devices running Android 12 or higher.

influences

Need to check for scenarios that include intent filters in activities, services, or broadcasts.

Thoughts & Suggestions

The official consideration for the mandatory declaration of the android:exported attribute is mainly to consider security. Naturally, it is recommended that we change the exported attribute to false if it is not required to be true. Ideally, it is recommended that you check all the scenarios one by one.

Of course, if you want to solve it more quickly, it is recommended to parse the AndroidManifest during compilation. For the unified settings that do not actively set the exported attribute, this can also solve the SDK related problems.

There is a detail to pay attention to here. When the Activity contains the intent filter, if the exported attribute is not set, the system will parse the exported as true when it is running, which is also reflected in the source code of the system; so we need to Consider the historical business scenario: there may be cases where the exported attribute is not set, but the exported is set to true for use.

3.4 Restrictions on the startup of foreground services [31]

background

Apps targeting Android 12 or higher cannot start foreground services while running in the background, with a few exceptions. An exception is thrown if the app tries to start a foreground service while it is running in the background.

influences

When using the business scenario to start the foreground service (the API is as follows), you need to check whether it is started from the background, and if so, see whether it meets the special circumstances. Mainly involved: startForegroundService and startForeground methods.

Suggest:

Try to avoid, or even eliminate (as the system continues to upgrade, it is more and more strict to start the foreground service from the background) to start the foreground service from the background. It is recommended to find, comb and check all APIs involving foreground calls from the perspective of static analysis.

3.5 The front desk service needs to declare when accessing the camera and microphone [30]

background:

1. To access the camera or microphone in the foreground service, you must add the foreground service types camera and microphone;
2. If a foreground service is started when the app is running in the background, the foreground service cannot access the microphone or camera. If you want to access the location, you need the permission to access location information in the background.

influences

Use of camera, microphone or location in foreground services.

Suggest

1. If you need to use camera and microphone in the foreground service, you need to declare the corresponding types in AndroidManifest.xml. As follows: <service ... android:foregroundServiceType="camera|microphone" />
2. It is not recommended to start the foreground service when the application is in the background, because if the Target is upgraded to 31, unless there are special circumstances, the foreground service cannot be started from the background.

3.6 Pending intent variability [31]

background

If your app targets Android 12, you need to enforce "mutability" (ie FLAG_IMMUTABLE/FLAG_MUTABLE) on the Pending Intent, an additional requirement that improves your app's security.

influences

Business scenarios that use PendingIntent.

Suggest

Fill in the PendingIntent.FLAG_MUTABLE or PendingIntent.FLAG_IMMUTABLE flag for PendingIntent as required; in addition, it is better to provide an adapted aggregation class, and other classes can directly call the methods of the adaptation class, which can reduce the adaptation cost.

3.7 Updated non-SDK limitations [29, 30, 31]

background

Starting with Android 9 (API level 28), the Android platform enforces restrictions on the non-SDK interfaces that apps can use. These restrictions apply whenever an app references a non-SDK interface or attempts to use reflection or JNI to obtain a handle to it. These limits are designed to help improve the user and developer experience, reduce the risk of app crashes for users, and reduce the risk of emergency releases for developers.

• Distinguish between SDK interfaces and non-SDK interfaces: In general, public SDK interfaces are those documented in the Android Framework Package Index. The handling of non-SDK interfaces is an implementation detail abstracted away by the API, so these interfaces may change at any time without notice. To avoid crashes and unexpected behavior, apps should only use officially documented classes from the SDK. This also means that when your app interacts with the class through mechanisms such as reflection, it should not access methods or fields not listed in the SDK;
• List of non-SDK APIs: With each release of Android, more non-SDK APIs are restricted. To minimize the impact of non-SDK usage restrictions on the development workflow, non-SDK interfaces are grouped into lists that define the strictness of non-SDK interface usage restrictions (depending on the target API level of the application).

influences

Using the tools officially provided by Google and the Android 12 non-SDK interface and its corresponding list, you can scan the results of the required APPs, and you can know the scope of influence according to the results.

Suggest

Ideally, we should only use the SDK (whitelist); but some apps use non-sdk interfaces in order to gain some capabilities. therefore:

• For greylist, we can use it temporarily;
• For greylist-max-x, we need to see if it can be used temporarily according to the target version in the project. greylist-max-p is equivalent to max-target-p;
• For blacklist, it cannot be used. In addition, all non-sdk interfaces must be protected by try catch.

write before the end

The above is our thinking and solution in the Target upgrade. Due to space limitations, the above only introduces some "key points" related to privacy and security, and the specific technical implementation details. If you are interested, please feel free to leave a message in the comment area to discuss.

The key to Target's upgrade is that, in addition to the external (manufacturer, government policy) promotion, the company's internal positive attitude towards embracing privacy compliance and being responsible to users, there are also multi-party team cooperation, top-down attention, and self-improvement. Determination from the inside out, all three are indispensable. Target upgrades are by no means a "one-shot deal" and require long-term, consistent work to keep bearing fruit. We hope that our experience can bring inspiration to everyone, avoid detours, and travel lightly.

Pay attention to [Alibaba Mobile Technology], Ali's cutting-edge mobile dry goods & practice will give you thoughts!