Project: /_project.yaml Book: /_book.yaml
{% include “_versions.html” %}
Android {{ androidPVersionNumber }} has released! This page summarizes the major features in this release, and provides links to additional information when available. These feature summaries are organized according to the feature's documentation location on this site. See the August 2018 Site Updates for a guide to section moves and renaming.
Generic System Image (GSI) describes the Generic System Image (GSI) for Android {{ androidPVersionNumber }}, including details on differences between GSIs for devices launching with Android {{ androidPVersionNumber }} and devices upgrading to Android {{ androidPVersionNumber }}.
HIDL Framework Backwards Compatibility Verification is a method for verifying the backwards compatibility of the framework.
Dynamically Available HALs support the dynamic shutdown of Android hardware subsystems when they are not in use or not needed.
HIDL MemoryBlock is an abstract layer built on hidl_memory, HIDL @1.0::IAllocator, and HIDL @1.0::IMapper. It is designed for HIDL services that have multiple memory blocks to share a single memory heap.
This release adds support for using compressed overlays in the Device Tree Blob Overlay (DTBO) image when using version 1 of the device tree table header.
This release requires that the bootloader must not modify the properties defined in the device tree overlays before passing the unified device tree blob to the kernel.
This release introduces a new version field in the DTBO image header.
This release requires a DTBO partition. To add nodes or make changes to the properties in the SoC DT, the bootloader must dynamically overlay a device specific DT over the SoC DT. For more information see Compiling & Verifying.
This release includes changes to requirements that affect the kernel, its interfaces, and the use of DTBOs. For more information, see these pages:
For information about VNDK design changes in this release, see these pages:
ABI Stability describes the process for ensuring changes made to libraries in the Vendor Native Development Kit (VNDK) maintain Application Binary Interface (ABI) compliance.
VNDK Snapshots can be used by a system image to provide the correct VNDK libraries to vendor images even when system and vendor images are built from different versions of Android.
The following pages in the Vendor Interface Object section describe vendor interface object updates in this release:
The following pages describe how Android deprecates and removes HIDL HALs:
This release supports building /product partitions using the Android build system. Previously, Android 8.x enforced the separation of System-on-Chip (SoC)-specific components from the /system partition to the /vendor partition without dedicating space for OEM-specific components built from Android build system.
Canonical Boot Reason describes changes to the bootloader boot reason specification in this release.
All devices launching with this release must use system-as-root, which merges ramdisk.img into system.img (this is also known as no-ramdisk), which in turn is mounted as rootfs.
Starting in this release, the boot image header contains a field to indicate the header version. The bootloader must check this header version field and parse the header accordingly.
To prevent OTA failures due to mismatches between the recovery image and the DTBO partition on non-A/B devices, the recovery image must contain information from the DTBO image.
Display Cutouts allow app developers to create immersive, edge-to-edge experiences while still allowing space for important sensors on the front of devices.
Updates to screen rotation behavior in this release include support for a user-facing control to pin screen rotation in either landscape or portrait.
Synchronized App Transitions allow for new app transition animations.
This release introduces a Text Classifier service, which is now the recommended way to implement text classification, and a default service implementation.
This release introduces support for wide gamut color, including:
To use wide gamut color, a device’s full display stack (screen, hardware composer, GPU, etc.) must support wide-gamut colors or buffer formats. Devices are not required to claim support for wide gamut content even if the hardware supports it. However, wide gamut color should be enabled to take full advantage of the hardware. To avoid an inconsistent visual experience, wide gamut color should not be turned off during runtime.
The Android 9 Compatibility Definition Document iterates upon previous versions with updates for new features and changes to requirements for previously released functionality.
The Android app widget framework now offers increased visibility into user interactions, specifically when a user deletes or manually adds widgets. This functionality comes by default with Launcher3.
Manufacturers need to update their Launcher apps (which are shipped with devices) to support this feature if not based upon Launcher3. OEMs need to support the new widgetFeatures API{: .external} in their default Launcher.
The API in itself does not guarantee that it will work end to end unless the launchers implement it as expected. AOSP includes a sample implementation. See the AOSP Change-Id Iccd6f965fa3d61992244a365efc242122292c0ca for the sample code provided.
A protected system broadcast can now be sent to apps that hold the INSTALL_PACKAGES permission whenever a change to properties like locale or display density happens. Receivers can be registered in the manifest, and a process will be awakened to receive the broadcast. This is useful for package installers that wish to install additional components of apps upon such changes, which will happen rarely, because the configuration changes eligible to trigger this broadcast are rare.
Device state change notification source code is located at the following locations under platform/frameworks/base:
api/system-current.txtcore/java/android/content/Intent.javacore/res/AndroidManifest.xmlservices/core/java/com/android/server/am/ActivityManagerService.javaChanges to the Settings app information architecture provide more Settings functionality and easier implementation.
Atest{: .external} is a new command line tool that allows users to build, install and run Android tests locally.
New CTS packages supporting Android 9 have been uploaded to the CTS Downloads page. The source code for the included tests can be synced with the android-cts-9.0_r1 tag in the open-source tree.
For Android 9, CTS v2 gains the following command and argument:
run retry - Retry all tests that failed or were not executed from the previous sessions.‘--shard-count - Shard a CTS run into given number of independent chunks, to run on multiple devices in parallel.In addition, the previously undocumented commands ‘--retry-type’ has been added to the same CTS v2 console command reference.
Secure Element Service checks for Global platform-supported secure elements (essentially checks for Global platform-supported secure elements, by seeing if devices have an SE HAL implementation and if yes, how many. This is used as the basis to test the API and the underlying secure element implementation.
The Sensor Fusion Box is used in the CameraITS sensor_fusion test and multi-camera sync test and provides a consistent test environment for measuring timestamp accuracy of camera and other sensors for Android phones. See these pages for more information:
The Wide Field of View ITS-in-a-Box is an automated system designed to test both wide field of view (WFoV) and regular field of view (RFoV) camera systems in the Camera Image Test Suite (ITS).
VTS Host Controller Architecture describes the architecture of VTS test framework integrated with its cloud-based test serving service.
VTS Service Name Aware HAL Testing supports obtaining the service name of a given HAL instance based on the device on which Vendor Test Suite (VTS) tests are running.
VTS HAL Testability Check includes a runtime method for using the device configuration to identify which VTS tests should be skipped for that device target.
The Automated Testing Infrastructure page describes a new Vendor Test Suite (VTS) infrastructure for automated testing of VTS, CTS, or other tests on partner devices running the AOSP generic system image (GSI).
In Android, telemetry is the process of automatically collecting usage and diagnostics information about the device, the Android system, and apps. In previous versions of Android, the telemetry stack was limited and did not capture the information needed to identify and resolve system reliability and device or app issues. This made identifying root causes of issues difficult, if not impossible.
Android 9 includes a new telemetry feature, statsd, which solves this deficiency by collecting better data faster. statsd collects app usage, battery and process statistics, and crashes. The data is analyzed and used to improve products, hardware, and services.
For more details, see frameworks/base/cmds/statsd/.
APK Signature Scheme v3 is the new APK signature scheme, which supports APK key rotation.
Android 9 includes a BiometricPrompt API{: .external} that apps can use to integrate biometric authentication support in a device- and modality-agnostic fashion. For more information about integrating your biometrics stack to include BiometricPrompt, see Biometrics.
Android 9 includes support for more exploit mitigation and analysis tools.
Control Flow Integrity (CFI) is a security mechanism that disallows changes to the original control flow graph of a compiled binary, making it significantly harder to perform such attacks.
In addition to system CFI, which is enabled by default, this release also includes support for Kernel Control Flow Integrity.
File-based encryption is updated to work with adoptable storage. For new devices, we recommend using file-based encryption over full-disk encryption.
This release introduces support for metadata encryption where hardware support is present. With metadata encryption, a single key present at boot time encrypts whatever content is not encrypted by file-based-encryption.
Android 9 includes Keymaster 4{: .external}, which has these features:
Android 9 includes support for Android Keystore keys that are stored and used in a physically separate CPU purpose-built for high-security applications, such as an embedded Secure Element (SE). StrongBox Keymaster is an implementation of the Keymaster HAL in discrete secure hardware. A StrongBox has:
To securely import a key into Keymaster 4, a key created off-device is encrypted with a specification of the authorizations that define how the key may be used.
Keymaster 4 includes 3DES for compatibility with legacy systems that use 3DES.
To support Treble's modular structure and break the binding of system.img to boot.img, Keymaster 4 changed the key version binding model to have separate patch levels for each partition. This allows each partition to be updated independently while still providing rollback protection.
Supported devices that launch with Android 9 installed give developers the ability to use the Android Protected Confirmation API{: .external}. By using this new API, apps can use an instance of ConfirmationPrompt to display a prompt to the user, asking them to approve a short statement. This statement allows an app to reaffirm that the user would like to complete a sensitive transaction, such as making a payment.
The Application Sandbox has new protections and test cases to ensure that all non-privileged apps tageting Android 9 and higher run individual SELinux sandboxes.
Updates to Treble SELinux in this release are documented in several pages in the SELinux section.
Vendor Init describes updates to close the init process access hole in the Treble system/vendor split by using a separate SELinux domain to run /vendor commands with vendor-specific permissions.
Android 9 restricts system properties from being shared between system and vendor partitions unnecessarily and provides a method for ensuring consistency between shared system properties.
Android 9 includes new build-time tests{: .external} that ensure all files in specific locations have the appropriate attributes. For example, all files in sysfs have the required sysfs_type attribute.
Updates to High-Resolution Audio Effects include converting effect processing from int16 to float format and increases in simultaneous client output tracks, maximum client/server memory, and total mixed tracks.
This release supports using plug-and-play USB cameras (i.e. webcams) using the standard Android Camera2 API and the camera HIDL interface.
Camera devices can advertise motion tracking capability.
Multi-Camera Support includes API support for multi-camera devices via a new logical camera device composed of two or more physical camera devices pointing in the same direction.
Implementing session parameters can reduce delays by enabling camera clients to actively configure a subset of costly request parameters as part of the capture session initialization phase.
Single Producer Multiple Consumer Camera Buffer Transport is a new set of methods that allows camera clients to add and remove output surfaces dynamically while the capture session is active and camera streaming is ongoing.
This release provides improved support for carriers implementing data plans using the SubcriptionPlan APIs.
This release provides APIs that allow third-party calling apps to handle concurrent incoming carrier calls and to have calls logged in the system call log.
In Android {{ androidPVersionNumber }}, AOSP adds a carrier ID database to help with carrier identification. The database minimizes duplicate logic and fragmented app experiences by providing a common way to identify carriers.
Embedded SIM (eSIM or eUICC) is the latest technology to allow mobile users to download a carrier profile and activate a carrier's service without having a physical SIM card. In this release, the Android framework provides standard APIs for accessing eSIM and managing subscription profiles on the eSIM. For more information, see:
This release provides improvements to the user settings for IMS. Users can set up Voice over LTE (VoLTE), video calling, and Wi-Fi calling on a per-subscription basis instead of sharing these settings across all subscriptions.
In this release, Intent.ACTION_SIM_STATE_CHANGED has been deprecated, and two separate broadcasts for card state and card application state have been added: TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED and TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED.
With this change, receivers that only need to know whether a card is present are no longer required to listen to application state changes, and receivers that only need to know whether card applications are ready are not required to listen to changes in card state.
The two new broadcasts are @SystemApis and are not sticky. Only receivers with the READ_PRIVILEGED_PHONE_STATE permission can receive the broadcasts.
The intents are not rebroadcast when the user unlocks the device. Receivers that depend on broadcasts sent before user unlock must either be directBootAware, or they must query the state after user unlock. The states can be queried using the corresponding APIs in TelephonyManager: getSimCardState() andgetSimApplicationState().
Carrier Wi-Fi allows devices to automatically connect to carrier-implemented Wi-Fi networks. In areas of high congestion or with minimal cell coverage such as a stadium or an underground train station, Carrier Wi-Fi can be used to improve users' connectivity experience and to offload traffic.
MAC Randomization allows devices to use random MAC addresses when probing for new networks while not currently associated to a network. In this release, a developer option can be enabled to cause a device to use a randomized MAC address when connecting to a Wi-Fi network.
Turn on Wi-Fi automatically allows users to automatically re-enable Wi-Fi whenever the device is near a Wi-Fi network that has been saved and has a sufficiently high relative received signal strength indicator (RSSI).
Wi-Fi Round Trip Time (RTT) allows devices to measure the distance to other supporting devices: whether they are Access Points (APs) or Wi-Fi Aware peers (if Wi-Fi Aware is supported on the device). This feature, built upon the IEEE 802.11mc protocol, enables apps to use enhanced location accuracy and awareness.
Improved Wi-Fi scoring models quickly and accurately determine when a device should exit a connected Wi-Fi network or enter a new Wi-Fi network. These models provide a reliable and seamless experience for users by avoiding gaps in connectivity.
You should review and tune the RSSI values in the config.xml resources, especially the following:
config_wifi_framework_wifi_score_bad_rssi_threshold_5GHzconfig_wifi_framework_wifi_score_entry_rssi_threshold_5GHzconfig_wifi_framework_wifi_score_bad_rssi_threshold_24GHzconfig_wifi_framework_wifi_score_entry_rssi_threshold_24GHzNote: The “entry” values were introduced in Android 8.1, and the defaults were chosen to match the defaults for the “bad” thresholds for compatibility. Ideally, the entry threshold should be 3 dB or more above the corresponding exit (“bad”) threshold.
Wi-Fi STA/AP concurrency is the ability for devices to operate in Station (STA) and Access Point (AP) modes concurrently. For devices supporting Dual Band Simultaneous (DBS), this feature opens up new capabilities such as not disrupting STA Wi-Fi when a user wants to enable a hotspot (softAP).
WifiStateMachine is the main class used to control Wi-Fi activity, coordinate user input (operating mode: hotspot, scan, connect or off), and control Wi-Fi network actions (e.g., scanning, connecting).
In this release, the Wi-Fi framework code and implementation of WifiStateMachinehas been re-architected leading to reduced code size, easier-to-follow Wi-Fi control logic, improved control granularity, and increased coverage and quality of unit tests.
At a high level,WifiStateMachine allows Wi-Fi to be in one of four states:
Each Wi-Fi mode has different requirements for running services and should be set up in a consistent manner, handling only the events relevant to its operation. The new implementation restricts the code to events related to that mode, reducing debugging time and the risk of introducing new bugs due to complexity. In addition to explicit handling for mode functionality, thread management is handled in a consistent manner and the use of asynchronous channels is eliminated as a mechanism for synchronization.
From this release, the CHANGE_WIFI_STATE app permission is dynamically checked and can be turned off by the user. The user can disable the permission for any app through the special settings page in Settings > Apps & notifications > Special app access > Wi-Fi control.
Apps must be able to handle cases where the CHANGE_WIFI_STATE permission is not granted.
To validate this behavior, run the roboelectric and manual tests.
Run the roboelectric tests at: /packages/apps/Settings/tests/robotests/src/com/android/settings/wifi/AppStateChangeWifiStateBridgeTest.java{: .external}
For manual testing:
CHANGE_WIFI_STATE permission is not granted.Due to security issues, Wi-Fi Protected Setup (WPS) in WiFiManager has been deprecated and disabled from this release. However, WiFiDirect still uses WPS in the WPA supplicant.
This release supports implementing the Vulkan 1.1 graphics API.
This release introduces the WinScope tool for tracing window transitions. WinScope provides infrastructure and tools to record and analyze Window Manager state during and after transitions. It allows recording and stepping through window transitions, while recording all pertinent window manager state to a trace file. You can use this data to replay and step through the transition.
The WinScope tool source code is located at platform/development/tools/winscope.
The section Automotive Audio describes the audio architecture for automotive-related Android implementations.
The Neural Networks (NN) HAL defines an abstraction of the various accelerators. The drivers for these accelerators must conform to this HAL.
Vehicle Properties describes changes to the vehicle HAL interface.
When working with new Global Navigation Satellite System (GNSS) HALs (v1.1+), the Android Framework will monitor Android Settings. Partners can change the Settings from Google Play Services or other system updatees. These settings tell the GNSS HAL if certain GNSS satellites should not be used. This can be useful in case of persistent GNSS satellite or constellation errors, or to react more rapidly to GNSS HAL implementation issues that may occur when intermixing constellations using different time systems and external events, such as leap-second and/or Day, or Week Number rollovers.
In Android {{ androidPVersionNumber }}, the GNSS HAL version 1.1 or higher can pass information about the hardware API to the platform. The platform needs to implement the IGnssCallback interface and pass a handle to the HAL. The GNSS HAL passes the hardware model information through the LocationManager#getGnssHardwareModelName(){: .external} API. Device manufacturers should work with their GNSS HAL providers to provide this information where possible.
Configuring Discretionary Access Control (DAC) contains updates to the Android IDs (AIDs) mechanism for extending filesystem capabilities.
Starting in Android 9, if there are permissions that should be denied, edit the XML to use a deny-permission tag instead of a permission tag as was used in prior releases.
Android {{ androidPVersionNumber }} provides improved support for bandwidth estimation. Android applications can make better decisions on the resolution to use for video calls and video streaming if they are aware of the data bandwidth available to them.
On devices running Android 6.0 and higher, a caller wanting a bandwidth estimate for a cellular network calls ConnectivityManager.requestBandwidthUpdate(){: .external}, and the framework may provide an estimated downlink bandwidth.
But on devices running {{ androidPVersionNumber }} or higher, the onNetworkCapabilitiesChanged(){: .external} callback automatically fires when there is a significant change in the estimated bandwidth, and calling requestBandwidthUpdate() is a no-op; the associated getLinkDownstreamBandwidthKbps(){: .external} and getLinkUpstreamBandwidthKbps(){: .external} is populated with updated information provided by the physical layer.
In addition, devices can check the LTE cell bandwidths via ServiceState.getCellBandwidths(){: .external}. This lets applications know exactly how much bandwidth (frequency) is available on a given cell. Cell bandwidth information is available via a hidden menu so that field testers can check the most current information.
The eBPF network traffic tool uses a combination of kernel and user space implementation to monitor network usage on the device since the last device boot. It provides additional functionality such as socket tagging, separating foreground/background traffic and per-UID firewall to block apps from network access depending on device state.
Devices can now restore from future versions of the operating system. This is especially useful when users have upgraded their phones but then lost or broken them.
If an OEM modifies the backup agents for any of the system packages (android, system, settings), those agents should handle restoring backups sets that were made on later versions of the platform without crashing and with restoring at least some data.
Consider using a validator to check for invalid values of a given piece of backup data and only restore valid data, as done in core/java/android/provider/SettingsValidators.java.
The feature is on by default. SettingsBackupAgent support for restoring from future versions can be turned off via Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION. No additional implementation is required unless the device manufacturer extends one of backup agents included in the ROM (or adds a custom one).
This feature allows system restores from future versions of the platform; however, it’s reasonable to expect that the restored data won’t be complete. The following instructions apply to the following backup agents:
PackageManagerBackupAgent: Supports future versions of the backup data via format versioning; extensions here MUST be compatible with current restore code or follow instructions in the class, which include bumping the proper constants.
SystemBackupAgent: restoreAnyVersion = false in Android this release and higher. Doesn’t support restore from higher versions of the API.
SettingsBackupAgent: restoreAnyVersion = true starting in this release. Partial support exists via validators. A setting can be restored from a higher API version if a validator for it exists in the target OS. Adding any setting should be accompanied by its validator. Check class for details.
Any custom backup agent included in the ROM should increase its version code any time an incompatible change is made to the backup data format and ensure restoreAnyVersion = false (the default) if their agent is not prepared to deal with backup data from a future version of their code.
Managed Profile UX changes make it easier for users to identify, access, and control the managed profile.
A new @SystemApi lets device owners indefinitely pause OTA updates, including security updates.
This release introduces includes android.hardware.health HAL 2.0, a major version upgrade from [email protected] HAL. For more information see these pages:
Android 9 includes an APK caching solution for rapid installation of preloaded apps on a device that supports A/B partitions. OEMs can place preloads and popular apps in the APK cache stored in the mostly empty B partition on new A/B-partitioned devices without impacting any user-facing data space.
This release supports using Clang's profile-guided optimization (PGO) on native Android modules that have blueprint build rules.
Compatibility WAL (Write-Ahead Logging) for Apps is a new special mode of SQLiteDatabase called Compatibility WAL (write-ahead logging) that allows a database to use journal_mode=WAL while preserving the behavior of keeping a maximum of one connection per database.
Optimizing Boot Times describes changes to boot time optimization.
Android {{ androidPVersionNumber }} introduces Background Restrictions, which allow users to restrict apps that may be draining device battery power. The system may also suggest disabling apps that it detects are negatively affecting a device's health.
Android 9 more elegantly handles batteryless devices than previous releases. Android 9 removes some previous code for batteryless devices that by default pretended a battery was present, was being charged at 100%, and was in good health with a normal temperature reading on its thermistor.