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 文件,用于指定供应商映像提供了哪些 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 版本
在 system 分区上发布 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。
此外,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(无论是 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 版本从下一个框架版本的 SF 集中移除。方法是从构建规则中移除 compatibility_matrix.V.xml
(以便它不再安装在系统映像中),并删除用于实现或依赖于已移除功能的所有代码。如果设备搭载的目标 FCM 版本不在指定框架版本的 SF 之内,则无法升级到该版本。
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 之前版本的有效设备数量降至特定阈值以下后移除)。
已发布的 FCM 版本
您可以在 hardware/interfaces/compatibility_matrices
下找到已发布的 FCM 版本的列表。
如需查找针对特定 Android 版本发布的 FCM 版本,请参阅Level.h
。