Migrating Apps to Android P

Android P (API level 28) introduces new features and APIs that you can take advantage of in your apps, as well as new behavior changes. This document gives you an overview of the steps to migrate your apps to Android P across two key phases:

Ensure basic compatibility with Android verify that your existing app is fully functional on the new version of the platform. At this stage, you do not use new APIs or change your app’s,targetSdkVersion but minor changes might be necessary.
Target the new platform, compile with the Android P SDK, and build with Android P features when you are ready to take advantage of the new features of the platform, update your targetSdkVersionto,28 verify the app continues to function as expected, and then begin using new APIs.

Prepare a device running Android P

If you have a compatible device, obtain the Android P system image for your device from the manufacturer. Read Get Android P for information. General instructions for flashing a system image are here.

You can also download the Android P system image for the Android Emulator. It’s listed in the SDK Manager under Android P Preview as Google APIs Intel x86 Atom System Image.

Note: The Android P emulator system image is available for download in Android Studio 3.1 and higher; Android Studio 3.2 provides maximum compatibility. For more information, see Get the Android P SDK.

Ensure compatibility with Android P

The objective here is to make sure that your existing app works as-is on Android P (API level 28). Because some platform changes might affect the way your app behaves, some adjustments might be necessary, but you do not need to use new APIs or change yourstargetSdkVersion.

Perform compatibility testing

For the most part, testing compatibility with Android P (API level 28) entails the same type of testing you perform when preparing to release your app. This is a good time to review the Core App Quality Guidelines and Best Practices for Testing.

However, there’s another aspect to testing: Android P introduces changes to the Android platform that can affect your app’s behavior or break the app altogether, even if you do not change yourstargetSdkVersion. For this reason, it is important that you review the key changes in table 1, and test any fixes that you implement to accommodate the changes.

Table 1. Key changes that affect all apps running on Android P devices.

Change	Summary
Restrictions on non-SDK interfaces	Access to specific non-SDK interfaces is now blocked, whether the access is direct, via JNI, or via reflection. Attempts to access restricted interfaces generate errors such as`NoSuchFieldException` and.`NoSuchMethodException` See Restrictions on Non-SDK Interfaces for details.
Removal of Crypto provider	Starting in Android P, Crypto JCA provider has been removed. Calls to will`SecureRandom.getInstance("SHA1PRNG", "Crypto")` throw.`NoSuchProviderException`
Stricter UTF-8 decoder	In Android P, the UTF-8 decoder for Java language is stricter and follows the Unicode standard.
Access to camera, microphone, and sensors blocked for idle apps	While apps are idle, they can no longer access camera, microphone, or SensorManager sensors.

For a more extensive list of behavior changes for all apps running on Android P, see the Behavior Changes document.

Update your target version and use Android P features

This section explains how to enable full support for Android P (API level 28) by updating your totargetSdkVersion 28 and adding new features available in Android P.

In addition to offering you new APIs, Android P introduces some behavior changes when you update yours totargetSdkVersion 28. Because some behavior changes might require code changes to avoid breakage, you should first understand how your app might be affected when you change the bytargetSdkVersion reviewing all behavior changes for apps targeting Android P.

Note: The steps described above to ensure platform compatibility are prerequisite to targeting your app to Android P, so be sure to complete those steps first.

Get the Android P SDK

You can get the SDK packages to build your app with Android P (API level 28) using Android Studio 3.1 or higher. If you don’t need the new features in Android P yet, and only want to compile against that version of the platform, you can use Android Studio 3.1. Android Studio 3.2 provides complete support for Android P features.

To get set up with either version of Android Studio, follow the steps documented in Set up the Preview SDK.

Test your Android P app

With the above preparations complete, you can build your app and then test it further to make sure it works properly when targeting Android P (API level 28). This is another good time to review the Core App Quality Guidelines and Best Practices for Testing.

When you build your app with the settargetSdkVersion to P, there are specific platform changes you should be aware of. Some of these changes can significantly affect your app’s behavior or even break your app altogether, even if you do not implement new features in Android P.

Table 2 provides a list of these changes with links to more information.

Table 2. Key changes that affect apps when istargetSdkVersion set to 28.

Change	Summary
Foreground service permission	Apps wanting to use foreground services must now request the FOREGROUND_SERVICE permission first. This is a normal permission, so the system automatically grants it to the requesting app. Starting a foreground service without the permission throws a SecurityException.
Deprecation of Bouncy Castle ciphers	Android P deprecates several ciphers from the Bouncy Castle provider in favor of those provided by the Conscript provider. Calls to that`getInstance()` request the Bouncy Castle provider generate errors`NoSuchAlgorithmException`. To resolve the errors, do not specify a provider in getInstance() (that is, request the default implementation).
Removal of direct access to `Build.serial`	Apps needing the Build.serial identifier must now request the permission`READ_PHONE_STATE` and then use the new method`Build.getSerial()` added in Android P.
Disallowed sharing of WebView data directory	Apps can no longer share a single WebView data directory across processes. If your app has more than one process using WebView, CookieManager, or any other API in the android.WebKit package, your app will crash when the second process calls a WebView method.
Access to app’s data directory blocked by SELinux	The system enforces per-app SELinux sandboxes with per-app SELinux restrictions on each app’s private data directory. Directly accessing another app’s data directory by path is now disallowed. Apps may continue to share data using IPC mechanisms, including bypassing FDs.

For a more extensive list of behavior changes for apps targeting Android P, see Behavior Changes document.

To explore the new features and APIs available Android P (API level 28), see Android P Features and APIs.

Migrating Apps to Android P