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 对应的 FCM 相比更新的 HAL。
设备 HAL 在设备清单中列出(已提供)以及在框架兼容性矩阵 (FCM) 中列出(必需或可选)的 HAL。
设备兼容性矩阵 (DCM) 一个 XML 文件,用于指定需要满足哪些供应商要求才是合规的框架实现。每个设备包含一个 DCM。
框架清单 一种 XML 文件,用于指定供应商接口的框架端(包括 system、system_ext 和 product 映像)提供的 HAL 版本。系统会根据设备的目标 FCM 版本动态停用框架清单中的 HAL。
框架 HAL 在框架清单中列为“已提供”以及在设备兼容性矩阵 (DCM) 中列为必需或可选的 HAL。

使用新 FCM 版本进行开发

Android 会针对每个框架版本递增 FCM 版本(如 Android 8、8.1 等)。在开发期间,会创建新的 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(WLAN、NFC 等)时,请将相应 HAL 添加到 compatibility_matrix.F.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.F.xml(曾在该版本的开发过程中被临时命名为 compatibility_matrix.current.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(次要版本)

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

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

例如,Android 8.1 引入了 broadcastradio@1.1 作为 1.0 HAL 的次要版本升级。对于搭载 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.F.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(主要版本)

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

  • optional="false" 且仅包含版本 x.0(如果搭载 V = F 的设备必须附带 x.0)。
  • optional="false",但与较旧的主要版本位于同一个 <hal> 标记中(如果搭载 V = F 的设备必须附带此 HAL,但可以附带较旧的主要版本)。
  • optional="true"(如果搭载 V = F 的设备可以不附带此 HAL)。

例如,Android 9 引入了 health@2.0 作为 1.0 HAL 的主要版本升级,并废弃了 1.0 HAL。对于搭载 Android 8.0 和 Android 8.1 的设备,较旧版本 health@1.0 是选用版本。搭载 Android 9 的设备不得提供已弃用的 1.0 HAL,必须改为提供新的 2.0 版本。在 compatibility_matrix.legacy.xmlcompatibility_matrix.1.xmlcompatibility_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.F.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 版本

在 system 分区上发布 FCM 版本的流程是在 AOSP 发布时由 Google 单独完成的,包含以下步骤:

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

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

此外,product 和 system_ext FCM 也可能列出每个平台 FCM 版本的相应要求。product 和 system_ext 分区上 FCM 版本的发布分别由这些映像的所有者完成。product 和 system_ext 分区上的 FCM 版本号必须与 system 分区上的 FCM 版本号一致。与 system 分区上的 FCM 版本类似,product 和 system_ext 分区中 FCM 版本的兼容性矩阵反映了运行目标 FCM 版本 F 的设备方面的要求。

HAL 版本弃用

是否废弃 HAL 版本由开发者决定(例如,是否废弃 AOSP HAL 由 Google 决定)。发布较高版本的 HAL(无论是次要版本还是主要版本)时,可能需要做出此类决定。

废弃设备 HAL

如果在 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 = F 的设备,以下条件之一为 true:

  • 框架需要较高版本(主要版本或次要版本);
  • 框架不再需要该 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

在 FCM 版本 F 下废弃指定框架 HAL foo@x.y 后,任何发布时搭载目标 FCM 版本 V = F 或更高版本的设备的该框架都不再在 x.y 或任何低于 x.y 的版本下提供 foo。框架仍提供已废弃的 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 集中移除。这是通过以下两个步骤完成的:

  • 从构建规则中移除 compatibility_matrix.V.xml以便它不再安装在系统映像中),并删除用于实现或依赖于已移除功能的所有代码。
  • 从框架清单中移除 max-level 低于或等于 V 的框架 HAL,并删除用于实现已移除的框架 HAL 的所有代码。

如果设备搭载的目标 FCM 版本不在指定框架版本的 SF 之内,则无法升级到该版本。

HAL 版本状态

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

未发布

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

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

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

已发布且当前有效

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

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

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

已发布但已废弃

对于设备 HAL,当且仅当满足以下条件时,HAL 版本才会被视为废弃:

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

示例:

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

对于框架 HAL,如果 HAL 版本在最新发布的分支的框架清单中,并且 max-level 属性低于此分支中发布的 FCM 版本,则会被视为已发布但已废弃的 HAL 版本。例如,schedulerservice HAL 已发布,但在 Android 12 中已废弃(由 Android 12framework manifest 指定)。

已移除

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

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

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

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

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

旧版 FCM

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

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

已发布的 FCM 版本

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

如需查找针对特定 Android 版本发布的 FCM 版本,请参阅 Level.h