自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
AVB 属性中的版本信息
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
为支持 Keymaster 版本绑定,设备引导加载程序应提供每个分区的操作系统 (OS) 版本和安全补丁级别。操作系统版本和安全补丁级别是 AVB 属性中的两个单独的键值对。例如:
com.android.build.system.os_version -> '12'
com.android.build.system.security_patch -> '2022-02-05'
com.android.build.vendor.os_version -> '12'
com.android.build.vendor.security_patch -> '2022-02-05'
com.android.build.boot.os_version -> '12'
com.android.build.boot.security_patch -> '2022-02-05'
设备引导加载程序可以使用 avb_property_lookup()
从 vbmeta 映像获取这些 AVB 属性。多个 vbmeta 映像可以通过 avb_slot_verify()
加载,并且会存储在 AvbSlotVerifyData**
out_data
输出参数中。
默认情况下,Android 构建系统会分别为操作系统版本和安全补丁使用以下格式。
com.android.build.${partition}.os_version
的格式为 A[.B.C],例如 12
或 12.0.0
:
- A:主要版本
- B:次要版本,不存在时默认为零
- C:子次要版本,不存在时默认为零
com.android.build.${partition}.security_patch
的格式为 YYYY-MM-DD。
默认情况下,构建系统会为 system
、system_ext
和 product
分区生成 com.android.build.${partition}.security_patch
。设备制造商应为非系统分区设置 BOOT_SECURITY_PATCH
、VENDOR_SECURITY_PATCH
和其他补丁。例如:
BOOT_SECURITY_PATCH := 2022-01-05
生成
com.android.build.boot.security_patch -> '2022-01-05'
VENDOR_SECURITY_PATCH := 2022-02-05
生成
com.android.build.vendor.security_patch -> '2022-02-05'
如果设备制造商始终将所有分区更新为具有相同安全补丁级别的版本,可将 *_SECURITY_PATCH
设置为 $(PLATFORM_SECURITY_PATCH)
。
BOOT_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)
VENDOR_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)
从 Android 13 开始,每个设备 build 都可以有一个设备引导加载程序可识别的自定义操作系统版本值。例如:
SYSTEM_OS_VERSION := 12.0.0
生成
com.android.build.system.os_version -> '12.0.0'
BOOT_OS_VERSION := a.b.c
生成
com.android.build.boot.os_version -> 'a.b.c'
VENDOR_OS_VERSION := 12.0.1
生成
com.android.build.vendor.os_version -> '12.0.1'
从 Android 9 开始,Keymaster 版本绑定建议从 boot.img
头文件中移除 os_version
。
作为对比,这里也介绍了从启动映像头文件中获取版本信息的过时用法。请注意,启动头文件中的 os_version
字段将操作系统版本和安全补丁级别合并成了一个 32 位无符号整数。此机制假定所有映像都将一起更新,而在 Treble 计划中分区模块化后,此假定已过时。
// Operating system version and security patch level.
// For version "A.B.C" and patch level "Y-M-D":
// (7 bits for each of A, B, C; 7 bits for (Y-2000), 4 bits for M)
// A = os_version[31:25]
// B = os_version[24:18]
// C = os_version[17:11]
// Y = 2000 + os_version[10:4]
// M = os-version[3:0]
uint32_t os_version;
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-04-04。
[null,null,["最后更新时间 (UTC):2025-04-04。"],[],[],null,["# Version information in AVB properties\n\nTo support KeyMint (previously Keymaster) [version\nbinding](/docs/security/features/keystore/version-binding),\nthe device bootloader is expected to provide the operating system (OS) version\nand the security patch level for each partition. The OS version and the security\npatch level are two separate key-value pairs in the [AVB\nproperties](https://android.googlesource.com/platform/external/avb/+/refs/heads/android16-release/libavb/avb_property_descriptor.h).\nFor example:\n\n- `com.android.build.system.os_version -\u003e '12'`\n- `com.android.build.system.security_patch -\u003e '2022-02-05'`\n- `com.android.build.vendor.os_version -\u003e '12'`\n- `com.android.build.vendor.security_patch -\u003e '2022-02-05'`\n- `com.android.build.boot.os_version -\u003e '12'`\n- `com.android.build.boot.security_patch -\u003e '2022-02-05'`\n\nThe device bootloader can get those AVB properties from a vbmeta image using\n[`avb_property_lookup()`](https://cs.android.com/android/platform/superproject/+/android-latest-release:external/avb/libavb/avb_property_descriptor.h;l=83;drc=fbd9f0de0a21605d09d2c1388f0cab947f7e920e).\nMultiple vbmeta images can be loaded by\n[`avb_slot_verify()`](https://cs.android.com/android/platform/superproject/+/android-latest-release:external/avb/libavb/avb_slot_verify.c;l=1366;drc=c0debbfd55f08a755b006550779c23e707d30b6d)\nand are stored in the\n[`AvbSlotVerifyData**`](https://cs.android.com/android/platform/superproject/+/android-latest-release:external/avb/libavb/avb_slot_verify.h;l=308;drc=7043326a1c206b7abb627b4d8c7a47f3acd4aa46)\n[`out_data`](https://cs.android.com/android/platform/superproject/+/android-latest-release:external/avb/libavb/avb_slot_verify.c;l=1371;drc=c0debbfd55f08a755b006550779c23e707d30b6d)\noutput parameter.\n\nThe default format of the version information\n---------------------------------------------\n\nBy default, the Android build system uses the following format for the OS\nversion and the security patch, respectively.\n\nThe format of `com.android.build.${partition}.os_version` is A\\[.B.C\\],\nfor example, `12` or `12.0.0`:\n\n- A: major version\n- B: minor version, defaults to zero when it is absent\n- C: sub-minor version, defaults to zero when it is absent\n\nThe format of `com.android.build.${partition}.security_patch` is YYYY-MM-DD.\n\nBy default the build system generates\n`com.android.build.${partition}.security_patch` for the `system`,\n`system_ext`, and `product` partitions. The device manufacturer is\nexpected to set `BOOT_SECURITY_PATCH`, `VENDOR_SECURITY_PATCH`, and other\npatches, for nonsystem partitions. For example:\n\n- `BOOT_SECURITY_PATCH := 2022-01-05` generates\n - `com.android.build.boot.security_patch -\u003e '2022-01-05'`\n- `VENDOR_SECURITY_PATCH := 2022-02-05` generates\n - `com.android.build.vendor.security_patch -\u003e '2022-02-05'`\n\nThe device manufacturer can set `*_SECURITY_PATCH` to\n`$(PLATFORM_SECURITY_PATCH)`\nif it always updates all partitions to the version with the same security\npatch level.\n\n- `BOOT_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)`\n- `VENDOR_SECURITY_PATCH := $(PLATFORM_SECURITY_PATCH)`\n\nSpecify custom version information\n----------------------------------\n\nStarting in Android 13, each device build can have a\ncustom value for the OS version that can be recognized by the device bootloader.\nFor example:\n\n- `SYSTEM_OS_VERSION := 12.0.0` generates\n - `com.android.build.system.os_version -\u003e '12.0.0'`\n- `BOOT_OS_VERSION := a.b.c` generates\n - `com.android.build.boot.os_version -\u003e 'a.b.c'`\n- `VENDOR_OS_VERSION := 12.0.1` generates\n - `com.android.build.vendor.os_version -\u003e '12.0.1'`\n\nThe obsolete version information in the boot image header\n---------------------------------------------------------\n\nIn Android 9 and higher, Keymaster 4's\n[version binding](/docs/security/features/keystore/version-binding)\nsuggests removing `os_version` from the `boot.img` header.\n\nFor comparison, the obsolete usage of obtaining the version information from the\nboot image header is also described here. Note that the\n[`os_version`](https://cs.android.com/android/kernel/superproject/+/common-android-mainline:tools/mkbootimg/include/bootimg/bootimg.h;l=257;drc=b4b04c2a965d9b3ce1ebf0442fc8047fe103d4e6)\nfield in the boot header combines both OS version and security patch level into\na 32-bit unsigned integer. And this mechanism assumes that all images will be\nupdated together, which is obsolete after partition modularization in\n[Project Treble](https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html). \n\n // Operating system version and security patch level.\n // For version \"A.B.C\" and patch level \"Y-M-D\":\n // (7 bits for each of A, B, C; 7 bits for (Y-2000), 4 bits for M)\n // A = os_version[31:25]\n // B = os_version[24:18]\n // C = os_version[17:11]\n // Y = 2000 + os_version[10:4]\n // M = os-version[3:0]\n\n uint32_t os_version;"]]