ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
ข้อมูลเวอร์ชันในพร็อพเพอร์ตี้ AVB
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
เพื่อรองรับการเชื่อมโยงเวอร์ชัน KeyMint (เดิมคือ Keymaster)
คาดว่า Bootloader ของอุปกรณ์จะระบุเวอร์ชันของระบบปฏิบัติการ (OS)
และระดับแพตช์ด้านความปลอดภัยสำหรับแต่ละพาร์ติชัน เวอร์ชันของระบบปฏิบัติการและระดับแพตช์ความปลอดภัยเป็นคู่คีย์-ค่า 2 คู่ที่แยกกันในพร็อพเพอร์ตี้ 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 เหล่านั้นจากอิมเมจ vbmeta ได้โดยใช้
avb_property_lookup()
avb_slot_verify()
สามารถโหลดรูปภาพ vbmeta หลายรูปได้
และจัดเก็บไว้ในพารามิเตอร์เอาต์พุต
AvbSlotVerifyData**
out_data
โดยค่าเริ่มต้น ระบบบิลด์ Android จะใช้รูปแบบต่อไปนี้สำหรับเวอร์ชันของระบบปฏิบัติการและแพตช์ความปลอดภัยตามลำดับ
รูปแบบของ 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
โดยค่าเริ่มต้น ระบบบิลด์จะสร้าง
com.android.build.${partition}.security_patch สำหรับพาร์ติชัน system
system_ext และ product ผู้ผลิตอุปกรณ์ควรตั้งค่า 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 เป็นต้นไป บิลด์ของอุปกรณ์แต่ละรายการจะมี
ค่าที่กำหนดเองสำหรับเวอร์ชันของระบบปฏิบัติการที่ Bootloader ของอุปกรณ์รู้จัก
เช่น
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
แนะนำให้นำ os_version ออกจากส่วนหัว boot.img
นอกจากนี้ เรายังอธิบายการใช้งานที่ล้าสมัยในการรับข้อมูลเวอร์ชันจากส่วนหัวของอิมเมจการบูตเพื่อใช้เปรียบเทียบด้วย โปรดทราบว่าฟิลด์
os_version
ในส่วนหัวของการบูตจะรวมทั้งเวอร์ชันของระบบปฏิบัติการและระดับแพตช์ความปลอดภัยไว้ใน
จำนวนเต็มแบบไม่มีเครื่องหมาย 32 บิต และกลไกนี้ถือว่ารูปภาพทั้งหมดจะได้รับการอัปเดตพร้อมกัน ซึ่งไม่เกี่ยวข้องอีกต่อไปหลังจากการแยกส่วนในProject 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 และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 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;"]]
