Android P developer preview
Compatibility test

Question 1: suppose android. OS. Build. VERSION. RELEASE for numeric types

The reason:

For previews of upcoming new releases of Android, these values may be alphanumeric (such as “PPR” or “P”), resulting in a crash when trying to resolve “P” to an integer.

Advice:

The application treats the value of RELEASE as a string.

Problem 2: The third-party SDK version is too early to be compatible with Android P

The reason:

In the Chinese Android ecosystem, applications often rely on third-party SDKS (especially hardened and hotfix frameworks) that are tightly integrated with the underlying system (such as using non-public interfaces), resulting in the failure of the application to run properly when the Android version is upgraded. We’ve also started working with some of the common SDK providers (and plan to cover more) to address compatibility issues early in the new preview version of Android.

Advice:

Check the update bulletin of the third-party SDK regularly and update it to the latest version in a timely manner.

If the third-party SDK you are using does not yet support the new version of Android, please report it to its provider and help push it to resolve compatibility issues.

Problem 3: Detected Problems with API compatibility is displayed when an application is started, or NoSuchFieldException or NoSuchMethodException is encountered when a non-SDK interface is invoked

The reason:

Non-sdk interfaces are those that are used internally by the Android system and not provided in the SDK, and that developers can invoke through Java reflection, JNI, etc. However, this is dangerous: non-SDK interfaces do not have any public documentation, and you must look at the source code to understand their behavior logic.

Non-sdk interface function signatures (including parameter lists and return values), behavior logic are likely to be significantly modified in the next Android version, and even the API itself may be removed. This can cause applications that use non-SDK interfaces to not run on new Android versions, or to behave differently than expected at runtime, and developers must invest considerable development resources to keep them fit for each new Version of Android.

Using the underlying non-SDK interface may bypass some of Android’s security and privacy protections. Not only will it affect the user experience and interfere with user privacy, but Google Play Protect may also determine that the application is malware and prompt the user to uninstall it.

Starting with Android P, the use of non-SDK interfaces is limited.

Advice:

Use only the public interfaces in the Android SDK for application development. The public SDK interface has detailed technical documentation and support channels, and future Versions of Android will ensure the compatibility of the public SDK interface (even if there are changes, they will be detailed in the documentation).

Test your app as early as possible in the Android P preview. You can run and manipulate your app and then look for something like the following in ADB Logcat, which includes the name of the non-SDK interface your app calls, the black/grey list it belongs to, and how it calls: Accessing hidden field Landroid/os/Message; ->flags:I (light greylist, JNI) Accessing hidden method Landroid/app/ActivityThread; ->currentActivityThread()Landroid/app/ActivityThread; (dark greylist, reflection)

If you have a legitimate reason to use a non-SDK interface, please leave us a comment at the bottom of this article. We look forward to listening and discussing with you, and after fully evaluating the necessity and feasibility, we will provide possible solutions to meet the reasonable functional requirements.

Problem 4: Call dex2OAT directly, or compile dex file in an unsupported/incorrect way

The reason:

From the beginning, Dex2OAT was designed as a build and deployment tool for internal use in the system, and Android has never supported a scenario where developers call Dex2OAT directly. We continue to tweak the tool from time to time, and many times its behavior changes (e.g. generated files and their formats) are incompatible with previous ones. In most cases, the standard classloaders (BaseDexClassLoader/DexClassLoader/PathClassLoader) cannot find or use the files generated by calling Dex2OAT directly.

Also note that starting with Android O, the “optimizedDirectory” parameter in the BaseDexClassLoader and DexClassLoader constructors is discarded and does not work when the dex file is loaded.

Advice:

If you need to load the dex file from memory and don’t want to leave a trail in storage, use the new loader InMemoryDexClassLoader in Android O.

Problem 5: Injecting or tampering with dex and SO files generated by Android Studio

The reason:

The dex file generated by Android Studio has a public layout, but the content is compiled and optimized in the background at run time. If you write custom content in the dex file, it is likely that these custom write operations will conflict with the system optimization, so that the custom content will be erased or overwritten, and even cause the optimized DEX to crash directly during execution.

The SO files generated by Android Studio contain some metadata (such as ELF headers and Section headers) for integrity checking by the dynamic linker. Tampering with so files does not result in improved security (many tools can regenerate metadata), but may result in the application not being launched in future Android versions (because dynamic linkers may perform more stringent checks). For more information about so file requirements, you can send the information “SO file” on the official account platform to get the related link.

Advice:

Do not modify the dex and SO files generated by Android Studio.

This app was built for an older version of Android and may not work properly…

The reason:

The applied targetSdkVersion is too old (<17)

Advice:

Update the targetSdkVersion of your application to the latest version. You can send the message “targetSdkVersion” on the official account platform to obtain the related document link.

Problem 7: The application does not display correctly on the special screen, some content is out of the screen

The reason:

Android O is starting to support extra strong screens, and many manufacturers are starting to release phones with extra strong screens. The application made the wrong assumptions about the display ratio of the screen and failed to support aspect ratios above 16:9, thereby affecting the user experience.

Advice:

Modify your application to accommodate different screen sizes (including aspect ratios above 16:9).

If an adaptive UI is not suitable for your scenario, consider setting resizableActivity = false in the manifest and adding Android :MaxAspectRatio to declare the maximum aspect ratio supported. This will enable compatibility mode on devices with long screens, filling the display space around the edges of the application with black.

Problem 8: The application does not display correctly on the specialty screen. Black edges appear above and below

The reason:

Android O is starting to support extra strong screens, and many manufacturers are starting to release phones with extra strong screens. Application pairs that fail to support aspect ratios above 16:9 will enable compatibility mode on devices with long screens, filling the display space around the edges of the application with black.

Advice:

Update the targetSdkVersion of your application to the latest version. You can send the message “targetSdkVersion” on the official account platform to obtain the related document link.

Please refer to the following Android P documentation to make your application compatible with Android P as early as possible:

Set up the SDK and emulator

Migration guide

Behavior change

New features and apis

If you have any experience working with Android P compatibility, please share with us in the comments below. Thank you very much!