HAL 版本控制理解

HAL 版本控制理解

1. 版本控制

官方连接https://source.android.com/docs/core/architecture/hidl/versioning?hl=zh-cn#interface-version

升级规则

官方写的有点难理解，这里举例说明

先看原文

如需定义软件包 [email protected]，A 必须为 true，或 B 中的所有项必须为 true：

规则 A

“是起始 minor 版本”：所有之前的 minor 版本（[email protected]、[email protected]…package@major.(minor-1)）必须均未定义。

或

规则 B

以下各项均为 true：

1. “以前的 minor 版本有效”：package@major.(minor-1) 必须已定义，并且遵循相同的规则 A（从 [email protected] 到 package@major.(minor-2) 均未定义）或规则 B（如果它是从 @major.(minor-2) 升级而来）；

2. “继承至少一个具有相同名称的接口”：存在扩展 package@major.(minor-1)::IFoo 的接口 [email protected]::IFoo（如果前一个软件包具有接口）；

3. “没有具有不同名称的继承接口”：不得存在扩展 package@major.(minor-1)::IBaz 的 [email protected]::IBar，其中 IBar 和 IBaz 是两个不同的名称。如果存在具有相同名称的接口，[email protected]::IBar 必须扩展 package@major.(minor-k)::IBar，以确保不存在 k 较小的 IBar。

对于软件包版本升级，满足规则A或规则B中的所有选项全部满足

对于规则A

假如当前定义软件包版本为[email protected] 根据规则A，如果[email protected]之前的所有次要版本([email protected]、[email protected])都没有被定义，则就算是满足了规则A，可以进行升级，其实也可以理解为软件包的第一个版本号是可以随便定义的.

对于规则B

1. 对于规则B的第1条(以前的 minor 版本有效)： 怎么理解呢？ 这段话可以这么理解，就是我现在想定义这个版本号为 [email protected], 那么[email protected]必须被定义，但是 [email protected][email protected]不能被定义

2. 对于规则B的第2条(继承至少一个具有相同名称的接口): 比如上面的定义给出的例子，如果我前一个软件包有接口，比如package@major.(minor-1)::IFoo，则就要扩展它

3. 对于规则B的第3条(没有具有不同名称的继承接口):这里解释以下官方的例子，就是说，当你升级到新的版本时，仅需要保持相同名字接口的继承关系，不同名字的接口不必保持，其实这个在HIDL语法中已经避免了此类场景，如果你需要保持上一个版本的兼容，那么你继承上一个版本的接口，HIDL不支持多继承，所以你只能继承一个，另外，你继承了上一个版本的那个接口，其实也就间接的继承了这个接口的基类

总结来看，满足两个规则中的任意一个就可以升级

规则A：初始/major升级版本可能用的比较多

规则B：主要是对于兼容的情况下做支撑

一图胜千言，看图吧

规则A

规则B

规则B中IBaz不需要修改,根据规则B中的描述，我们直接让IBar继承1.0版本的IBar