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.0
、keymaster@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
中开发
- 将最新的
compatibility_matrix.<F-1>.xml
复制到compatibility_matrix.F.xml
。 - 将文件中的
level
属性更新为F
。 - 添加相应的构建规则以将此兼容性矩阵安装到设备。
引入新的 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 版本的一部分完成,包括以下步骤
- 确保
compatibility_matrix.F.xml
具有属性level="F"
。 - 确保所有设备构建和启动。
- 更新 VTS 测试以确保搭载最新框架(基于发货 API 级别)推出的设备的目标 FCM 版本
V >= F
。 - 将文件发布到 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.y
的 foo
。已弃用的 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.xml
、compatibility_matrix.1.xml
和 compatibility_matrix.2.xml 中。因此,health@1.0
被视为已弃用。
弃用框架 HAL
当给定的框架 HAL foo@x.y
在 FCM 版本 F
中被弃用时,这意味着任何搭载目标 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,并且仅存在于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 版本的公共和冻结的兼容性矩阵中。
- 它在框架仍然支持的公共和冻结的兼容性矩阵中。
示例
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 中进行了次要版本升级,但
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 版本在最新发布分支的框架清单中,带有 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
。