This page summarizes the major features in the Android 9 release, and provides links to additional information. 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)
A generic system image (GSI) is a system image with adjusted configurations for Android devices. Generic System Image (GSI) includes details on differences between GSIs for devices launching with Android 9 and devices upgrading to Android 9.
Hardware abstraction layer (HAL)
HIDL framework backwards compatibility
HIDL framework backward compatibility verification is a method for verifying the backward compatibility of the framework.
Dynamically available HALs
Dynamically available HALs support the dynamic shutdown of Android hardware subsystems when they're not in use or not needed.
HIDL MemoryBlock is an abstract layer
HIDL @1.0::IAllocator, and
HIDL @1.0::IMapper. It's
designed for HIDL services that have multiple memory blocks sharing a single
Device tree overlays
Android 9 and higher includes support for compressed overlays in the device tree blob overlay (DTBO) image when using version 1 of the device tree table header.
Android 9 and higher requires that the bootloader pass the unified device tree blob to the kernel prior to modifying the properties defined in the device tree overlays (DTOs).
DTBO image header versioning
Android 9 and higher includes a version field in the DTBO image header.
Android 9 and higher 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.
Android 9 and higher includes 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 Android 9 and higher, see these pages:
- Vendor Native Development Kit (VNDK)
- VNDK Build System Support
- VNDK Definition Tool
- Directories, Rules, and sepolicy
- VNDK Extensions
- Linker Namespace
The ABI Stability page describes the application binary interface (ABI) checker, which ensures that changes made to VNDK libraries maintain ABI compliance.
A system image can use VNDK snapshots 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 (VINTF object)
The following pages in the Vendor Interface Object section describe updates in Android 9 and higher:
HIDL deprecation schedule
The following pages describe how Android deprecates and removes HIDL HALs:
Android 9 and higher 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 the Android build system.
Canonical boot reason compliance
The Canonical Boot Reason page describes changes to the bootloader boot reason specification in Android 9 and higher.
System as root
All devices launching with Android 9 and higher must use
system-as-root, which merges
system.img (also known as no-ramdisk), which in turn is mounted
Boot image header versioning
In Android 9 and higher, the boot image header contains a field to indicate the header version. The bootloader must check this 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 Android 9 and higher include support for a user-facing control to pin screen rotation to either landscape or portrait even if the device position changes.
Synchronized app transitions
Synchronized app transitions allow for new app transition animations.
Text classification (formerly TEXTCLASSIFIER)
Android 9 and higher includes a Text Classifier service, which is the recommended way to implement text classification, and a default service implementation.
Android 9 and higher includes 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 (such as screen, hardware composer, GPU) must support wide-gamut colors or buffer formats. Devices aren't 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 shouldn't be turned off during runtime.
Android Compatibility Definition Document
Better app widgets
The Android app widget framework 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 field in their default launcher.
Note that the feature only works end to end when 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 be sent to apps that hold the
INSTALL_PACKAGES permission whenever there's a change to properties like
locale or display density. Receivers can be registered in the manifest, and a
process awakens to receive the broadcast. This is useful for package
installers that wish to install additional components of apps upon such changes,
which is uncommon, 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 information architecture for the Settings app provide more functionality and easier implementation.
The Atest command line tool allows you to build, install, and run Android tests locally, greatly speeding test re-runs without requiring knowledge of Trade Federation test harness command line options.
Compatibility Test Suite
Compatibility Test Suite (CTS) packages supporting Android 9 are available on 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 retryretries all tests that failed or weren't executed from the previous sessions.
‘--shard-countshards a CTS run into given number of independent chunks, to run on multiple devices in parallel.
In addition, the previously undocumented command
--retry-type has been added
to the same CTS v2 console command reference.
Secure Element (SE) service
The Secure Element service checks for global platform-supported secure elements by identifying whether devices have an SE HAL implementation and if so, 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 Camera Image Test Suite (Camera ITS) sensor fusion test and multi-camera sync test and provides a consistent test environment for measuring the timestamp accuracy of the camera and other sensors for Android phones. See these pages for more information:
- Sensor Fusion Box Quick Start Guide provides steps for setting up the sensor fusion test and sensor fusion box for the first time.
- Sensor Fusion Box Assembly provides steps 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 ITS.
Vendor Test Suite
Host controller architecture
The Vendor Test Suite (VTS) host controller architecture is 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 getting the service name of a given HAL instance based on the device on which 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 is a 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 use and diagnostics information about the device, the Android system, and apps. In previous versions of Android, the telemetry stack was limited and didn't 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 the
statsd telemetry feature, 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
The v3 APK signature scheme supports APK key rotation.
Android 9 includes the public class
which 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 prohibits 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, Android 9 and higher includes support for kernel control flow integrity (CFI).
Android 9 and higher includes support for metadata encryption where hardware support is present. With metadata encryption, a single key present at boot time uses file-based-encryption to encrypt any unenctypted content.
Android 9 and higher includes Keymaster 4, which has these features.
Android 9 and higher 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 API
Supported devices that launch with Android 9 installed give developers the
ability to use the
Android Protected Confirmation API.
With this 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 wants 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 targeting Android 9 and higher run individual SELinux sandboxes.
Treble SELinux changes
Updates to Treble SELinux in Android 9 and higher are documented in several pages in the SELinux section.
Vendor init closes the 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
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 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
Implement data plans
Android 9 and higher provides improved support for carriers implementing data plans using the SubscriptionPlan APIs.
Third-party calling apps
Android 9 and higher provides APIs that allow third-party (3P) 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 Android 9 and higher, the Android framework provides standard APIs for accessing eSIM and managing subscription profiles on eSIM. For more information, see:
Multi-SIM support for IMS settings
Android 9 and higher provides improvements to the user settings for IP multimedia subsystem (IMS). You can set up voiceover 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 Android 9 and higher,
Intent.ACTION_SIM_STATE_CHANGED is deprecated, and two
separate broadcasts for card state and card application state are added,
With these changes, receivers that only need to know whether a card is present don't have to listen to application state changes, and receivers that only need to know whether card applications are ready don't have to listen to changes in card state.
The two new broadcasts are @SystemApis and aren't sticky. Only receivers with
READ_PRIVILEGED_PHONE_STATE permission can receive the broadcasts.
The intents aren't rebroadcast when you unlock the device. Receivers that
depend on broadcasts sent before you unlock must either use
or they must query the state after user unlock. The states can be queried using
the corresponding APIs in TelephonyManager,
The carrier Wi-Fi feature 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 helps improve connectivity and offloads traffic.
MAC randomization lets devices use random MAC addresses when probing for new networks while not currently associated with a network. In Android 9 and higher, 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
When the Turn on Wi-Fi automatically feature is enabled, Wi-Fi is automatically re-enabled whenever the device is near a saved Wi-Fi network with a sufficiently high relative received signal strength indicator (RSSI).
Wi-Fi round trip time
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 is built on the IEEE 802.11mc protocol, and 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.
Review and tune the RSSI values in the
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) Wi-Fi, this opens up 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 modes: hotspot, scan, connect, or off), and control Wi-Fi
network actions (such as scanning or connecting).
In Android 9 and higher, the Wi-Fi framework code and implementation of
WifiStateMachine is 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
In Android 9 and higher, the
CHANGE_WIFI_STATE app permission is enabled
by default. You can disable the permission for any
app on the 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 isn't
To validate this behavior, run the roboelectric and manual tests.
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 isn't granted.
Due to security issues, Wi-Fi protected setup (WPS) in
deprecated and disabled in Android 9 and higher. However,
WiFiDirect still uses
WPS in the WPA supplicant.
Vulkan 1.1 API
Android 9 and higher supports implementing the Vulkan 1.1 graphics API.
WinScope tool for window transition tracing
Android 9 and higher includes the WinScope tool for tracing window transitions. WinScope provides infrastructure and tools to record and analyze the 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
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 monitors Android settings. Partners can change the settings from Google Play services or other system updates. These settings tell the GNSS HAL if certain GNSS satellites shouldn't 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 mixing constellations using different time systems and external events, such as leap-second, 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
method. Device manufacturers should work with their GNSS HAL providers to provide
this information where possible.
Configuring discretionary access control updates
Configuring Discretionary Access Control (DAC) contains updates to the Android IDs (AIDs) mechanism for extending file system capabilities.
Whitelisting privileged apps permissions
In Android 9 and higher, if there are permissions that
should be denied, edit the XML to use the
deny-permission tag instead of
permission tag used in prior releases.
Bandwidth estimation improvements
Android 9 provides improved support for bandwidth estimation. Android apps can make more appropriate resolution settings for video calls and video streaming if they can access the data bandwidth available.
On devices running Android 6.0 or 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's a significant change in the estimated
bandwidth, and calling
requestBandwidthUpdate() is a no-op; the associated
are populated with updated information provided by the physical layer.
In addition, devices can check the LTE cell bandwidths via
This lets applications determine 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 use on a device since the last device boot. This tool 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 higher 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 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 the
backup agents included in the ROM (or adds a custom agent).
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 the current restore code or follow instructions in the class, which include bumping the proper constants.
restoreAnyVersion = falsein Android 9 and higher. It doesn’t support a restore from higher versions of the API.
restoreAnyVersion = truein Android 9 and higher. 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 the 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
UX changes for managed profiles 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.
Android 9 and higher includes
android.hardware.health HAL 2.0, a major
version upgrade from email@example.com HAL. For more information see these pages:
APK caching solution
Android 9 and higher 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 mostly in the empty B partition on new A/B-partitioned devices without impacting any user-facing data space.
Android 9 and higher supports using Clang's profile-guided optimization (PGO) on native Android modules that have blueprint build rules.
A special mode of SQLiteDatabase called compatibility write-ahead
logging (WAL) allows a database to use
journal_mode=WAL while keeping a maximum of one connection per database.
Android 9 changes boot time optimization as described in Optimizing Boot Times.
Android 9 and higher includes background restrictions that allow users to restrict apps that may be draining battery power. The system may also suggest disabling apps that are negatively affecting a device's health.
Android 9 handles batteryless devices more elegantly than in previous releases. Android 9 removes code for batteryless devices that assumed by default that a battery was present, charged at 100%, and in good health with a normal temperature reading on its thermistor.