Android 9 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)
Generic System Image (GSI) describes the Generic System Image (GSI) for Android 9, including details on differences between GSIs for devices launching with Android 9 and devices upgrading to Android 9.
Hardware Abstraction Layer
HIDL Framework Backwards Compatibility
HIDL Framework Backwards Compatibility Verification is a method for verifying the backwards compatibility of the framework.
Dynamically Available HALs
Dynamically Available HALs support the dynamic shutdown of Android hardware subsystems when they are not in use or not needed.
HIDL Memory Block
HIDL MemoryBlock is an abstract layer
HIDL @1.0::IAllocator, and
HIDL @1.0::IMapper. It is
designed for HIDL services that have multiple memory blocks to share a single
Device Tree Overlays
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.
DTO Image Header Versioning
This release inroduces 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:
- Stable Kernel Releases & Updates
- Android Common Kernels
- Modular Kernel Requirements
- Interface Requirements
- Device Tree Overlays
For information about VNDK design changes in this release, see these pages:
- Vendor Native Development Kit (VNDK)
- VNDK Build System Support
- VNDK Definition Tool
- Directories, Rules, and sepolicy
- VNDK Extensions
- Linker Namespace
VNDK: ABI Checker
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.
Vendor Interface Object
The following pages in the Vendor Interface Object section describe vendor interface object updates in this release:
HIDL Deprecation Schedule
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 compliance
Canonical Boot Reason describes changes to the bootloader boot reason specification in this release.
System as Root
All devices launching with this release must use
system-as-root, which merges
system.img (this is also known as no-ramdisk), which in turn is mounted
Boot Image Header Versioning
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.
DTBO in Recovery
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
Synchronized App Transitions allow for new app transition animations.
Text Classification (formerly TEXTCLASSIFIER)
This release introduces a Text Classifier service, which is now the recommended way to implement text classification, and a default service implementation.
Wide gamut color
This release introduces support for wide gamut color, including:
- High dynamic range (HDR)
- Processing content in the BT2020 color space, but not as an end-target dataspace
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.
Android Compatibility Definition Document (CDD)
Better App Widgets
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 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.
Device State Change Notifications to Package Installers
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
Changes to the Settings app information architecture provide more Settings functionality and easier implementation.
Atest is a new command line tool that allows users to build, install and run Android tests locally.
Compatibility Test Suite (CTS)
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
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.
Sensor Fusion Box
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:
- Sensor Fusion Box Quick Start Guide provides step-by-step directions on how to set up the Sensor Fusion test and Sensor Fusion Box for the first time.
- Sensor Fusion Box Assembly provides step-by-step instructions for assembling a Sensor Fusion Box.
Wide Field of View ITS-in-a-Box
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).
Vendor Test Suite
Host Controller Architecture
VTS Host Controller Architecture describes the architecture of VTS test framework integrated with its cloud-based test serving service.
Service Name Aware HAL Testing
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.
HAL Testability Check
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.
Automated Testing Infrastructure
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.
app usage, battery and process statistics, and crashes. The data is analyzed and
used to improve products, hardware, and services.
For more details, see
APK Signature Scheme v3 is the new APK signature scheme, which supports APK key rotation.
Android 9 includes a
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
Android 9 includes support for more exploit mitigation and analysis tools.
Control Flow Integrity (CFI)
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.
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, 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:
- Discrete CPU
- Integral secure storage
- High-quality True Random Number Generator
- Tamper-resistant packaging
- Side-channel resistance
Secure key import
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
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.
Android Protected Confirmation
Supported devices that launch with Android 9 installed give developers the
ability to use the
Android Protected Confirmation API.
By using this new API, apps can use an instance of
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.
Per-App SELinux Sandbox
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.
Treble SELinux changes
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
vendor partitions unnecessarily and
provides a method for ensuring consistency between shared system properties.
SELinux attribute tests
High-Resolution Audio Effects
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.
External USB Cameras
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 Buffer
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.
Calling and Messaging
Implementing data plans
This release provides improved support for carriers
implementing data plans using the
Third-party calling apps
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 9, 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:
Multi-SIM support for IMS settings
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.
SIM state broadcasts
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:
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
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
or they must query the state after user unlock. The states can be queried using
the corresponding APIs in TelephonyManager:
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
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)
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.
Wi-Fi Scoring improvements
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:
Wi-Fi STA/AP concurrency
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:
- Client mode (can connect and scan)
- Scan Only mode
- SoftAP mode (Wi-Fi hotspot)
- Disabled (Wi-Fi fully off)
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.
Wi-Fi permission updates
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
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
For manual testing:
- Go to Settings > Apps & notifications > Special app access > Wi-Fi control.
- Select and turn off the permission for your app.
- Verify that your app can handle the scenario where the
CHANGE_WIFI_STATEpermission 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.
Vulkan 1.1 API
This release supports implementing the Vulkan 1.1 graphics API.
WinScope tool for window transition tracing
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
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.
GNSS Satellite Selection
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.
GNSS Hardware Model
In Android 9, the GNSS HAL version 1.1 or higher can
pass information about the hardware API to the platform. The platform needs to
IGnssCallback interface and pass a handle to the HAL. The GNSS
HAL passes the hardware model information through the
API. Device manufacturers should work with their GNSS HAL providers to provide
this information where possible.
Configuring Discretionary Access Control (DAC) Updates
Configuring Discretionary Access Control (DAC) contains updates to the Android IDs (AIDs) mechanism for extending filesystem capabilities.
Update on the privileged apps permissions whitelisting
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
Bandwidth Estimation Improvements
Android 9 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
and the framework may provide an estimated downlink bandwidth.
But on devices running 9 or higher, the
callback automatically fires when there is a significant change in the estimated
bandwidth, and calling
requestBandwidthUpdate() is a no-op; the associated
is populated with updated information provided by the physical layer.
In addition, devices can check the LTE cell bandwidths via
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.
eBPF Traffic Monitoring
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.
Restore to lower APIs
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
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.
restoreAnyVersion = falsein Android this release and higher. Doesn’t support restore from higher versions of the API.
restoreAnyVersion = truestarting 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 Improvements
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@example.com 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.
Profile Guided Optimization (PGO)
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 9 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.