2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
AVB 속성의 버전 정보
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
KeyMint (이전 Keymaster) 버전 결합을 지원하려면 기기 부트로더가 각 파티션에 맞는 운영체제 (OS) 버전과 보안 패치 수준을 제공해야 합니다. 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 속성을 가져올 수 있습니다.
avb_slot_verify()로 여러 vbmeta 이미지를 로드할 수 있고 로드한 이미지는 AvbSlotVerifyData**
out_data 출력 매개변수에 저장됩니다.
Android 빌드 시스템이 사용하는 OS 버전과 보안 패치의 기본 형식은 각각 다음과 같습니다.
com.android.build.${partition}.os_version의 형식은 A[.B.C]입니다. 예를 들어 12 또는 12.0.0입니다.
- A: 메이저 버전
- B: 마이너 버전(없으면 0으로 설정됨)
- C: 하위 마이너 버전(없으면 0으로 설정됨)
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부터 각 기기 빌드는 기기 부트로더가 인식할 수 있는 OS 버전의 맞춤 값을 가질 수 있습니다.
예를 들면 다음과 같습니다.
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 4의 버전 결합을 사용할 때 boot.img 헤더에서 os_version을 삭제하는 것이 좋습니다.
여기에서는 비교해 볼 수 있도록 더 이상 사용하지 않는 부팅 이미지 헤더의 버전 정보 사용법도 설명합니다. 부팅 헤더의 os_version 필드는 OS 버전과 보안 패치 수준을 모두 부호 없는 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;
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],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;"]]
