自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
接口哈希
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本文档介绍了 HIDL 接口哈希,这是一种旨在防止接口遭到意外更改并确保接口更改经过全面审查的机制。这种机制是必需的,因为 HIDL 接口带有版本编号,也就是说,接口一经发布便不得再更改,但不会影响应用二进制接口 (ABI) 的情况(例如更正备注)除外。
布局
每个软件包根目录(即映射到 hardware/interfaces
的 android.hardware
或映射到 vendor/foo/hardware/interfaces
的 vendor.foo
)都必须包含一个列出所有已发布 HIDL 接口文件的 current.txt
文件。
# current.txt files support comments starting with a '#' character
# this file, for instance, would be vendor/foo/hardware/interfaces/current.txt
# Each line has a SHA-256 hash followed by the name of an interface.
# They have been shortened in this doc for brevity but they are
# 64 characters in length in an actual current.txt file.
d4ed2f0e...995f9ec4 vendor.awesome.foo@1.0::IFoo # comments can also go here
# types.hal files are also noted in current.txt files
c84da9f5...f8ea2648 vendor.awesome.foo@1.0::types
# Multiple hashes can be in the file for the same interface. This can be used
# to note how ABI sustaining changes were made to the interface.
# For instance, here is another hash for IFoo:
# Fixes type where "FooCallback" was misspelled in comment on "FooStruct"
822998d7...74d63b8c vendor.awesome.foo@1.0::IFoo
注意:为了方便跟踪各个哈希的来源,Google 将 HIDL current.txt
文件分成了不同的部分:第一部分列出了 Android 8 中发布的接口文件,第二部分列出了 Android 8 MR1 中发布的接口文件。我们强烈建议在您的 current.txt
文件中使用类似布局。
使用 hidl-gen 添加哈希
您可以手动将哈希添加到 current.txt
文件中,也可以使用 hidl-gen
添加。以下代码段提供了可与 hidl-gen
搭配使用来管理 current.txt
文件的命令示例(哈希已缩短):
hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0::types
9626fd18...f9d298a6 vendor.awesome.nfc@1.0::types
hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0::INfc
07ac2dc9...11e3cf57 vendor.awesome.nfc@1.0::INfc
hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0
9626fd18...f9d298a6 vendor.awesome.nfc@1.0::types
07ac2dc9...11e3cf57 vendor.awesome.nfc@1.0::INfc
f2fe5442...72655de6 vendor.awesome.nfc@1.0::INfcClientCallback
hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0 >> vendor/awesome/hardware/interfaces/current.txt
警告:请勿直接替换之前发布的接口的哈希。更改此类接口时,请向 current.txt
文件的末尾添加新的哈希。如需了解详情,请参阅 ABI 稳定性。
hidl-gen
生成的每个接口定义库都包含哈希,并可通过调用 IBase::getHashChain
进行检索。hidl-gen
编译接口时,会检查 HAL 软件包根目录中的 current.txt
文件,查看 HAL 是否已更改:
- 如果没有找到 HAL 的哈希,则接口会被视为未发布(处于开发阶段),并且编译会继续进行。
- 如果找到了相应哈希,则会对照当前接口对其进行检查:
- 如果接口与哈希匹配,则编译会继续进行。
- 如果接口与哈希不匹配,则编译会暂停,因为这意味着之前发布的接口会被更改。
- 如需在更改的同时不影响 ABI(请参阅 ABI 稳定性),必须先修改
current.txt
文件,编译才能继续进行。
- 其他所有更改都应在接口的次要或主要版本升级中进行。
ABI 稳定性
ABI 包括二进制文件关联/调用规范等信息。如果 ABI 或 API 发生更改,相应接口就不再适用于使用官方接口编译的常规 system.img
。
确保接口带有版本编号且 ABI 稳定至关重要,具体有如下几个原因:
- 可确保您的实现能够通过供应商测试套件 (VTS) 测试,通过该测试后您将能够正常进行仅限框架的 OTA。
- 作为原始设备制造商 (OEM),您将能够提供简单易用且符合规定的板级支持包 (BSP)。
- 有助于您跟踪哪些接口可以发布。您可以将
current.txt
视为接口目录的“地图”,从中了解软件包根目录中提供的所有接口的历史记录和状态。
对于在 current.txt
中已有条目的接口,为其添加新的哈希时,应确保添加的哈希能够反映出接口具有良好的 ABI 稳定性。请查看以下更改类型:
允许的更改 |
- 更改备注(除非这会更改方法的含义)。
- 更改参数的名称。
- 更改返回参数的名称。
- 更改注释。
|
不允许的更改 |
- 重新排列参数、方法等。
- 重命名接口或将其移至新的软件包。
- 重命名软件包。
- 在接口的任意位置添加方法/结构体字段等。
- 会破坏 C++ vtable 的任何更改。
- 等等
|
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Interface hashing\n\nThis document describes HIDL interface hashing, a mechanism to prevent\naccidental interface changes and ensure interface changes are thoroughly vetted.\nThis mechanism is required because HIDL interfaces are versioned, which means\nthat after an interface is released it must not be changed except in an\napplication binary interface (ABI) preserving manner (such as a comment\ncorrection).\n\nLayout\n------\n\nEvery package root directory (i.e. `android.hardware` mapping to\n`hardware/interfaces` or `vendor.foo` mapping to\n`vendor/foo/hardware/interfaces`) must contain a\n`current.txt` file that lists all released HIDL interface files. \n\n```objective-c\n# current.txt files support comments starting with a '#' character\n# this file, for instance, would be vendor/foo/hardware/interfaces/current.txt\n\n# Each line has a SHA-256 hash followed by the name of an interface.\n# They have been shortened in this doc for brevity but they are\n# 64 characters in length in an actual current.txt file.\nd4ed2f0e...995f9ec4 vendor.awesome.foo@1.0::IFoo # comments can also go here\n\n# types.hal files are also noted in current.txt files\nc84da9f5...f8ea2648 vendor.awesome.foo@1.0::types\n\n# Multiple hashes can be in the file for the same interface. This can be used\n# to note how ABI sustaining changes were made to the interface.\n# For instance, here is another hash for IFoo:\n\n# Fixes type where \"FooCallback\" was misspelled in comment on \"FooStruct\"\n822998d7...74d63b8c vendor.awesome.foo@1.0::IFoo\n```\n\n**Note:** To help keep track of which hashes come\nfrom where, Google separates HIDL `current.txt` files into different\nsections: The first section is *Released in Android 8* ; the next section\nwill be *Released in Android 8 MR1* . We strongly recommend using a\nsimilar layout in your `current.txt` file.\n\nHash with hidl-gen\n------------------\n\nYou can add a hash to a `current.txt` file manually or by\nusing `hidl-gen`. The following code snippet provides examples of\ncommands you can use with `hidl-gen` to manage a\n`current.txt` file (hashes have been shortened): \n\n hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0::types\n 9626fd18...f9d298a6 vendor.awesome.nfc@1.0::types\n hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0::INfc\n 07ac2dc9...11e3cf57 vendor.awesome.nfc@1.0::INfc\n hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0\n 9626fd18...f9d298a6 vendor.awesome.nfc@1.0::types\n 07ac2dc9...11e3cf57 vendor.awesome.nfc@1.0::INfc\n f2fe5442...72655de6 vendor.awesome.nfc@1.0::INfcClientCallback\n hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0 \u003e\u003e vendor/awesome/hardware/interfaces/current.txt\n\n**Warning:** Do not replace a hash for a\npreviously-released interface. When changing such an interface, add a new hash\nto the end of the `current.txt` file. For details, refer to\n[ABI stability](#abi-stability).\n\nEvery interface definition library generated by `hidl-gen`\nincludes hashes, which can be retrieved by calling\n`IBase::getHashChain`. When `hidl-gen` is compiling an\ninterface, it checks the `current.txt` file in the root directory of\nthe HAL package to see if the HAL has been changed:\n\n- If no hash for the HAL is found, the interface is considered unreleased (in development) and compilation proceeds.\n- If hashes are found, they are checked against the current interface:\n - If the interface does match the hash, compilation proceeds.\n - If the interface does not match a hash, compilation is halted as this means a previously-released interface is being changed.\n - For an ABI-preserving change (see [ABI stability](#abi-stability)), the `current.txt` file must be modified before compilation can proceed.\n - All other changes should be made in a minor or major version upgrade of the interface.\n\nABI stability\n-------------\n\n| **Key Point:** Please read and understand this section carefully.\n\nAn ABI includes the binary\nlinkages/calling conventions/etc. If the ABI or API changes, the interface no\nlonger works with a generic `system.img` that was compiled with\nofficial interfaces.\n\nMaking sure that interfaces are versioned and ABI stable is\n**crucial** for several reasons:\n\n- It ensures your implementation can pass the Vendor Test Suite (VTS), which puts you on track to being able to do framework-only OTAs.\n- As an OEM, it enables you to provide a Board Support Package (BSP) that is straightforward to use and compliant.\n- It helps you keep track of what interfaces can be released. Consider `current.txt` a map of an interfaces directory that allows you to see the history and state of all interfaces being provided in a package root.\n\nWhen adding a new hash for an interface that already has an entry in\n`current.txt`, make sure to add only the hashes that represent\ninterfaces which maintain ABI stability. Review the following types of changes:\n\n| Changes allowed | - Changing a comment (unless this changes the meaning of a method). - Changing the name of a parameter. - Changing the name of a return parameter. - Changing annotations. |\n| Changes not allowed | - Reordering arguments, methods, etc. - Renaming an interface or moving it to a new package. - Renaming a package. - Adding a method/struct field/etc. anywhere in the interface. - Anything that would break a C++ vtable. - etc. |\n|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|"]]