FCM 生命周期

Android 框架版本具有多个框架兼容性矩阵 (FCM),每个可升级的目标 FCM 版本各有一个,用于定义框架可能使用的内容和目标 FCM 版本要求。作为 FCM 生命周期的一部分,Android 会弃用和移除 HIDL HAL,然后修改 FCM 文件以反映 HAL 版本的状态。

为了在其自身的生态系统中启用仅框架 OTA,扩展供应商接口的合作伙伴也应使用相同的方法弃用和移除 HIDL HAL。

术语

框架兼容性矩阵 (FCM)
一个 XML 文件,用于指定框架对一致的供应商实现的要求。兼容性矩阵是版本化的,并且每个框架版本都会冻结一个新版本。每个框架版本都包含多个 FCM。
平台 FCM 版本 (SF)
框架版本中所有 FCM 版本的集合。框架可以与满足其中一个 FCM 的任何供应商实现协同工作。
FCM 版本 (F)
框架版本中所有 FCM 中的最高版本。
目标 FCM 版本 (V)
目标 FCM 版本(来自 SF),在设备清单中显式声明,供应商实现满足该版本。供应商实现必须针对已发布的 FCM 生成,尽管它可以在其设备清单中声明较新的 HAL 版本。
HAL 版本
HAL 版本的格式为 foo@x.y,其中 foo 是 HAL 名称,x.y 是特定版本;例如 nfc@1.0keymaster@3.0(根前缀,例如 android.hardware,在本文档中省略)。
设备清单
XML 文件,用于指定供应商接口的设备端(包括供应商和 ODM 映像)提供的 HAL 版本。设备清单的内容受设备的目标 FCM 版本的约束,但可以列出相对于对应于 V 的 FC 而言严格更新的 HAL。
设备 HAL
在设备清单中列出(提供)并在框架兼容性矩阵 (FCM) 中列出的 HAL。
设备兼容性矩阵 (DCM)
一个 XML 文件,用于指定供应商对一致的框架实现的要求。每个设备都包含一个 DCM。
框架清单
一个 XML 文件,用于指定供应商接口的框架端(包括 system、system_ext 和 product 映像)提供的 HAL 版本。框架清单中的 HAL 根据设备的目标 FCM 版本动态禁用。
框架 HAL
在框架清单中列为提供并在设备兼容性矩阵 (DCM) 中列出的 HAL。

代码库中的 FCM 生命周期

本文档从抽象层面描述了 FCM 生命周期。要查看受支持的清单,请参阅 hardware/interfaces/compatibility_matrix.<FCM>.xml,其中 FCM 可以在 system/libvintf/include/vintf/Level.h 中找到。

搭载相应 Android 版本的设备应具有大于或等于等效级别的 FCM 值。例如,搭载 Android 11 的设备通常具有 FCM 级别 5,但会实现 FCM 级别 6 或更高级别,这附带兼容性矩阵中指定的各种附加要求。Android 15 支持的级别为

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

FCM 级别等于或高于供应商 API 级别

当 Android 弃用 FCM 级别时,它仍然支持现有设备。目标 FCM 级别较低的设备隐式允许使用较新 FCM 级别中列出的 HAL,只要这些 HAL 在分支中可用即可。

在新 FCM 版本中开发

Android 为每个框架版本(例如 Android 8 和 8.1)递增 FCM 版本。在开发期间,会创建新的 compatibility_matrix.F.xml,并且不再更改现有的 compatibility_matrix.f.xml(其中 f < F)。

要开始在新 FCM 版本 F 中开发

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

引入新的 HAL

在开发期间,当在当前 FCM 版本 F 上向 Android 引入新的 HAL(Wi-Fi、NFC 等)时,将 HAL 添加到 compatibility_matrix.F.xml

例如,Android 8.1 引入了 cas@1.0。搭载 Android 8.1 推出的设备可以实现此 HAL,因此将以下条目添加到 compatibility_matrix.F.xml(在该版本的开发期间,临时命名为 compatibility_matrix.current.xml

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

升级 HAL(次要版本)

AIDL HAL 版本计为次要 HAL 版本。HIDL 接口版本具有 major.minor 版本,例如 1.2

在开发期间,当 AIDL HAL 在当前 FCM 版本 F 从版本 2 升级到 3 时,新版本将添加到 compatibility_matrix.F.xml 中的 HAL 条目。HAL 条目的版本字段接受诸如 2-3 之类的范围。

例如,Android FCM F 引入了 foo@3 作为 HAL 的次要版本升级。旧版本 foo@2 用于以旧 FCM 为目标的设备,而新版本 foo@3 可用于以 Android FCM F 为目标的设备。版本 2 之前的旧 FCM 中的条目如下所示

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

此条目被复制到 compatibility_matrix.F.xml 并修改为支持版本 3,如下所示

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

升级 HAL(主要版本)

在开发期间,当 HAL 在当前 FCM 版本 F 进行主要版本升级时,新的主要版本 x.0 将添加到 compatibility_matrix.F.xml,并带有以下设置

  • 仅版本 x.0,如果搭载 V = F 推出的设备必须使用 x.0 启动。
  • 在同一 <hal> 标记中使用较旧的主要版本,如果搭载 V = F 推出的设备可以使用较旧的主要版本启动。

例如,FCM 版本 F 引入了 foo@2.0 作为 1.0 HAL 的主要版本升级,并弃用了 1.0 HAL。旧版本 foo@1.0 用于以之前的 FCM 版本为目标的设备。以 FCM 版本 F 为目标的设备如果提供 HAL,则必须提供新的 2.0 版本。在此示例中,之前的 FCM 版本包含此条目

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

将此条目复制到 compatibility_matrix.F.xml 并按如下方式修改

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

限制

  • 由于 compatibility_matrix.F.xml 中没有 1.0 HAL,因此以 FCM 版本 F 为目标的设备不得提供 1.0 HAL(因为此 HAL 被视为已弃用)。
  • 由于 1.0 HAL 存在于旧 FCM 版本中,因此框架仍然可以与 1.0 HAL 协同工作,因此它向后兼容以旧 FCM 版本为目标的旧设备。

新的 FCM 版本

在系统分区上发布 FCM 版本的流程完全由 Google 作为 AOSP 版本的一部分完成,包括以下步骤

  1. 确保 compatibility_matrix.F.xml 具有属性 level="F"
  2. 确保所有设备构建和启动。
  3. 更新 VTS 测试以确保搭载最新框架(基于发货 API 级别)推出的设备的目标 FCM 版本 V >= F
  4. 将文件发布到 AOSP。

例如,VTS 测试确保搭载 Android 9 推出的设备的目标 FCM 版本 >= 3。

此外,产品和 system_ext FCM 也可能列出每个平台 FCM 版本的需求。产品和 system_ext 分区上的 FCM 版本的发布分别由这些映像的所有者完成。产品和 system_ext 分区上的 FCM 版本号必须与系统分区上的版本号一致。与系统分区上的 FCM 版本类似,产品和 system_ext 分区中 FCM 版本 F 的兼容性矩阵反映了对目标 FCM 版本为 F 的设备的要求。

HAL 版本弃用

弃用 HAL 版本是开发人员的决定(即,对于 AOSP HAL,Google 做出决定)。当发布更高的 HAL 版本(无论是次要版本还是主要版本)时,可能会发生这种情况。

弃用设备 HAL

当给定的设备 HAL foo@x.y 在 FCM 版本 F 中被弃用时,这意味着任何搭载目标 FCM 版本 V = F 或更高版本推出的设备都不得实现版本 x.y 或任何版本早于 x.yfoo。已弃用的 HAL 版本仍受框架支持以用于升级设备。

当 FCM 版本 F 发布时,如果特定 HAL 版本未在目标 FCM 版本 V = F 的最新 FCM 中明确声明,则 HAL 版本 foo@x.y 被视为已弃用。对于搭载 V = F 推出的设备,以下条件之一为真

  • 框架需要更高的版本(主要版本或次要版本);
  • 框架不再需要该 HAL。

例如,在 Android 9 中,health@2.0 作为 1.0 HAL 的主要版本升级而引入。health@1.0 已从 compatibility_matrix.3.xml 中移除,但存在于 compatibility_matrix.legacy.xmlcompatibility_matrix.1.xmlcompatibility_matrix.2.xml 中。因此,health@1.0 被视为已弃用。

弃用框架 HAL

当给定的框架 HAL foo@x.y 在 FCM 版本 F 中被弃用时,这意味着任何搭载目标 FCM 版本 V = F 或更高版本推出的设备都不得期望框架提供版本 x.y 或任何版本早于 x.yfoo。已弃用的 HAL 版本仍然由框架提供,以用于升级设备。

当 FCM 版本 F 发布时,如果框架清单为 foo@x.y 指定了 max-level="F - 1",则 HAL 版本 foo@x.y 被视为已弃用。对于搭载 V = F 推出的设备,框架不提供 HAL foo@x.y。搭载 V = F 推出的设备上的设备兼容性矩阵不得列出 max-level < V 的框架 HAL。

例如,在 Android 12 中,schedulerservice@1.0 已弃用。其 max-level 属性设置为 5,即在 Android 11 中引入的 FCM 版本。请参阅Android 12 框架清单

移除对目标 FCM 版本的支持

当特定目标 FCM 版本 V 的活跃设备数量降至一定阈值以下时,目标 FCM 版本将从下一个框架版本的 SF 集合中移除。这通过以下两个步骤完成

  1. 从构建规则中移除 compatibility_matrix.V.xml(以便它不会安装在系统映像上),并删除任何实现或依赖于已移除功能的代码。

  2. 从框架清单中移除 max-level 低于或等于 V 的框架 HAL,并删除任何实现已移除框架 HAL 的代码。

目标 FCM 版本在给定框架版本的 SF 之外的设备无法升级到该版本。

HAL 版本状态

以下部分按时间顺序描述了 HAL 版本的可能状态。

未发布

对于设备 HAL,如果 HAL 版本不在任何公共和冻结的兼容性矩阵中,则它被视为未发布,并且可能正在开发中。这包括仅在 compatibility_matrix.F.xml 中的 HAL 版本。示例

  • 在 Android 9 的开发过程中,health@2.0 HAL 被视为未发布的 HAL,并且仅存在于 compatibility_matrix.3.xml 中。
  • teleportation@1.0 HAL 不在任何已发布的兼容性矩阵中,也被视为未发布的 HAL。

对于框架 HAL,如果 HAL 版本仅在不相关的开发分支的框架清单中,则它被视为未发布。

已发布且当前

对于设备 HAL,如果 HAL 版本在任何公共和冻结的兼容性矩阵中,则它已发布。例如,在 FCM 版本 3 冻结并发布到 AOSP 之后,health@2.0 HAL 被视为已发布且当前的 HAL 版本。

如果 HAL 版本在具有最高 FCM 版本的公共和冻结的兼容性矩阵中,则 HAL 版本是当前的(即,未弃用)。例如,继续存在于 compatibility_matrix.3.xml 中的现有 HAL 版本(例如 nfc@1.0,在 compatibility_matrix.legacy.xml 中引入)也被视为已发布且当前的 HAL 版本。

对于框架 HAL,如果 HAL 版本在最新发布分支的框架清单中,没有 max-level 属性,或者(非常规地)max-level 等于或高于此分支中发布的 FCM 版本,则它被视为已发布且当前的 HAL 版本。例如,Android 12 框架清单指定,displayservice HAL 在 Android 12 中已发布且是当前的。

已发布但已弃用

对于设备 HAL,当且仅当满足以下所有条件时,HAL 版本才会被弃用

  • 它已发布。
  • 它不在具有最高 FCM 版本的公共和冻结的兼容性矩阵中。
  • 它在框架仍然支持的公共和冻结的兼容性矩阵中。

示例

因此,在 Android 9 中,power@1.0 是当前的,但不是已弃用的。

对于框架 HAL,如果 HAL 版本在最新发布分支的框架清单中,带有 max-level 属性,且该属性低于此分支中发布的 FCM 版本,则它被视为已发布但已弃用的 HAL 版本。例如,Android 12 框架清单指定,schedulerservice HAL 在 Android 12 中已发布但已弃用。

已移除

对于设备 HAL,当且仅当满足以下条件时,HAL 版本才会被移除

  • 它以前已发布。
  • 它不在框架支持的任何公共和冻结的兼容性矩阵中。

代码库中保留了公共、冻结但不受框架支持的兼容性矩阵,以定义已移除的 HAL 版本集,以便可以编写 VTS 测试来确保新设备上没有已移除的 HAL。

对于框架 HAL,当且仅当满足以下条件时,HAL 版本才会被移除

  • 它以前已发布。
  • 它不在最新发布分支的任何框架清单中。

旧版 FCM

目标 FCM 版本 legacy 是所有非 Treble 设备的特殊值。旧版 FCM compatibility_matrix.legacy.xml 列出了框架对旧版设备(即在 Android 8.0 之前推出的设备)的要求。

如果版本为 F 的 FCM 存在此文件,则任何非 Treble 设备都可以升级到 F,前提是其设备清单与此文件兼容。它的移除遵循与其他目标 FCM 版本的 FCM 相同的程序(在 8.0 之前的活跃设备数量降至一定阈值以下后移除)。

已发布的 FCM 版本

已发布的 FCM 版本列表可以在 hardware/interfaces/compatibility_matrices 下找到。

要查找随特定 Android 版本发布的 FCM 版本,请参阅 Level.h