Google VINTF机制经验总结

OPPO内核工匠

于 2024-09-06 17:00:50 发布

阅读量563

点赞数 5

本文链接：https://blog.csdn.net/feelabclihu/article/details/141986294

版权

一、背景

Project Treble是Android8.0提出的一种新的架构，将供应商实现（Vendor）与Android操作系统框架分离开来。旨在让供应商以更低的成本更轻松、更快速地将设备更新到新版 Android 系统。Project Treble 适用于搭载 Android 8.0 及后续版本的所有新设备。

二、VINTF 对象

VINTF对象（Vendor Interface object），即供应商接口对象，是Treble架构分离system和vendor组件的机制之一，该对象用于汇总设备的相关信息并通过可查询的 API 提供该信息，用来检查system和vendor依赖是否匹配。该对象用于汇总设备的相关信息并通过可查询的 API 提供该信息。主要包含compatibility matrix和manifest两种类型。

1. 术语

名词	描述
框架兼容性矩阵 (FCM)	一种 XML 文件，用于指定需要满足哪些框架要求才是合规的供应商实现。兼容性矩阵带有版本编号，对于每个框架版本，都会冻结一个新版本的兼容性矩阵。每个框架版本都包含多个 FCM。
平台 FCM 版本 (S_F)	框架版本中所有 FCM 版本的集合。框架适用于所有符合其中一个 FCM 的供应商实现。
FCM 版本 (F)	在框架版本中，所有 FCM 中的版本。
目标 FCM 版本 (V)	供应商实现符合的目标 FCM 版本（S_F中的版本），已在设备清单中明确声明。必须针对已发布的 FCM 生成供应商实现，即使它可能在其设备清单中声明了更高的 HAL 版本，也是如此。
HAL 版本	HAL 版本采用foo@x格式，foo是 HAL 名称，x是具体版本。
设备清单	XML 文件，用于指定设备接口的设备端（包括供应商和 ODM 映像）提供的 HAL 版本。设备清单的内容受设备的目标 FCM 版本限制，但可以列出与 V 对应的 FCM 相比更新的 HAL。
设备 HAL	在设备清单中列出（已提供）以及在框架兼容性矩阵 (FCM) 中列出（必需或可选）的 HAL。
设备兼容性矩阵 (DCM)	一个 XML 文件，用于指定需要满足哪些供应商要求才是合规的框架实现。每个设备包含一个 DCM。
框架清单	一种 XML 文件，用于指定供应商接口的框架端（包括 system、system_ext 和 product 映像）提供的 HAL 版本。系统会根据设备的目标 FCM 版本动态停用框架清单中的 HAL。
框架 HAL	在框架清单中列出以及在设备兼容性矩阵 (DCM) 中列为必需或可选的 HAL。

2. 重要文件

设备清单（DM）：描述了设备可以为框架提供的静态组件。
框架兼容性矩阵（FCM）：描述了 Android 框架预期从给定设备中获取的内容。此矩阵是一个静态实体，我们会在开发下一个版本的 Android 框架期间手动确定此矩阵的组成。
框架清单（FM）：描述了框架可以为设备提供的高级层服务。
设备兼容性矩阵（DCM）：描述了供应商映像需要框架提供的服务，此矩阵的组成在设备开发期间由开发者手动确定。

总的来说，manifest是提供端，compatibility matrix是需求端。Manifest 描述了可以提供给对方的feature， compatibility matrix描述了需要对方提供的feature。Manifest 和 compatibility matrix在构建、开机以及OTA升级时都会进行匹配检查，以确保framework和device的兼容性。

三、HAL接口的VINTF object

在HAL接口的开发和迭代过程中，需要添加或者修改FCM/DM，VINTF object填写缺失或者不规范会造成编译报错、运行时功能问题以及VTS问题等，本文主要从HAL接口的角度来介绍VINTF。

1. 兼容性矩阵架构

compatibility-matrix.type：指定兼容型矩阵的类型，框架兼容性矩阵为”framework”，设备兼容型矩阵为”device”。
compatibility-matrix.level：指定此文件的框架兼容性矩阵版本(FCM版本) ，FCM版本与Android大版本一一对应，Android V以及之后的FCM不再以数字形式递增，Android V对应的FCM版本为202404。
compatibility-matrix.hal.format：HAL的类型，主要就是"hidl"和"aidl"两项，默认为"hidl"。
compatibility-matrix.hal.optional：true指明此 HAL 对兼容性矩阵（框架或设备）的所有者来说是可选的，false表明此HAL是必须的，设备必须提供。

除了HAL接口信息之外，还有sepolicy、kernal等相关信息，会在编译时插入到FCM中参与到后续的兼容性检查。

2. 清单架构

与兼容性矩阵不同，清单并没有集中存放，而是分布于各模块中，在Android.mk或Android.bp定义：

1）Android.mk：LOCAL_VINTF_FRAGMENTS :=.xml

2）Android.bp：vintf_fragments: [".xml"]

manifest.target-level：对于设备清单而言是必需的。用于指定相应设备清单要兼容的框架兼容性矩阵 (FCM) 版本，换句话说，声明了当前设备所搭载的FCM版本，仅在平台DM中声明。
manifest.hal.max-level：仅对框架清单有效。如果设置了此标记，最高级别低于框架清单中的目标 FCM 版本的 HAL视为被废弃。
manifest.hal.max-level.version: HAL版本。可选，默认为1.
manifest.hal.max-level.fqname: 可选且可重复。为名称是 manifest.hal.name 的 HAL 指定实例的另一种方法。

与FCM一样，除了HAL接口信息之外，DM也会在编译插入sepolicy相关信息到产物中，参与到后续的兼容性检查。

3.FCM的生命周期与HAL接口版本迭代

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

3.1 引入新的HAL

Android会为每个框架版本递增，开发期间创建新的compatibility_matrix.F.xml，且不再更改现有的 compatibility_matrix.f.xml（其中 f < F）。为使用当前有效 FCM 版本 F 的 Android 引入新 HAL（WLAN、NFC 等），需要将对应HAL加入compatibility_matrix.F.xml。

eg：当前compatibility_matrix.F.xml对应的就是compatibility_matrix.202504.xml

3.2 升级HAL

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

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

3.3 HAL版本废弃

如果在某个FCM版本(F)中废弃指定版本的HAL@x，则意味着任何搭载目标FCM版本V=F或者更高版本的设备都不得在x版本及以下实现该HAL。框架仍支持已废弃的HAL 版本，以便升级设备。

FCM 版本 (F) 发布后，如果在目标 FCM 版本 V = F 对应的最新 FCM 中未明确声明 HAL 版本 foo@x，则x版本会被视为已废弃。

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

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

四、VINTF匹配

两对兼容性矩阵和清单旨在进行协调，以验证框架和供应商实现是否可以相互协同工作。当框架兼容性矩阵与设备清单之间以及框架清单与设备兼容性矩阵之间匹配时，便会成功通过此验证。系统会在构建时、在 OTA 更新软件包生成时、启动时以及 VTS 兼容性测试中完成此验证。

1. VINTF版本匹配

如需使设备清单与框架兼容性矩阵相匹配，manifest.target-level 指定的 Shipping FCM 版本必须与 compatibility-matrix.level 指定的 FCM 版本完全相同。否则，这二者将不匹配。就是需要兼容型矩阵和设备清单的target-level值相等。

如果使用 libvintf 请求框架兼容性矩阵，则此匹配始终都会成功，因为 libvintf 会打开设备清单，检索 Shipping FCM 版本，并返回该 Shipping FCM 版本的框架兼容性矩阵（以及更高 FCM 版本的兼容性矩阵中的一些可选 HAL）。

2. HAL匹配

在FCM中，HAL元素如果具有属性时，指明此 HAL 对兼容性矩阵的所有者来说是可选的。如果某条目被标记为可选的，则设备可以不提供该HAL；如果该属性为false时，条目被标记为不可选的，则设备必须提供该HAL。

HAL 匹配规则可以识别清单文件中被视为受相应兼容性矩阵的所有者支持的HAL元素的版本。以AIDL HAL为例，匹配规则如下：

矩阵HAL版本

匹配清单HAL版本

5. 在兼容性矩阵中，5 是 5-5 的简写形式。

5-7

5 是要求的最低版本，这意味着提供 HAL 1-4 的清单不兼容。

7 是可以请求的最高版本，这意味着兼容性矩阵（框架或设备）的所有者将不会请求超过 7 的版本，设备也不得提供超过。

3. VINTF检查工具

libvintf 是 AOSP原生基于VINTF xml的接口兼容性检查工具，用于验证SV之间的兼容性矩阵和清单之间的匹配关系，以验证框架和供应商是否可以完成协同工作。当框架兼容性矩阵与设备清单之间以及框架清单与设备兼容性矩阵之间匹配时，便会成功通过此验证。

如下图所示，在Android.bp中可以看到，libvintf模块的主函数为checkvintf.cpp，libvintf模块被封装为一个host端工具：checkvintf，在构建时被调用检查框架和设备端的兼容性。整个checkvintf的检查过程主要可以分为三个部分：兼容性校验、接口废弃检查以及检查未使用的接口。

3.1兼容性校验

check_vintf.cpp：

VintfObject.cpp：

从上述代码中可以看出，兼容性校验环节，首先需要通过get函数解析VINTF，获取所有的VINTF信息，包括HAL接口信息，SDK版本信息、Sepolicy版本信息等，之后分别进行提供侧对需求侧的兼容性校验。校验共分为三类：

校验DM ↔ FCM：HAL接口和Sepolicy版本兼容性
校验FM ↔ DCM：HAL接口和SDK版本兼容性
校验RuntimeInfo ↔ FCM：运行时检查

以DM和FCM为例，首先遍历FCM中的HAL接口，如果HAL接口的”optional”值为true的话，则直接跳过该接口，反之则会在DM中寻找与之匹配的接口，如果找不到可以匹配的接口，则会输出报错信息。除了HAL的兼容性之外，还会检查SDK版本的兼容性，获取DM中的Sepolicy版本信息，检查FCM是否支持，如果不支持，则会打印报错信息。

FM与DCM的兼容性检查逻辑与上述一致，不同的点在于FM和DCM除了检查HAL接口的兼容性之外，还会检查SDK版本的兼容性，规则与检查Sepolicy 版本兼容性一样。RuntimeInfo与FCM的兼容性检查为运行时信息的兼容性检查，未涉及到暂不做分析。

3.2接口废弃检查

check_vintf.cpp：

检查逻辑：

1.将FCM分成两组，level等于target-level的target FCM与other FCM；

2.按顺序遍历other FCM中的接口，在DM中找到匹配的接口（包名、接口、实例、version）；

a)在target FCM找不到相同的接口的话，则视为该接口废弃，则打印报错信息；

b)如果在target FCM找到相同的接口；如果DM中的接口的version小于target FCM中的最小version，则视为该接口废弃，打印报错信息。

3.3检查未使用的接口

check_vintf.cpp：

VintfObject.cpp：

在这个环节中，首先获取DM和FCM中的接口信息，遍历DM中的设备HAL，如果在FCM中找不到完全匹配的接口，则会打印报错信息。

以上就是checkvintf在构建时的主要的检查逻辑，需要注意的是，兼容性检查和检查未使用的接口环节的FCM与接口废弃检查时的target FCM是一样的；兼容性检查环节接口匹配只需要DM提供的HAL接口版本大于或等于FCM的需求的HAL接口最小版本即可，而接口废弃检查环节与检查未使用的接口环节，接口匹配需要FCM的需求的接口版本包含DM提供的HAL接口版本。除此之外，该检查还会在OTA升级、开机时对VINTF文件进行检查，检查逻辑一致。