اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release
بدلاً من aosp-main
لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
معلومات الإصدار في سمات AVB
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
لإتاحة ربط الإصدار في KeyMint (المعروفة سابقًا باسم Keymaster)،
من المفترض أن يوفّر برنامج الإقلاع لنظام التشغيل إصدار نظام التشغيل
ومستوى رمز تصحيح الأمان لكل قسم. إصدار نظام التشغيل ومستوى رمز تصحيح الأمان هما زوجان منفصلان من القيم الرئيسية في خصائص 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()
.
يمكن تحميل صور vbmeta متعددة باستخدام
avb_slot_verify()
ويتم تخزينها في
AvbSlotVerifyData**
out_data
معلَمة الإخراج.
يستخدم نظام إنشاء Android تلقائيًا التنسيق التالي لإصدار نظام التشغيل وحزمة الأمان على التوالي.
يكون تنسيق com.android.build.${partition}.os_version
هو A[.B.C]،
على سبيل المثال، 12
أو 12.0.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، يمكن أن يتضمّن كل إصدار من الجهاز قيمة مخصّصة لإصدار نظام التشغيل يمكن أن يتعرّف عليها برنامج إقلاع الجهاز.
مثلاً:
- تُنشئ
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'
في الإصدار 9 من نظام التشغيل Android والإصدارات الأحدث، تقترح ميزة ربط الإصدار في 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 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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;"]]