اطلاعات نسخه در ویژگی های AVB

برای پشتیبانی نسخه 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)

مشخص کردن اطلاعات نسخه سفارشی

با شروع از Android 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;