Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.

FCM lifecycle
Stay organized with collections Save and categorize content based on your preferences.

An Android framework release has multiple Framework Compatibility Matrixes (FCMs), one for each upgradable Target FCM Version, that define what the framework may use and Target FCM version requirements. As part of the FCM lifecycle, Android deprecates and removes HIDL HALs, then modifies FCM files to reflect the status of the HAL version.

To enable framework-only OTAs in their own ecosystems, partners who extend vendor interfaces should also deprecate and remove HIDL HALs using the same methods.

Terminology

Framework Compatibility Matrix (FCM): An XML file that specifies framework requirements on conforming vendor implementations. The compatibility matrix is versioned, and a new version is frozen for each framework release. Each framework release contains multiple FCMs.
Platform FCM Versions (S_F): The set of all FCM versions in a framework release. The framework can work with any vendor implementation that satisfies one of these FCMs.
FCM Version (F): The highest version among all FCMs in a framework release.
Target FCM Version (V): The targeted FCM version (from S_F), declared explicitly in the device manifest, that a vendor implementation satisfies. A vendor implementation must be generated against a published FCM, although it may declare newer HAL versions in its Device Manifest.
HAL Version: A HAL Version has the format foo@x.y, where foo is the HAL name and x.y is the specific version; e.g. nfc@1.0, keymaster@3.0 (the root prefix, e.g. android.hardware, is omitted throughout this document.)
Device Manifest: XML files that specify which HAL versions the device side of the vendor interface, including the vendor and ODM images, provides. The contents of a device manifest are constrained by the Target FCM version of the device but can list HALs that are strictly newer relative to the FC corresponding to V.
Device HALs: HALs that are listed (provided) in the device manifest and listed in the framework compatibility matrix (FCM).
Device Compatibility Matrix (DCM): An XML file that specifies vendor requirements on conforming framework implementations. Each device contains one DCM.
Framework Manifest: An XML file that specifies which HAL versions the framework side of the vendor interface, including system, system_ext, and product images, provides. HALs in the framework manifest are dynamically disabled according to the device's Target FCM version.
Framework HALs: HALs that are listed as provided in the framework manifest and listed in the device compatibility matrix (DCM).

FCM lifecycle in the codebase

This document describes the FCM lifecycle in the abstract. To see the supported manifests, refer to hardware/interfaces/compatibility_matrix.<FCM>.xml where FCM can be found in system/libvintf/include/vintf/Level.h.

A device shipping the corresponding Android release version is expected to have an FCM value greater than or equal to the equivalent level. For example, a device shipping with Android 11 would generally have FCM level 5, but implement FCM level 6 or greater, which comes with various additional requirements specified in the compatibility matrixes. The supported levels for Android 15 are:

FCM	Android Version
5	Android 11/R
6	Android 12/S
7	Android 13/T
8	Android 14/U
202404	Android 15/V

The FCM level is equal to or newer than the Vendor API Level.

When Android deprecates an FCM level, it's still supported for existing devices. Devices targeting lower FCM levels are implicitly allowed to use HALs listed in newer FCM levels, as long as they are available in the branch.

Develop in a new FCM version

Android increments the FCM version for each framework release (such as Android 8 and 8.1). During development, the new compatibility_matrix.F.xml is created and the existing compatibility_matrix.f.xml (where f < F) is no longer changed.

To start developing in a new FCM Version F:

Copy the latest compatibility_matrix.<F-1>.xml to compatibility_matrix.F.xml.
Update the level attribute in the file to F.
Add corresponding build rules to install this compatibility matrix to the device.

Introduce a new HAL

During development, when introducing a new HAL (Wi-Fi, NFC, etc.) to Android on the current FCM version F, add the HAL to compatibility_matrix.F.xml.

For example, Android 8.1 introduced cas@1.0. Devices launching with Android 8.1 can implement this HAL, so the following entry was added to compatibility_matrix.F.xml (which used to be named compatibility_matrix.current.xml temporarily during development of that release):

<hal format="hidl">
    <name>android.hardware.cas</name>
    <version>1.0</version>
    <interface>
        <name>IMediaCasService</name>
        <instance>default</instance>
    </interface>
</hal>

Upgrade a HAL (minor)

AIDL HAL versions count as minor HAL versions. HIDL interface versions have major.minor versions like 1.2.

During development, when an AIDL HAL has a version upgrade from 2 to 3 at current FCM Version F, the new version is added to the HAL entry in compatibility_matrix.F.xml. The version field of a HAL entry accepts ranges like 2-3.

For example, Android FCM F introduced foo@3 as a minor version upgrade of the HAL. The older version, foo@2, is used for devices targeting older FCMs while the newer version, foo@3, can be used for devices targeting Android FCM F. The entry in the older FCMs before version 2 look like:

<hal format="aidl">
    <name>foo</name>
    <version>2</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

This entry was copied to compatibility_matrix.F.xml and modified to support version 3 as follows:

<hal format="aidl">
    <name>foo</name>
    <version>2-3</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Upgrade a HAL (major)

During development, when a HAL has a major-version upgrade at current FCM Version F, the new major version x.0 is added to compatibility_matrix.F.xml with the following settings:

Only version x.0, if devices that ship with V = F must launch with x.0.
With older major versions in the same <hal> tag, if devices that ship with V = F can launch with an older major version.

For example, FCM version F introduces foo@2.0 as a major-version upgrade of the 1.0 HAL and deprecates the 1.0 HAL. The older version, foo@1.0, is used for devices targeting previous FCM versions. Devices targeting FCM version F must provide the new 2.0 version if they provide the HAL. In this example, the previous FCM versions contain this entry:

<hal format="hidl">
    <name>foo</name>
    <version>1.0</version>;
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Copy this entry to compatibility_matrix.F.xml and modify as follows:

<hal format="hidl">
    <name>foo</name>
    <version>2.0</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Restrictions:

Because the 1.0 HAL is not in compatibility_matrix.F.xml, devices that target FCM version F must not provide the 1.0 HAL (as this HAL is considered deprecated).
Because the 1.0 HAL is present in older FCM Versions, the framework can still work with the 1.0 HAL so it backward compatible with old devices that target the older FCM versions.

New FCM versions

The process of releasing an FCM Version on the system partition is done solely by Google as part of an AOSP release and includes the following steps:

Ensure the compatibility_matrix.F.xml has the attribute level="F".
Ensure all devices build and boot.
Update VTS tests to ensure devices launching with the latest framework (based on Shipping API level) have Target FCM Version V >= F.
Publish file to AOSP.

For example, VTS tests ensure that devices launching with Android 9 have Target FCM Version >= 3.

In addition, the product and system_ext FCMs may also list requirements for each platform FCM versions. Release of FCM versions on the product and system_ext partitions is done by the owner of these images, respectively. FCM version numbers on the product and system_ext partitions must align with those on the system partition. Similar to FCM versions on the system partition, the compatibility matrix at FCM version F in the product and system_ext partitions reflects requirements on a device with target FCM version F.

HAL version deprecation

Deprecating a HAL Version is a developer decision (i.e. for AOSP HALs, Google makes the decision). It could happen when a higher HAL version (whether minor or major) is released.

Deprecate a device HAL

When a given device HAL foo@x.y is deprecated at FCM Version F, it means that any device launching with Target FCM Version V = F or later must not implement foo at version x.y or any version older than x.y. A deprecated HAL version is still supported by the framework for upgrading devices.

When FCM Version F is released, a HAL Version foo@x.y is considered deprecated if the specific HAL Version is not explicitly stated in the latest FCM for Target FCM Version V = F. For devices launching with V = F, one of the following conditions is true:

The framework requires a higher version (major or minor);
The framework doesn't require the HAL anymore.

For example, in Android 9, health@2.0 is introduced as a major version upgrade of 1.0 HAL. health@1.0 is removed from compatibility_matrix.3.xml but is present in compatibility_matrix.legacy.xml, compatibility_matrix.1.xml, and compatibility_matrix.2.xml. Hence, health@1.0 is considered deprecated.

Deprecate a framework HAL

When a given framework HAL foo@x.y is deprecated at FCM Version F, it means that any device launching with Target FCM Version V = F or later must not expect the framework to provide foo at version x.y, or at any version older than x.y. A deprecated HAL version is still provided by the framework for upgrading devices.

When FCM version F is released, a HAL Version foo@x.y is considered deprecated if the framework manifest specifies max-level="F - 1" for foo@x.y. For devices launching with V = F, the framework doesn't provide the HAL foo@x.y. The device compatibility matrix on devices launching with V = F must not list framework HALs with max-level < V.

For example, in Android 12, schedulerservice@1.0 is deprecated. Its max-level attribute is set to 5, the FCM version introduced in Android 11. See Android 12 framework manifest.

Removal of support for target FCM versions

When active devices of a certain Target FCM Version V drop below a certain threshold, the Target FCM Version is removed from the set S_F of the next framework release. This is done by both of the following steps:

Removing compatibility_matrix.V.xml from the build rules (so that it isn't installed on the system image), and deleting any code that implemented or depended on the removed capabilities.
Removing framework HALs with max-level lower than or equal to V from the framework manifest, and deleting any code that implements the removed framework HALs.

Devices with a target FCM Version outside of S_F for a given framework release cannot upgrade to that release.

Removal of fully deprecated HALs

When an FCM version is removed, some HAL interfaces, or versions of HAL interfaces, are no longer present in any FCMs. This means that Android no longer supports them at all, even for upgrading devices.

After a HAL is no longer supported, developers remove references to that HAL interface from Android, including in the client code in the framework, the default implementation, and VTS test cases.

If there are no supported HALs inheriting from the HAL being removed, then the HAL definition itself can be removed with a few extra steps.

Remove the HAL interface definition from the source code. This includes the *.aidl files and the Android.bp aidl_interface module.
If HIDL, remove the HASH from hardware/interfaces/current.txt.
If AIDL, remove the aidl_api directory with the frozen AIDL files.
Remove the interface from hardware/interfaces/compatibility_matrices/exclude/fcm_exclude.cpp.

HAL version status

The following sections describe (in chronological order) the possible states of a HAL Version.

Unreleased

For device HALs, if a HAL Version is not in any of the public and frozen compatibility matrixes, it is considered unreleased and possibly in development. This includes HAL Versions that are only in compatibility_matrix.F.xml. Examples:

During the development of Android 9 the health@2.0 HAL was considered an unreleased HAL and was only present in compatibility_matrix.3.xml.
The teleportation@1.0 HAL is not in any released compatibility matrixes, and is also considered an unreleased HAL.

For framework HALs, if a HAL version is only in the framework manifest of an unrelated development branch, it's considered unreleased.

Released and current

For device HALs, if a HAL Version is in any public and frozen compatibility matrix, it is released. For example, after FCM Version 3 is frozen and published to AOSP, the health@2.0 HAL is considered a released and current HAL Version.

If a HAL Version is in a public and frozen compatibility matrix that has the highest FCM Version the HAL version is current (i.e. not deprecated). For example, existing HAL Versions (such as nfc@1.0 introduced in compatibility_matrix.legacy.xml) that continue to exist in compatibility_matrix.3.xml are also considered as released and current HAL Versions.

For framework HALs, if a HAL version is in the framework manifest of the latest released branch without the max-level attribute or (unusually) a max-level equal to or higher than the FCM version released in this branch, it is considered a released and current HAL version. For example, the displayservice HAL is released and current in Android 12, as specified by the Android 12 framework manifest.

Released but deprecated

For device HALs, a HAL Version is deprecated if and only if all of the following are met:

It is released.
It is not in the public and frozen compatibility matrix that has the highest FCM Version.
It is in a public and frozen compatibility matrix that the framework still supports.

Examples:

The health@1.0 HAL is in compatibility_matrix.legacy.xml, compatibility_matrix.1.xml, and compatibility_matrix.2.xml, but not in compatibility_matrix.3.xml. Hence it is considered deprecated in Android 9.
The power HAL has a minor version upgrade in Android 9, but power@1.0 is still in compatibility_matrix.3.xml.
power@1.0 compatibility_matrix.legacy.xml, compatibility_matrix.1.xml, and compatibility_matrix.2.xml.
compatibility_matrix.3.xml has power@1.0-1.

Hence power@1.0 is current, but NOT deprecated, in Android 9.

For framework HALs, if a HAL version is in the framework manifest of the latest released branch with a max-level attribute lower than the FCM version release in this branch, it is considered a released but deprecated HAL version. For example, the schedulerservice HAL is released but deprecated in Android 12, as specified by the Android 12 framework manifest.

Removed

For device HALs, a HAL Version is removed if and only if the following are true:

It was previously released.
It is not in any public and frozen compatibility matrix that the framework supports.

Compatibility matrixes that are public, frozen, but not supported by the framework are kept in the codebase to define the removed HAL Versions set so that VTS tests can be written to ensure removed HALs are not on new devices.

For framework HALs, a HAL version is removed if and only if the following are met:

It was previously released.
It is not in any framework manifest of the latest released branch.

Legacy FCMs

Target FCM Version legacy is a special value for all non-Treble devices. The legacy FCM, compatibility_matrix.legacy.xml, lists the requirements of the framework on legacy devices (i.e. devices launched prior to Android 8.0).

If this file exists for an FCM with version F, any non-Treble device can be upgraded to F provided its device manifest is compatible with this file. Its removal follows the same procedure as FCMs for other Target FCM Versions (removed after the number of active pre-8.0 devices drops below a certain threshold).

Released FCM versions

The list of released FCM versions can be found under hardware/interfaces/compatibility_matrices.

To find the FCM version released with a specific Android release, see Level.h.