FCM 生命周期

Android 框架版本具有多个框架兼容性矩阵 (FCM)，每个矩阵对应一个可升级的目标 FCM 版本，用于定义框架可以使用哪些内容以及目标 FCM 版本要求。在 FCM 生命周期中，Android 会弃用并移除 HIDL HAL，然后修改 FCM 文件，以反映 HAL 版本的状态。

要在自己的生态系统中启用仅针对框架的 OTA，扩展供应商接口的合作伙伴还应使用相同的方法弃用并移除 HIDL HAL。

术语

框架兼容性矩阵 (FCM)	一种 XML 文件，用于指定需要满足哪些框架要求才是合规的供应商实现。兼容性矩阵带有版本编号，对于每个框架版本，都会冻结一个新版本的兼容性矩阵。每个框架版本都包含多个 FCM。
平台 FCM 版本 (S_F)	框架版本中所有 FCM 版本的集合。框架适用于所有符合其中一个 FCM 的供应商实现。
FCM 版本 (F)	在框架版本中，所有 FCM 中的最高版本。
目标 FCM 版本 (V)	供应商实现符合的目标 FCM 版本（S_F 中的版本），已在设备清单中明确声明。必须针对已发布的 FCM 生成供应商实现，即使它可能在其设备清单中声明了更高的 HAL 版本，也是如此。
HAL 版本	HAL 版本采用 `foo@x.y` 格式，其中 `foo` 是 HAL 名称，`x.y` 是具体版本；例如 `nfc@1.0`、`keymaster@3.0`（本文档中省略了根前缀，例如 `android.hardware`。）
设备清单	一种 XML 文件，用于指定供应商映像提供了哪些 HAL 版本。设备清单的内容受设备的目标 FCM 版本限制，但可以列出与 V 对应的 FCM 相比更新的 HAL。

使用新 FCM 版本进行开发

Android 会针对每个框架版本递增 FCM 版本（如 Android 8、8.1 等）。在开发期间，会创建新的 compatibility_matrix.current.xml (F)，且不再更改现有的 compatibility_matrix.f.xml（其中 f < F）。

要开始使用新 FCM 版本 F 进行开发，请执行以下操作：

将最新的 compatibility_matrix.<F-1>.xml 复制到 compatibility_matrix.current.xml。
将文件中的 level 属性更新为 F。
添加相应的编译规则，以便将此兼容性矩阵安装到设备。

引入新 HAL

在开发期间，为使用当前有效 FCM 版本 F 的 Android 引入新 HAL（WLAN、NFC 等）时，请将相应 HAL 添加到 compatibility_matrix.current.xml，并采用以下 optional 设置：

optional="false"（如果搭载 V = F 的设备必须附带此 HAL），

或者
optional="true"（如果搭载 V = F 的设备可以不附带此 HAL）。

例如，Android 8.1 引入了 cas@1.0 作为选用 HAL。搭载 Android 8.1 的设备无需实现此 HAL，因此将以下条目添加到了 compatibility_matrix.current.xml（Android 8.1 发布后已改名为 compatibility_matrix.2.xml）中：

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

升级 HAL (Minor)

开发期间，在当前有效 FCM 版本 F 下将 HAL 的 Minor 版本从 x.z 升级到 x.(z+1) 时，如果：

搭载 V = F 的设备必须使用此版本，则 compatibility_matrix.current.xml 必须声明 x.(z+1) 和 optional="false"。
搭载 V = F 的设备无需使用此版本，则 compatibility_matrix.current.xml 必须从 compatibility_matrix.<F-1>.xml 复制 x.y-z 和可选性，并将版本更改为 x.w-(z+1)（其中 w >= y）。

例如，Android 8.1 引入了 broadcastradio@1.1 作为 1.0 HAL 的 Minor 版本升级。对于搭载 Android 8.0 的设备，较旧版本 broadcastradio@1.0 是选用版本；对于搭载 Android 8.1 的设备，较新版本 broadcastradio@1.1 是选用版本。在 compatibility_matrix.1.xml 中：

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

此条目复制到了 compatibility_matrix.current.xml（Android 8.1 发布后已改名为 compatibility_matrix.2.xml），并进行了以下修改：

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0-1</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

升级 HAL (Major)

在开发期间，当 HAL 有在当前有效 FCM 版本 F 下的 Major 版本升级时，新的 Major 版本 x.0 会添加到 compatibility_matrix.current.xml，并会采用以下 optional 设置：

optional="false" 且仅包含版本 x.0（如果搭载 V = F 的设备必须附带 x.0）。
optional="false"，但与较旧的 Major 版本位于同一个 <hal> 标记中（如果搭载 V = F 的设备必须附带此 HAL，但可以附带较旧的 Major 版本）。
optional="true"（如果搭载 V = F 的设备无需附带此 HAL）。

例如，Android 9 引入了 health@2.0 作为 1.0 HAL 的 Major 版本升级，并弃用了 1.0 HAL。对于搭载 Android 8.0 和 Android 8.1 的设备，较旧版本 health@1.0 是选用版本。搭载 Android 9 的设备不得提供已弃用的 1.0 HAL，必须改为提供新的 2.0 版本。在 compatibility_matrix.legacy.xml、compatibility_matrix.1.xml 和 compatibility_matrix.2.xml 中：

<hal format="hidl" optional="true">
    <name>android.hardware.health</name>
    <version>1.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

此条目复制到了 compatibility_matrix.current.xml（在 Android 9 版本中已改名为 compatibility_matrix.3.xml），并进行了以下修改：

<hal format="hidl" optional="false">
    <name>android.hardware.health</name>
    <version>2.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

限制条件：

由于 2.0 HAL 在 compatibility_matrix.3.xml 中且 optional="false"，因此搭载 Android 9 的设备必须附带 2.0 HAL。
由于 1.0 HAL 不在 compatibility_matrix.3.xml 中，因此搭载 Android 9 的设备不得提供 1.0 HAL（因为此 HAL 会被视为已弃用）。
由于 1.0 HAL 作为选用 HAL 存在于 legacy/1/2.xml（Android 9 可以支持的较旧 FCM 版本）中，因此 Android 9 框架仍可以支持 1.0 HAL（不会被视为已移除的 HAL 版本）。

新 FCM 版本

FCM 版本的发布过程是在 AOSP 发布时由 Google 单独完成的，包含以下步骤：

将 compatibility_matrix.current.xml 改名为 compatibility_matrix.F.xml。
确保该文件具有属性 level="F"。
修改相应编译规则，以反映文件名更改。
确保所有设备都已编译并启动。
更新 VTS 测试，确保附带最新框架（基于 Shipping API 级别）的设备搭载的目标 FCM 版本 V >= F。
将文件发布到 AOSP。

此文件一经改名并发布，便无法更改。例如，在 Android 9 开发期间，针对 hardware/interfaces/compatibility_matrices/ 编译了以下文件：

compatibility_matrix.legacy.xml
compatibility_matrix.1.xml
compatibility_matrix.2.xml
compatibility_matrix.current.xml

Android 9 发布后，compatibility_matrix.current.xml 改名为 compatibility_matrix.3.xml，并针对 hardware/interfaces/compatibility_matrices/ 编译了以下文件：

compatibility_matrix.legacy.xml
compatibility_matrix.1.xml
compatibility_matrix.2.xml
compatibility_matrix.3.xml

VTS 测试旨在确保搭载 Android 9 的设备的目标 FCM 版本 >= 3。

HAL 版本弃用

是否弃用 HAL 版本由开发者决定（例如，是否弃用 AOSP HAL 由 Google 决定）。发布较高版本的 HAL（无论是 Minor 版本还是 Major 版本）时，可能需要做出此类决定。如果在 FCM 版本 F 下弃用指定 HAL foo@x.y，则意味着任何搭载目标 FCM 版本 V = F 或更高版本的设备都不得在 x.y 或任何低于 x.y 的版本下实现 foo。框架仍支持已弃用的 HAL 版本，以便升级设备。

FCM 版本 F 发布后，如果目标 FCM 版本 V = F 对应的最新 FCM 中未明确声明 HAL 版本 foo@x.y，则该版本会被视为已弃用。对于搭载 V 的设备，以下条件之一为 true：

框架需要较高版本（Major 版本或 Minor 版本）；
框架不再需要该 HAL。

例如，Android 9 引入了 health@2.0 作为 1.0 HAL 的 Major 版本升级。health@1.0 从 compatibility_matrix.3.xml 中移除了，但存在于 compatibility_matrix.legacy.xml、compatibility_matrix.1.xml 和 compatibility_matrix.2.xml 中。因此，health@1.0 会被视为已弃用。

取消对目标 FCM 版本的支持

当搭载某个目标 FCM 版本 V 的有效设备数量降至特定阈值以下时，应将该目标 FCM 版本从下一个框架版本的 S_F 集中移除，方法是从编译规则中移除 compatibility_matrix.V.xml（以便它不再安装在系统映像中），并删除用于实现或依赖于已移除功能的所有代码。如果设备搭载的目标 FCM 版本不在指定框架版本的 S_F 之内，则无法升级到该版本。

HAL 版本状态

下文介绍了 HAL 版本的可能状态（按时间先后顺序）。

未发布

如果 HAL 版本不在任何公开且冻结的兼容性矩阵中，则被视为未发布且可能正在开发中。这包括仅在 compatibility_matrix.current.xml 中的 HAL 版本。示例：

在 Android 9 开发期间（在 compatibiility_matrix.current.xml 改名为 compatibility_matrix.3.xml 之前），health@2.0 HAL 被视为未发布的 HAL。
teleportation@1.0 HAL 不在任何已发布的兼容性矩阵中，也被视为未发布的 HAL。

已发布且当前有效

如果 HAL 版本位于任何公开且冻结的兼容性矩阵中，则为已发布版本。例如，FCM 版本 3 冻结（当 compatibiility_matrix.current.xml 已改名为 compatibility_matrix.3.xml 时）并发布到 AOSP 后，health@2.0 HAL 会被视为已发布且当前有效的 HAL 版本。

如果 HAL 版本位于包含最高 FCM 版本的公开且冻结兼容性矩阵中（compatibility_matrix.current.xml 除外），则 HAL 版本为当前有效版本（即未弃用版本）。例如，如果现有 HAL 版本（例如，在 compatibility_matrix.legacy.xml 中引入的 nfc@1.0）继续存在于 compatibility_matrix.3.xml 中，则也会被视为已发布且当前有效的 HAL 版本。

已发布但已弃用

当且仅当存在以下情况时，HAL 版本会被视为已弃用：

已发布；
不在包含最高 FCM 版本的公开且冻结兼容性矩阵中；
在框架仍支持的公开且冻结兼容性矩阵中。

示例：

health@1.0 HAL 在 compatibility_matrix.legacy.xml、compatibility_matrix.1.xml 和 compatibility_matrix.2.xml 中，但不在 compatibility_matrix.3.xml 中。因此，它在 Android 9 中被视为已弃用。
电量 HAL 在 Android 9 中有 Minor 版本升级，但 power@1.0 仍在 compatibility_matrix.3.xml 中。
- power@1.0 在 compatibility_matrix.legacy.xml、compatibility_matrix.1.xml 和 compatibility_matrix.2.xml 中。
- compatibility_matrix.3.xml 包含 power@1.0-1。

因此，在 Android 9 中，power@1.0 为当前有效版本，而不是已弃用版本。

已移除

当且仅当存在以下情况时，HAL 版本会被视为已移除：

之前已发布；
不在框架支持的任何公开且冻结兼容性矩阵中。

不受框架支持的公开且冻结兼容性矩阵会保留在代码库中，以便指定已移除的 HAL 版本集，从而可以写入 VTS 测试，确保新设备上没有已移除的 HAL。

旧版 FCM

对于所有不支持 Treble 的设备，旧版目标 FCM 版本是一个特殊值。旧版 FCM compatibility_matrix.legacy.xml 列出了框架对旧版设备（即搭载 Android 8.0 之前版本的设备）的要求。

如果版本为 F 的 FCM 具有此文件，则任何不支持 Treble 的设备均可升级到 F，但前提是其设备清单与此文件兼容。移除旧版 FCM 的程序与移除其他目标 FCM 版本对应的 FCM 的程序相同（在搭载 8.0 之前版本的有效设备数量降至特定阈值以下后移除）。