Android P introduces a number of behavior changes that enhance the security of your app and the devices that run them. This page describes the platform changes that are most important for third-party app developers to keep in mind.
Behavior changes affecting all apps
Android P adds several capabilities that improve your app's security, regardless of which version your app targets.
TLS implementation changes
The system's TLS implementation has undergone several changes in Android P:
- If an instance of
SSLSocketfails to connect while it's being created, the system now throws an
IOExceptioninstead of a
SSLEngineclass now cleanly handles any
close_notifyalerts that occur.
Stricter Seccomp filter
We've further restricted the system calls that are available to apps. Apps aren't affected, however, if they use the Bionic library and don't make system calls directly.
Support for ChaCha20 stream cipher
The Android platform now supplies implementations of the ChaCha20 cipher as described in RFC 7539, both in unadorned stream cipher form, ChaCha20/None/NoPadding, and in ChaCha20 + Poly1305 AEAD form, ChaCha20/Poly1305/NoPadding.
Legacy encryption support
Android P devices that ship with Keymaster 4 support the Triple Data Encryption Algorithm, or Triple DES. If your app interoperates with legacy systems that require Triple DES, use this type of cipher when encrypting sensitive credentials.
Behavior changes affecting apps targeting Android P
Android P adds several capabilities that improve your app's security, but only if it targets Android P.
Network TLS enabled by default
If your app targets Android P, the
false by default. As a result, if your app needs to enable
cleartext for specific domains, you need to explicitly set
true in your app's
Network Security Configuration.
Web-based data directories separated by process
In order to improve app stability and data integrity in Android P, apps can no
longer share a single
multiple processes. Typically,
such data directories store cookies, HTTP caches, and other persistent and
temporary storage related to web browsing.
In most cases, your app should use classes from the
android.webkit package, such
CookieManager, in only one
process. For example, you should move all
Activity objects that use a
into the same process. You can more strictly enforce the "one process only" rule
your app's other processes. This call prevents
WebView from being initialized
in those other processes by mistake, even if it's being called from a dependent
If your app must use instances of
WebView in more than one process,
you must assign a distinct data directory suffix for each process, using the
method, before using a given instance of
WebView in that process. This method
places web data from each process in its own directory that's inside your app's
Per-app SELinux domains
Apps that target Android P can no longer share data with other apps using world-accessible Unix permissions. This change improves the integrity of the Android Application Sandbox, particularly the requirement that an app's private data is accessible only by that app.