Android P introduces a number of changes to the Android system. Most of these changes affect all apps, regardless of what version of Android they target. However, several changes only affect apps targeting Android P. To maximize clarity, this page is divided into two sections: Apps targeting all API levels and Apps targeting Android P.
All apps running on Android P
These behavior changes apply to all apps when they run on the Android P platform, regardless of the API level that they are targeting. All developers should review these changes and modify their apps to support them properly, where applicable to the app.
Android P introduces new features to improve device power management. These changes, along with features that were already present before Android P, help to ensure that system resources are made available to the apps that need them the most.
For details, see Power Management in Android P.
To enhance user privacy, Android P introduces several behavior changes, such as limiting background apps' access to device sensors, restricting information retrieved from Wi-Fi scans, and new permission rules and permission groups related to phone calls, phone state, and Wi-Fi scans.
These changes affect all apps running on Android P, regardless of target SDK version.
Limited access to sensors in background
Android P limits the ability for background apps to access user input and sensor data. If your app is running in the background on a device running Android P, the system applies the following restrictions to your app:
- Your app cannot access the microphone or camera.
- Sensors that use the continuous reporting mode, such as accelerometers and gyroscopes, don't receive events.
- Sensors that use the on-change or one-shot reporting modes don't receive events.
If your app needs to detect sensor events on devices running Android P, use a foreground service.
Restricted access to call logs
Android P moves the
permissions from the
group to the new
group. This group gives users better control and visibility to apps that
need access to sensitive information about phone calls, such as reading phone
call records and identifying phone numbers.
If your app requires access to call logs or needs to process outgoing calls, it
must now explicitly request their permissions from the
group. Otherwise, a
Note: Because these permissions are in a new group and are granted at runtime, it's possible for the user to deny your app access to phone call logs information. In this case, your app should be able to handle the lack of access to information gracefully.
If your app is already following runtime permissions best practices, it can handle the new permission group.
Restricted access to phone numbers
Apps running on Android P can no longer read phone numbers or phone state
without first acquiring the
permission, in addition to the other permissions that your app's use cases
Phone numbers associated with incoming and outgoing calls are visible in the
such as for incoming and outgoing calls, and are accessible from the
permission, the phone number field that's provided in
broadcasts and through
PhoneStateListener is empty.
To read phone numbers from phone state, update your app to request the necessary permissions based on your use case:
- To read numbers from the
PHONE_STATEintent action, you need both the
READ_CALL_LOGpermission and the
- To read numbers from
onCallStateChanged(), you now need the
READ_CALL_LOGpermission only. You no longer need the
Restricted access to Wi-Fi location
Android P enforces the following permissions for Wi-Fi scans:
- When your app accesses scan results and connection information, it must have
ACCESS_COARSE_LOCATIONpermission or the
- When triggering Wi-Fi scans, your app must have one of these location
permissions, as well as either
Otherwise, no results are returned.
Information removed from Wi-Fi service methods
In Android P, the following events and broadcasts no longer receive information about the user's location or personally identifiable data:
In addition, system broadcasts from Wi-Fi no longer contain SSIDs, BSSIDs, connection information, or scan results.
If your app needs this information, call
Telephony information now relies on device location setting
If the user has disabled device location on a device running Android P, the following methods don't provide results:
Device security changes
Devices running Android P provide key rotation and system call protection. These changes enhance app security, no matter what API level your app targets. For more details, see changes to all apps on the Security Behavior Changes page.
Android P introduces several changes to the implementation and handling of cryptographic algorithms.
Conscrypt implementations of parameters and algorithms
Android P provides additional implementations of algorithm parameters in Conscrypt. These parameters include: AES, DESEDE, OAEP, and EC. The Bouncy Castle versions of these parameters and many algorithms have been deprecated in Android P.
If your app targets Android 8.1 (API level 27) or lower, you receive a warning
when requesting the Bouncy Castle implementation of one of these deprecated
algorithms. If you target Android P, however, these requests each throw a
Android P introduces several other cryptographic changes:
- When using PBE keys, if Bouncy Castle is expecting an initialization vector (IV) and your app doesn’t supply one, you receive a warning.
- The Conscrypt implementation of the ARC4 cipher allows you to specify either ARC4/ECB/NoPadding or ARC4/NONE/NoPadding.
- The Crypto Java Cryptography Architecture (JCA) provider has been removed. As
a result, if your app calls
SecureRandom.getInstance("SHA1PRNG", "Crypto"), a
- If your app parses RSA keys from buffers that are larger than the key structure, an exception no longer occurs.
App compatibility changes
To help ensure app stability and compatiblity, the platform restricts the use of some non-SDK methods and fields; these restrictions apply whether you attempt to access these methods and fields directly, via reflection, or using JNI. In Developer Preview 1, your app can continue to access these restricted interfaces; the platform uses toasts and log entries to bring them to your attention. If your app shows such a toast, it is important that you pursue an implementation strategy other than the restricted interface. If you feel that no alternative strategy is feasible, you may file a bug to request reconsideration of the restriction.
Restrictions on Non-SDK Interfaces contains further important information. You should review it to ensure that your app continues to function.
Updates to the ICU libraries
The version of the ICU library used in the platform has been updated from ICU 58, used in Android 8.0 (API level 26) and 8.1 (API level 27), to ICU 60.
used to provide public APIs beneath the
android.icu package and is
used internally in the Android platform for internationalization support.
For example, it is used to implement Android classes in java.util,
java.text and android.text.format. This release contains many small but useful
changes like Emoji 5.0 data support and improved date/time formats, as documented
in the ICU 59 and ICU 60 release notes. You should take particular note
of the following points:
- The way the platform handles time zones has changed.
- The platform handles GTM and UTC better; UTC is no longer a synonym for
ICU now provides translated zone names for GMT and UTC. This change affects
android.icuformatting and parsing behavior for zones like "GMT", "Etc/GMT", "UTC", "Etc/UTC", and "Zulu".
java.text.SimpleDateFormatnow uses ICU to provide display names for UTC /GMT, meaning:
zzzzgenerates a long localized string for many locales. Previously, it produced produced "UTC" for UTC and strings like "GMT+00:00" for GMT).
zzzzrecognizes strings like "Universal Coordinated Time", and "Greenwich Mean Time".
- Apps may encounter compatibility problems if they assume
that "UTC" or "GMT+00:00" are output for
zzzzin all languages.
- The behavior of
- As with
SimpleDateFormat, UTC and GMT now have long names. DST variants of time zone names for the UTC zone, such as "UTC", "Etc/UTC", and "Zulu", become GMT+00:00, which is the standard fallback when there are no names available, rather than the hard-coded string
- Some zone IDs are correctly recognized as synonyms for other
zones, so that Android finds strings for
archaic zone IDs, such as
Eire, that previously could not be resolved.
- As with
- Asia/Hanoi is no longer a recognized zone. For this reason
java.util.TimeZones.getAvailableIds()does not return this value, and
java.util.TimeZone.getTimeZone()does not recognize it. This behavior is consistent with the existing
- The platform handles GTM and UTC better; UTC is no longer a synonym for GMT.
android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String)method may throw a
ParseExceptioneven when parsing legitimate currency text. Avoid this problem by using
NumberFormat.parseCurrency, available since Android 7.0 (API level 24), for
PLURALCURRENCYSTYLE-style currency text.
Android secure encrypted files are no longer supported
Android secure encrypted files (ASECs) were originally introduced in Android 2.2 (API level 8) to support the original apps-on-SD-card feature. Android 6.0 (API level 23) replaced and deprecated ASECs, introducing in their place an “adoptable SD card” feature.
Android 8.0 (API level 26) blocked the ability to install new apps into ASECs. The Developer Preview removes the ASEC functionality completely.
Test suite build changes
addRequirements() method in the
class has been removed, and the
TestSuiteBuilder class itself been deprecated.
addRequirements() method had required developers to supply arguments whose
types are hidden APIs, making the API invalid.
Testing libraries removed from framework
In Android 8.1 (API level 27) and lower, the Android framework provides several
classes, such as
that you can use to create tests in your app. At compile time, these classes are
available when building against
android.jar. This built-in testing
architecture, although convenient, requires you to test against the version of
android.jar provides, which makes it difficult to build and test
dependencies that rely on a different version of JUnit.
To give you more flexibility in building and testing custom or third-party logic, Android P removes test classes from the framework. The testing libraries are still available as optional dependencies, though. The Legacy testing libraries page describes how to use them in Android P.
To learn more about how to test Android apps, see Testing Apps on Android.
Java UTF decoder
UTF-8 is the default charset in Android. A UTF-8 byte sequence can be decoded
String constructor, such as
String(byte bytes). The UTF-8 decoder is
stricter in Android P and follows the Unicode standards, namely:
- The non-shortest form of UTF-8, such as
<C0, AF>, is now treated as ill-formed.
- The surrogate form of UTF-8, such as
U+DFFF, is now treated as ill-formed.
- The maximal subpart is replaced by a single
U+FFFD. For example, in the byte sequence "
41 C0 AF 41 F4 80 80 41," the maximal subparts are "
AF," and "
F4 80 80." "
F4 80 80" can be the initial subsequence of "
F4 80 80 80", but "
C0" can't be the initial subsequence of any well-formed code unit sequence. Thus, the output should be "
- To decode a modified UTF-8 / CESU-8 sequence in Android P, use the
DataInputStream.readUTF()method or the
Hostname verification using a certificate
RFC 2818 describes two
methods to match a domain name against a certificate—using the available
names within the
SAN) extension, or in the absence of a
SAN extension, falling back to the
However, the fallback to the
CN was deprecated in RFC 2818. For this reason,
Android no longer falls back to using the
CN. To verify a hostname, the server
must present a certificate with a matching
SAN. Certificates that don't
SAN matching the hostname are no longer trusted.
Network address lookups can cause network violations
Network address lookups that require name resolution can involve network I/O and are considered blocking operations. Blocking operations on the main thread can cause pauses or jank.
StrictMode class is a development tool that helps
developers to detect problems in their code.
StrictMode now detects network
violations caused by network address lookups that require name resolution.
Developers should not ship their apps with
StrictMode enabled. Otherwise,
their apps can experience new exceptions, such as
NetworkOnMainThreadException when using the
detectAll() methods to get a policy
that detects network violations.
Resolving a numeric IP address isn't considered a blocking operation. Numeric IP address resolution works the same way as in platform versions lower than Android P.
In platform versions lower than Android P, if a socket is tagged using the
the socket is untagged when it's sent to another process using binder
IPC with a
Starting in Android P, the socket tag is kept when it’s is sent to another
process using binder IPC. This change can affect network traffic statistics, for
example, when using the
queryDetailsForUidTag() method. You can keep the previous behavior by calling
untagSocket() before sending
the socket to another process.
Reported amount of available bytes in socket
More detailed network capabilities reporting for VPNs
In platform versions lower than Android P, the
NetworkCapabilities class only reported a limited set of
information for VPNs, such as
TRANSPORT_VPN but omitting
NET_CAPABILITY_NOT_VPN. This situation made it
difficult for app developers to determine if using a VPN would result in charges
to the user. For example, checking
NET_CAPABILITY_NOT_METERED would not determine
whether the underlying networks are metered or not.
Starting in Android P, when a VPN calls the
the Android system merges the transports and capabilities of any underlying
networks and returns the result as the effective network capabilities of the VPN
App developers that already check for
NET_CAPABILITY_NOT_METERED receive the
network capabilities of the VPN and the underlying networks starting in Android
Files in xt_qtaguid folder are no longer available to apps
Direct read access to files in the
/proc/net/xt_qtaguid folder is no longer
allowed to apps. The reason is to ensure consistency with some devices running
Android P at launch that don't have these files at all.
The public APIs that rely on these files,
NetworkStatsManager, continue to work as intended.
However, the unsupported
functions, such as
may not work as expected—or at all— on different devices.
FLAG_ACTIVITY_NEW_TASK requirement is now enforced
With Android P, you cannot start an activity from a non-activity context unless
you pass the intent flag
If you attempt to start an activity without passing this flag, the
activity does not start, and the system prints a message to the log.
Screen rotation changes
Users in Android O can toggle between auto-rotate and portrait rotation modes using a Quicksettings tile or Display settings. In Android P there are significant changes to the portrait rotation mode. The portrait mode has been renamed rotation lock and it is active when auto-rotate is toggled off. There are no changes to auto-rotate mode.
When the device is in rotation lock mode, users can lock their screen to any
rotation supported by the top, visible Activity. An Activity should not assume
it will always be rendered in portrait. If the top Activity can be rendered in
multiple rotations in auto-rotate mode, the same options should be available in
rotation locked mode, with some exceptions based on the Activity's
screenOrientation setting (see the table below).
Activities that request a specific orientation (for example,
screenOrientation=landscape) ignore the user lock preference and behave
the same way as in Android O.
The rotation lock mode works by setting the user rotation preference which the WindowManager uses when handling Activity rotation. The user rotation preference might be changed in the following cases. Note that there is a bias to return to the device's natural rotation, which is normally portrait for phone form factor devices:
- When the user accepts a rotation suggestion the rotation preference changes to the suggestion.
- When the user switches to a forced portrait app (including the lock screen or the launcher) the rotation preference changes to portrait.
The following table summarizes rotation behavior for the common screen orientations:
|unspecified, user||In auto-rotate and rotation lock the Activity can be rendered in portrait or landscape (and the reverse). Expect to support both portrait and landscape layouts.|
|userLandscape||In auto-rotate and rotation lock the Activity can be rendered in either landscape or reverse landscape. Expect to support only landscape layouts.|
|userPortrait||In auto-rotate and rotation lock the Activity can be rendered in either portrait or reverse portrait. Expect to support only portrait layouts.|
|fullUser||In auto-rotate and rotation lock the Activity can be rendered in portrait or landscape (and the reverse). Expect to support both portrait and landscape layouts.
Rotation lock users will be given the option to lock to reverse portrait, often 180º.
|sensor, fullSensor, sensorPortrait, sensorLandscape||The rotation lock mode preference is ignored and is treated as if auto-rotate is active. Only use this in exceptional circumstances with very careful UX consideration.|
Apache HTTP client deprecation affects apps with non-standard ClassLoader
With Android 6.0, we removed support for the Apache HTTP client. This change has no effect on the great majority of apps that do not target Android P. However, the change can affect certain apps that have a nonstandard
ClassLoader structure, even if the apps do not target Android P.
An app can be affected if it uses a non-standard
ClassLoader that explicitly delegates to the system
ClassLoader. These apps need to delegate to the app
ClassLoader instead when looking for classes in
org.apache.http.*. If they delegate to the system
ClassLoader, the apps will fail on Android P with a
NoClassDefFoundError, because those classes are no longer known to the system
ClassLoader. To prevent similar problems in the future, apps should in general load classes through the app
ClassLoader rather than accessing the system
A device running Android P can discover every available camera by calling getCameraIdList(). An app should not assume that only a single back camera and/or a single front camera exists.
For example, if your app has a button to switch between the front and back cameras, there may be more than one front or back camera to choose from. You should walk the camera list, examine each camera's characteristics, and decide which cameras to expose to the user.
Apps targeting Android P
These behavior changes apply exclusively to apps that are targeting
the P platform or higher. Apps that compile against Android P or higher
targetSdkVersion to Android P or higher must modify
their apps to support these behaviors properly, where applicable to the app.
Apps that target Android P or higher and use foreground services must request
permission. This is a normal permission,
so the system automatically grants it to the requesting app.
If your app targets Android P, you should keep the following behavior changes in mind. These updates to device serial and DNS information enhance user privacy.
Build serial number deprecation
Build.SERIAL field was
deprecated in Android 8.0 (API level 26). In Android P,
Build.SERIAL is always
"UNKNOWN". This change protects users' privacy.
Android P apps should honor the private DNS APIs. In particular, apps should ensure that, if the system resolver is doing DNS-over-TLS, any built-in DNS client either uses encrypted DNS to the same hostname as the system, or is disabled in favor of the system resolver.
Framework security changes
If your app targets Android P, the system enforces stricter network and file system security. For more details, see changes to apps targeting Android P on the Security Behavior Changes page.
Connectivity data counting and multipath
Within apps that target Android P, the system counts network traffic on networks
that aren't the current default—such as cell traffic while the device is on
Wi-Fi—and provides methods in the
NetworkStatsManager class to query for that traffic.
now returns a value based on the aforementioned network traffic. New in Android
P, it returns
true for cell data, but when more than a certain amount of
traffic accumulates in a day, it starts returning
false. Apps running on
Android P must call and honor this hint.
class now sends information about VPNs to apps. This change makes it much easier
for apps to listen for connectivity events without having to mix synchronous and
asynchronous calls and using limited APIs. Additionally, it means that
information transfer works as expected when a device is connected to multiple
Wi-Fi networks or multiple cell networks simultaneously.
Views with 0 area (either a width or a height is 0) are no longer focusable.
Additionally, activities no longer implicitly assign initial focus in touch-mode. Instead, it is up to you to explicitly request initial focus, if desired.
CSS RGBA hex value handling
Android P apps enable the draft CSS Color Module Level 4 behaviour for handling 4 and 8 hex digit CSS colors.
CSS Color Module Level 4 has been supported by Chrome since release 52, but WebView currently disables the feature because existing Android applications were found to contain 32 bit hex colors in the Android ordering (ARGB), which would cause rendering errors.
For example, the color
#80ff8080 is currently rendered in
WebView as opaque
light red (
#ff8080) for apps targeting pre-Android P SDKs. The leading
component (which would be interpreted by Android as the alpha component) is
currently ignored. If an app targets P or above, this will be interpreted as
50% transparent light green (#80ff80).
Document scrolling element
Previously to Android P, scrolling position was set on the body element, and the root element had zero scroll values. Android P enables the standards-compliant behaviour where the scrolling element is the root element.
Furthermore, directly accessing
will behave differently depending on target SDK. To access viewport scroll
document.scrollingElement, if available.
DEX ahead-of-time compiler optimization
On devices running Android P, the Android runtime (ART) has a new ahead-of-time compiler, which optimizes compressed DEX files by converting app package (APK) DEX files into more compact machine code. This change allows your app to start faster and consume less disk space and RAM. This improvement particularly benefits low-end devices with slower disk I/O speeds.
Notifications from suspended apps
Prior to Android P, notifications from suspended apps were canceled. In Android P, notifications from suspended apps are hidden until the app is resumed.
Apache HTTP client deprecation
With Android 6.0, we removed support for the Apache HTTP client. Beginning with Android P, that library is removed from the bootclasspath and is not available to apps by default.
To continue using the Apache HTTP client, apps that target Android P and above
can add the following to their
<uses-library android:name="org.apache.http.legacy" android:required="false"/>
As an alternative to using the runtime Apache library, apps can bundle their
own version of the
org.apache.http library in their APK. If you do this,
you must repackage the library (with a utility like Jar
Jar) to avoid class compatibility issues with
the classes provided in the runtime.