I. Introduction

Second, the version adaptation

Limit http network requests

http (plaintext transmission) network requests are restricted in android 9.0,If you continue to use http requests, the following exception will be prompted in the log (but the request cannot be sent normally,Will not cause the app to crash):

java.net.unknownserviceexception:cleartext communication to xxx not permitted by network security policy

The method of adaptation is as follows:

The first

Create a new xml file in the resource directory as the network security configuration file.For example, xml/network_security_config.xml, then fill in the file with the following:

<?xml version="1.0" encoding="utf-8"?>
 <base-config cleartexttrafficpermitted="true" />

Configure in androidmanifest.xml:

 android:networksecurityconfig="@ xml/network_security_config">

Second (thanks to allenchiang for reminding)

The configuration of whether to allow the network to use clear text transmission was introduced in android 6.0:

<application android:usescleartexttraffic=["true" | "false"]>

The original default was true, but the default value was changed to false in android 9.0, so manually setting the configuration to true can solve the problem of limited plain text transmission

2. Deprecated apache http client

Since the official removal of all apache http client related classes in android 9.0,Therefore, if our application or some third-party libraries use these classes,Will throw the class not found exception:

java.lang.noclassdeffounderror:failed resolution of:lorg/apache/http/conn/scheme/schemeregistry;

If you need to continue to use apache http client, you can adapt it by the following methods:

Add the following in androidmanifest.xml:

<uses-library android:name="org.apache.http.legacy" android:required="false" />

Or directly package and reference the apache http client related classes in the application

3. Restrict calls to non-sdk interfaces

3.1 Brief description

All the timeThe officially provided interfaces are divided into SDK interfaces and non-SDK interfaces. The sdk interface is the officially supported interface.Developers can call directly without any restrictions.Generally speaking,The sdk interfaces are recorded in the official interface index.Those that are not documented are considered non-sdk interfaces, such as methods marked with @hide.

In the past, developers' calls to non-sdk interfaces were usually made using reflection or jni indirect calls.But this kind of calling method will be prone to some unknown errors if it is not handled properly.To improve the user experience and reduce the risk of app crashes,Android 9.0 imposes restrictions on non-sdk interfaces that apps can use.See the table below for specific restrictions:

In addition, in order to allow developers to smoothly transition to android 9.0, the official classification of non-sdk interfaces,Divided into three categories,light-greylist, dark-greylist, and blacklist:

light-greylist (light gray list):For non-sdk interfaces in this list, the official has not found an alternative sdk interface, so developers can still access it (if targetsdkversion is greater than or equal to 28, a warning will appear). dark-greylist (dark gray list):if targetsdkversion is less than 28, you can continue to use the interfaces in this list,But a warning prompt will appear;When it is greater than or equal to 28, these interfaces will restrict access. blacklist:No matter what the targetdkversion is, as long as the application runs on the android 9.0 platform, access to the interfaces in this list will be restricted

3.2 How to test if the application uses a non-sdk interface

You can test it in the following ways (for details, go toOfficial document):

Debug apps with android 9.0 or higher devices Testing with strictmode api Scan the app with the veridex tool

The third method is recommended.The tool's scan results list the application's call details for the interfaces in the three restricted lists.

4. Front desk service permissions

In android 9.0, the application must apply for foreground_service permission before using the foreground service, otherwise a securityexception exception will be thrown.

In addition, since the foreground_service permission is just a normal permission,So developers only need to register this permission in androidmanifest.xml,The system automatically authorizes this permission:

<uses-permission android:name="android.permission.foreground_service" />

5. Enforce flag_activity_new_task requirements

Before Android 7.0 (api level 24), if developers need to start an activity through a non-activity context, they must set the intent flag_activity_new_task, otherwise it will fail to start and throw the following exception

android.util.androidruntimeexception:calling startactivity () from outside of an activity context requires the flag_activity_new_task flag. is this really what i want?

However, this requirement was temporarily cancelled due to system problems after updating android 7.0.The developer can start the activity normally even if the flag is not set. This problem was officially fixed in android 9.0,This requirement restarted enforcement,Therefore, developers need to pay attention to this problem when adapting to android 9.0.

6. Disallow sharing webview data directory

To improve application stability and data integrity in android 9.0,Apps can no longer have multiple processes share the same webview data directory.Such data directories typically store cookies, http caches, and other persistent and temporary storage related to web browsing.

If developers need to use webview in multiple processes, they must first call the webview.setdatadirectorysuffix () method to set the directory for each process to store webview data.If you need to share data between multi-process webviews,Developers need to implement it through ipc.

In addition, if a developer wants to use webview in only one process and wants to strictly enforce this rule,You can do this by calling the webview.disablewebview () method in another process, so that other processes that create webview instances will throw exceptions.

7. Other API changes

7.1 region.op related

In android 9.0, if you set a type other than region.op.intersect or region.op.difference when using the drawing crop function,Will throw the following exception:

java.lang.illegalargumentexception:invalid region.op-only intersect and difference are allowed

The specific reason is that the cropping methods with the region.op parameter are officially abandoned.Such as cliprect (@nonnull rectf rect, @nonnull region.op op):

 * modify the current clip with the specified rectangle.
 * @param rect the rect to intersect with the current clip
 * @param op how the clip is modified
 * @return true if the resulting clip is non-empty
 * @deprecated region.op values ​​other than {@link region.op #intersect} and
 * {@link region.op #difference} have the ability to expand the clip. the canvas clipping apis
 * are intended to only expand the clip as a result of a restore operation. this enables a view
 * parent to clip a canvas to clearly define the maximal drawing area of ​​its children. the
 * recommended alternative calls are {@link #cliprect (rectf)} and {@link #clipoutrect (rectf)};
 * as of api level api level {@value build.version_codes #p} only {@link region.op #intersect} and
 * {@link region.op #difference} are valid region.op parameters.
 * /
public boolean cliprect (@nonnull rectf rect, @nonnull region.op op) {
 checkvalidclipop (op);
 return ncliprect (mnativecanvaswrapper, rect.left, rect.top, rect.right, rect.bottom,   op.nativeint);
private static void checkvalidclipop (@nonnull region.op op) {
 if (scompatiblityversion>= build.version_codes.p
   &&op!=Region.op.intersect&&op!=Region.op.difference) {
  throw new illegalargumentexception (
    "invalid region.op-only intersect and difference are allowed");

About this question,You can adapt by:

if (build.version.sdk_int>= build.version_codes.p) {
 canvas.clippath (path);
} else {
 canvas.clippath (path, region.op.xor);//replace, union and other types

7.2 build.serial is deprecated

Before android 9.0, developers can use build.serial to get the serial number of the device.This method is now deprecated,build.serial will always be set to "unknown" to protect user privacy.

The adapted method is to first request read_phone_state permission and then call the build.getserial () method.

  • Previous Python35 Pandas module missing value processing and hierarchical index examples
  • Next Vue's way to redirect 404 pages in Nuxtjs
  • Trends