برای پشتیبانی نسخه Keymaster binding ، انتظار می رود بوت لودر دستگاه نسخه سیستم عامل (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 را از یک تصویر vbmeta با استفاده از avb_property_lookup()
دریافت کند. چندین تصویر vbmeta را می توان توسط avb_slot_verify()
بارگذاری کرد و در پارامتر خروجی AvbSlotVerifyData**
out_data
ذخیره می شود.
فرمت پیش فرض اطلاعات نسخه
به طور پیش فرض، سیستم ساخت اندروید از فرمت زیر به ترتیب برای نسخه سیستم عامل و وصله امنیتی استفاده می کند.
قالب com.android.build.${partition}.os_version
A[.BC] است، به عنوان مثال، 12
یا 12.0.0
:
- A: نسخه اصلی
- ب: نسخه جزئی، در صورت عدم وجود آن به صورت پیش فرض صفر می شود
- ج: نسخه فرعی، در صورت وجود نداشتن، به طور پیش فرض صفر می شود
قالب 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)
اطلاعات نسخه سفارشی را مشخص کنید
با شروع اندروید 13، هر ساخت دستگاه می تواند یک مقدار سفارشی برای نسخه سیستم عامل داشته باشد که توسط بوت لودر دستگاه قابل تشخیص است. به عنوان مثال:
-
SYSTEM_OS_VERSION := 12.0.0
ایجاد می کند-
com.android.build.system.os_version -> '12.0.0'
-
-
BOOT_OS_VERSION := abc
تولید می کند-
com.android.build.boot.os_version -> 'abc'
-
-
VENDOR_OS_VERSION := 12.0.1
ایجاد می کند-
com.android.build.vendor.os_version -> '12.0.1'
-
اطلاعات نسخه منسوخ در هدر تصویر بوت
با شروع از Android 9، نسخه Keymaster binding پیشنهاد می کند 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;