پارتیشن بوت عمومی

در اندروید 12، تصویر boot عمومی، که به عنوان تصویر هسته عمومی (GKI) شناخته می‌شود، حاوی ramdisk عمومی و هسته GKI است.

برای دستگاه‌هایی که با Android 13 راه‌اندازی می‌شوند، ramdisk عمومی از تصویر boot حذف می‌شود و در یک تصویر init_boot جداگانه قرار می‌گیرد. با این تغییر، تصویر boot تنها با هسته GKI باقی می ماند.

برای ارتقای دستگاه‌هایی که همچنان از اندروید 12 یا نسخه‌های هسته قدیمی‌تر استفاده می‌کنند، ramdisk عمومی در جایی که بود بدون نیاز به تصویر init_boot جدید باقی می‌ماند.

برای ساختن یک ramdisk عمومی، منابع خاص فروشنده را از ramdisk خارج کنید به طوری که ramdisk عمومی فقط شامل مرحله اول init و یک فایل ویژگی است که حاوی اطلاعات timestamp است.

در دستگاه هایی که:

  • از پارتیشن recovery اختصاصی استفاده نکنید، همه بیت های بازیابی از ramdisk عمومی به vendor_boot ramdisk منتقل می شوند.

  • از یک پارتیشن recovery اختصاصی استفاده کنید، هیچ تغییری در ramdisk recovery لازم نیست زیرا ramdisk recovery مستقل است.

معماری

نمودارهای زیر معماری دستگاه های دارای اندروید 12 و بالاتر را نشان می دهد. دستگاهی که با Android 13 راه اندازی می شود، یک تصویر init_boot جدید حاوی ramdisk عمومی دارد. دستگاه هایی که از اندروید 12 به اندروید 13 ارتقا می یابند از همان معماری استفاده می کنند که در اندروید 12 استفاده می کردند.

راه اندازی با اندروید 13، بدون بازیابی اختصاصی

راه اندازی/ارتقا دستگاه، GKI، بدون بازیابی اختصاصی

شکل 1. دستگاه هایی که به اندروید 13 راه اندازی یا ارتقا می یابند، با GKI، بدون بازیابی اختصاصی.

راه اندازی با اندروید 13، ریکاوری اختصاصی و A/B (رمدیسک اختصاصی)

راه اندازی/ارتقا دستگاه، GKI، اختصاصی و بازیابی A/B

شکل 2. دستگاه هایی که به اندروید 13 راه اندازی یا ارتقا می یابند، با GKI، اختصاصی و بازیابی A/B.

اگر دستگاه دارای پارتیشن های recovery_a و recovery_b است به این شکل مراجعه کنید.

راه اندازی با اندروید 13، بازیابی اختصاصی و غیر A/B (رمدیسک اختصاصی)

راه اندازی/ارتقا دستگاه، GKI، بازیابی اختصاصی و غیر A/B

شکل 3. دستگاه هایی که به اندروید 13 راه اندازی یا ارتقا می یابند، با GKI، بازیابی اختصاصی و غیر A/B.

اگر دستگاه دارای پارتیشنی به نام recovery بدون پسوند اسلات است به این شکل مراجعه کنید.

راه اندازی یا ارتقا به اندروید 12، بدون بازیابی اختصاصی

راه اندازی/ارتقا دستگاه، GKI، بدون بازیابی اختصاصی

شکل 4. دستگاه هایی که به اندروید 12 راه اندازی یا ارتقا می یابند، با GKI، بدون بازیابی اختصاصی.

راه اندازی یا ارتقا به اندروید 12، بازیابی اختصاصی و A/B (رمدیسک اختصاصی)

راه اندازی/ارتقا دستگاه، GKI، اختصاصی و بازیابی A/B

شکل 5. دستگاه هایی که به اندروید 12 راه اندازی یا ارتقا می یابند، با GKI، اختصاصی و بازیابی A/B.

اگر دستگاه دارای پارتیشن های recovery_a و recovery_b است به این شکل مراجعه کنید.

راه اندازی یا ارتقا به اندروید 12، بازیابی اختصاصی و غیر A/B (رمدیسک اختصاصی)

راه اندازی/ارتقا دستگاه، GKI، بازیابی اختصاصی و غیر A/B

شکل 6. دستگاه هایی که به اندروید 12 راه اندازی یا ارتقا می یابند، با GKI، بازیابی اختصاصی و غیر A/B.

اگر دستگاه دارای پارتیشنی به نام recovery بدون پسوند اسلات است به این شکل مراجعه کنید.

ارتقا به اندروید 12، بازیابی به عنوان بوت (بازیابی به عنوان ramdisk)

راه‌اندازی/ارتقا دستگاه، بدون GKI، بازیابی به‌عنوان بوت

شکل 7. دستگاه‌هایی که به اندروید 12 ارتقا می‌یابند، بدون GKI، بازیابی به‌عنوان بوت.

ارتقا به اندروید 12، ریکاوری اختصاصی (رمدیسک اختصاصی)

راه اندازی/ارتقا دستگاه، بدون GKI، بازیابی اختصاصی

شکل 8. دستگاه هایی که به اندروید 12 ارتقا می یابند، بدون GKI، بازیابی اختصاصی.

محتویات تصاویر را بوت کنید

تصاویر بوت اندروید شامل موارد زیر است.

  • تصویر init_boot برای دستگاه هایی که با Android 13 راه اندازی می شوند اضافه شد

    • نسخه هدر V4
    • تصویر ramdisk عمومی

  • تصویر boot عمومی

    • نسخه هدر V3 یا V4
      • یک boot_signature برای گواهی GKI boot.img (فقط نسخه 4). گواهی GKI boot.img برای بوت تایید شده امضا نشده است. OEM ها همچنان باید boot.img از پیش ساخته شده را با یک کلید AVB مخصوص دستگاه امضا کنند.
      • cmdline عمومی ( GENERIC_KERNEL_CMDLINE )
      • هسته GKI
    • تصویر ramdisk عمومی
      • فقط در تصاویر boot از اندروید 12 و نسخه های قبلی گنجانده شده است

  • تصویر vendor_boot (برای جزئیات، به پارتیشن‌های بوت فروشنده مراجعه کنید)

    • هدر vendor_boot
      • cmdline ویژه دستگاه ( BOARD_KERNEL_CMDLINE )
    • vendor_boot تصویر ramdisk
      • lib/modules
      • منابع بازیابی (در صورت عدم وجود بازیابی اختصاصی)
    • تصویر dtb

  • تصویر recovery

    • نسخه هدر V2
      • cmdline مخصوص دستگاه برای بازیابی، در صورت لزوم
      • برای پارتیشن بازیابی غیر A/B، محتویات هدر باید مستقل باشد. به تصاویر بازیابی مراجعه کنید. به عنوان مثال:
      • cmdline به boot و vendor_boot cmdline متصل نیست.
      • هدر DTBO بازیابی را در صورت لزوم مشخص می کند.
      • برای پارتیشن بازیابی A/B، محتویات را می توان از boot و vendor_boot به هم پیوست یا استنباط کرد. به عنوان مثال:
      • cmdline به boot و vendor_boot cmdline متصل است.
      • DTBO را می توان از هدر vendor_boot استنباط کرد.
    • تصویر رام دیسک recovery
      • منابع بازیابی
      • برای پارتیشن بازیابی غیر A/B، محتویات ramdisk باید مستقل باشد. به تصاویر بازیابی مراجعه کنید. به عنوان مثال:
      • lib/modules باید شامل تمام ماژول های هسته مورد نیاز برای بوت شدن حالت بازیابی باشد
      • ramdisk بازیابی باید حاوی init باشد.
      • برای پارتیشن بازیابی A/B، ramdisk بازیابی به ramdisk generic و vendor_boot اضافه شده است، بنابراین نیازی به مستقل بودن آن نیست. به عنوان مثال:
      • lib/modules ممکن است علاوه بر ماژول‌های هسته در vendor_boot ramdisk فقط شامل ماژول‌های هسته اضافی مورد نیاز برای راه‌اندازی حالت بازیابی باشد.
      • ممکن است پیوند نمادین در /init وجود داشته باشد، اما توسط باینری /init مرحله اول در تصویر راه‌اندازی تحت الشعاع قرار می‌گیرد.

محتویات تصویر ramdisk عمومی

ramdisk عمومی شامل اجزای زیر است.

  • init
  • system/etc/ramdisk/build.prop
  • ro. PRODUCT .bootimg.* build لوازم
  • دایرکتوری های خالی برای نقاط اتصال: debug_ramdisk/ ، mnt/ ، dev/ ، sys/ ، proc/ ، metadata/
  • first_stage_ramdisk/
    • دایرکتوری های خالی تکراری برای نقاط اتصال: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/

ادغام تصویر بوت

پرچم‌های ساخت نحوه ساخت تصاویر init_boot ، boot ، recovery و vendor_boot را کنترل می‌کنند. مقدار متغیر برد بولی باید رشته true یا خالی باشد (که پیش‌فرض است).

  • TARGET_NO_KERNEL . این متغیر نشان می دهد که آیا بیلد از یک تصویر بوت از پیش ساخته شده استفاده می کند. اگر این متغیر روی true تنظیم شده است، سپس BOARD_PREBUILT_BOOTIMAGE در محل تصویر بوت از پیش ساخته شده قرار دهید ( BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img )

  • BOARD_USES_RECOVERY_AS_BOOT . این متغیر نشان می دهد که آیا دستگاه از تصویر recovery به عنوان تصویر boot استفاده می کند یا خیر. هنگام استفاده از GKI، این متغیر خالی است و منابع بازیابی باید به vendor_boot منتقل شوند.

  • BOARD_USES_GENERIC_KERNEL_IMAGE . این متغیر نشان می دهد که برد از GKI استفاده می کند. این متغیر روی sysprops یا PRODUCT_PACKAGES تأثیر نمی گذارد.

    این سوئیچ GKI در سطح برد است. همه متغیرهای زیر توسط این متغیر محدود می شوند.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT . این متغیر کنترل می کند که آیا منابع بازیابی ramdisk برای vendor_boot ساخته شده است یا خیر.

    • وقتی روی true تنظیم شود، منابع بازیابی فقط برای vendor-ramdisk/ ساخته می شوند و برای recovery/root/ ساخته نمی شوند.

    • وقتی خالی است، منابع بازیابی فقط برای recovery/root/ ساخته می شوند و برای vendor-ramdisk/ ساخته نمی شوند.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT . این متغیر کنترل می کند که آیا کلیدهای GSI AVB برای vendor_boot ساخته شده اند یا خیر.

    • وقتی روی true تنظیم شود، اگر BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

      • تنظیم شده است، کلیدهای GSI AVB روی $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb ساخته شده‌اند.

      • تنظیم نشده است، کلیدهای GSI AVB روی $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb ساخته شده‌اند.

    • وقتی خالی است، اگر BOARD_RECOVERY_AS_ROOT :

      • تنظیم شده است، کلیدهای GSI AVB روی $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb ساخته شده‌اند.

      • تنظیم نشده است، کلیدهای GSI AVB روی $ANDROID_PRODUCT_OUT/ramdisk/avb ساخته شده‌اند.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE . این متغیر کنترل می کند که آیا تصویر recovery دارای هسته است یا نه. دستگاه‌هایی که با Android 12 راه‌اندازی می‌شوند و از پارتیشن recovery A/B استفاده می‌کنند باید این متغیر را روی true تنظیم کنند. دستگاه‌هایی که با Android 12 راه‌اندازی می‌شوند و از غیر A/B استفاده می‌کنند باید این متغیر را روی false تنظیم کنند تا تصویر بازیابی مستقل بماند.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES . این متغیر کنترل می‌کند که $OUT/boot*.img در زیر فایل‌های هدف در IMAGES/ کپی شود یا خیر.

    • aosp_arm64 باید این متغیر را روی true تنظیم کند.

    • دستگاه های دیگر باید این متغیر را خالی بگذارند.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE . این متغیر کنترل می کند که آیا init_boot.img تولید می شود و اندازه را تعیین می کند. پس از تنظیم، ramdisk عمومی به جای boot.img به init_boot.img اضافه می‌شود و باید متغیرهای BOARD_AVB_INIT_BOOT* برای vbmeta زنجیره‌ای تنظیم شوند.

ترکیبات مجاز

جزء یا متغیر دستگاه را بدون پارتیشن بازیابی ارتقا دهید دستگاه را با پارتیشن بازیابی ارتقا دهید راه اندازی دستگاه بدون پارتیشن بازیابی دستگاه را با پارتیشن بازیابی A/B راه اندازی کنید دستگاه را با پارتیشن بازیابی غیر A/B راه اندازی کنید aosp_arm64
حاوی boot بله بله بله بله بله بله
حاوی init_boot (اندروید 13) نه نه بله بله بله بله
حاوی vendor_boot است اختیاری اختیاری بله بله بله نه
شامل recovery است نه بله نه بله بله نه
BOARD_USES_RECOVERY_AS_BOOT true خالی خالی خالی خالی خالی
BOARD_USES_GENERIC_KERNEL_IMAGE خالی خالی true true true true
PRODUCT_BUILD_RECOVERY_IMAGE خالی true یا خالی خالی true یا خالی true یا خالی خالی
BOARD_RECOVERYIMAGE_PARTITION_SIZE خالی > 0 خالی > 0 > 0 خالی
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT خالی خالی true خالی خالی خالی
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT خالی خالی true true true خالی
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE خالی خالی خالی true خالی خالی
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES خالی خالی خالی خالی خالی true

دستگاه‌های دارای پارتیشن recovery اختصاصی می‌توانند PRODUCT_BUILD_RECOVERY_IMAGE روی true یا خالی تنظیم کنند. برای این دستگاه‌ها، اگر BOARD_RECOVERYIMAGE_PARTITION_SIZE تنظیم شده باشد، یک تصویر recovery ساخته می‌شود.

vbmeta زنجیره ای را برای بوت فعال کنید

vbmeta زنجیره ای باید برای تصاویر boot و init_boot فعال باشد. موارد زیر را مشخص کنید:

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

برای مثال به این تغییر مراجعه کنید.

سیستم به عنوان ریشه

System-as-root برای دستگاه هایی که از GKI استفاده می کنند پشتیبانی نمی شود. در چنین دستگاه‌هایی، BOARD_BUILD_SYSTEM_ROOT_IMAGE باید خالی باشد. System-as-root همچنین برای دستگاه هایی که از پارتیشن های پویا استفاده می کنند پشتیبانی نمی شود.

تنظیمات محصول

دستگاه‌هایی که از ramdisk عمومی استفاده می‌کنند باید فهرستی از فایل‌هایی را که مجاز به نصب در ramdisk هستند نصب کنند. برای این کار موارد زیر را در device.mk مشخص کنید:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

فایل generic_ramdisk.mk همچنین از نصب تصادفی فایل‌های دیگر در ramdisk توسط سایر فایل‌های make-فایل جلوگیری می‌کند (به جای آن چنین فایل‌هایی را به vendor_ramdisk منتقل کنید).

دستگاه ها را راه اندازی کنید

دستورالعمل‌های راه‌اندازی بین دستگاه‌هایی که با Android 13 راه‌اندازی می‌شوند، به‌روزرسانی به Android 12 و راه‌اندازی با Android 12 متفاوت است. Android 13، مانند آنچه در Android 12 بود، تنظیم شده است.

  • ارتقاء دستگاه ها به اندروید 12:

    • می تواند ارزش BOARD_USES_RECOVERY_AS_BOOT را حفظ کند. اگر این کار را انجام دهند، از پیکربندی های قدیمی استفاده می کنند و متغیرهای ساخت جدید باید خالی باشند. اگر چنین وسایلی:

      • BOARD_USES_RECOVERY_AS_BOOT روی true تنظیم کنید، معماری مانند شکل 3 است.

      • BOARD_USES_RECOVERY_AS_BOOT روی خالی تنظیم کنید، معماری مانند شکل 4 است.

    • می‌تواند BOARD_USES_RECOVERY_AS_BOOT را روی خالی تنظیم کند. اگر این کار را انجام دهند، از تنظیمات جدید استفاده می کنند. اگر چنین وسایلی:

      • از پارتیشن recovery اختصاصی استفاده نکنید، معماری مطابق شکل 1 است و گزینه تنظیم دستگاه گزینه 1 است.

      • از یک پارتیشن recovery اختصاصی استفاده کنید، معماری همانطور که در شکل 2a یا شکل 2b نشان داده شده است و گزینه تنظیم دستگاه گزینه 2a یا گزینه 2b است.

  • دستگاه‌هایی که با Android 12 راه‌اندازی می‌شوند باید BOARD_USES_RECOVERY_AS_BOOT برای خالی کردن و استفاده از پیکربندی‌های جدید تنظیم کنند. اگر چنین وسایلی:

    • از پارتیشن recovery اختصاصی استفاده نکنید، معماری مطابق شکل 1 است و گزینه تنظیم دستگاه گزینه 1 است.

    • از یک پارتیشن recovery اختصاصی استفاده کنید، معماری همانطور که در شکل 2a یا شکل 2b نشان داده شده است و گزینه تنظیم دستگاه گزینه 2a یا گزینه 2b است.

از آنجا که aosp_arm64 فقط GKI (و نه vendor_boot یا بازیابی) را می سازد، یک هدف کامل نیست. برای تنظیمات ساخت aosp_arm64 ، به generic_arm64 مراجعه کنید.

گزینه 1: پارتیشن بازیابی اختصاصی وجود ندارد

دستگاه‌های بدون پارتیشن recovery حاوی تصویر boot عمومی در پارتیشن boot هستند. ramdisk vendor_boot شامل تمام منابع بازیابی، از جمله lib/modules (با ماژول‌های هسته فروشنده) است. در چنین دستگاه‌هایی، پیکربندی محصول از generic_ramdisk.mk به ارث می‌رسد .

مقادیر BOARD را تنظیم کنید

مقادیر زیر را تنظیم کنید:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

ramdisk vendor_boot می‌تواند حاوی /init به /system/bin/init و init_second_stage.recovery در /system/bin/init . با این حال، از آنجایی که ramdisk عمومی بعد از ramdisk vendor_boot به هم پیوسته است، سیم پیوند /init بازنویسی می شود. هنگامی که دستگاه در مرحله بازیابی بوت می شود، باینری /system/bin/init برای پشتیبانی از مرحله دوم init مورد نیاز است. محتویات vendor_boot + ramdisks عمومی به شرح زیر است:

  • /init (از ramdisk عمومی، ساخته شده از init_first_stage )
  • /system/bin/init (از vendor_ramdisk ، ساخته شده از init_second_stage.recovery )

انتقال فایل های fstab

هر فایل fstab را که به ramdisk عمومی نصب شده است به vendor_ramdisk منتقل کنید. برای مثال به این تغییر مراجعه کنید.

ماژول ها را نصب کنید

می‌توانید ماژول‌های مخصوص دستگاه را در vendor_ramdisk نصب کنید (اگر ماژول‌های مخصوص دستگاه برای نصب ندارید، از این مرحله بگذرید).

  • هنگامی که ماژول در /first_stage_ramdisk نصب می شود، از نوع vendor_ramdisk ماژول استفاده کنید. این ماژول باید بعد از اینکه init روت را به /first_stage_ramdisk سوئیچ کند اما قبل از اینکه init root را به /system تغییر دهد در دسترس باشد. برای مثال، جمع‌های چک فراداده و فشرده‌سازی A/B مجازی را ببینید.

  • هنگام نصب ماژول در / از نوع recovery ماژول استفاده کنید. این ماژول باید قبل از اینکه init root را به /first_stage_ramdisk سوئیچ کند در دسترس باشد. برای جزئیات بیشتر در مورد نصب ماژول ها در / به کنسول مرحله اول مراجعه کنید.

کنسول مرحله اول

از آنجا که کنسول مرحله اول قبل از اینکه init روت را به /first_stage_ramdisk سوئیچ کند شروع می شود، باید نوع recovery ماژول ها را نصب کنید. به طور پیش‌فرض، هر دو نوع ماژول برای build/make/target/product/base_vendor.mk نصب می‌شوند، بنابراین اگر فایل ساخت دستگاه از آن فایل به ارث می‌رسد، نیازی به نصب صریح نوع recovery ندارید.

برای نصب صریح ماژول های بازیابی، از موارد زیر استفاده کنید.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

این تضمین می‌کند که linker ، sh و toybox در $ANDROID_PRODUCT_OUT/recovery/root/system/bin نصب می‌شوند، که سپس در /system/bin زیر vendor_ramdisk نصب می‌شود.

برای افزودن ماژول های مورد نیاز برای کنسول مرحله اول (مثلاً adbd)، از موارد زیر استفاده کنید.

PRODUCT_PACKAGES += adbd.recovery

این تضمین می‌کند که ماژول‌های مشخص‌شده در $ANDROID_PRODUCT_OUT/recovery/root/system/bin نصب می‌شوند، که سپس در /system/bin زیر vendor_ramdisk نصب می‌شود.

جمع های چک فراداده

برای پشتیبانی از جمع‌های چک فراداده در مرحله اول نصب، دستگاه‌هایی که از GKI پشتیبانی نمی‌کنند، نوع ramdisk ماژول‌های زیر را نصب می‌کنند. برای افزودن پشتیبانی از GKI، ماژول ها را به $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin منتقل کنید:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

برای مثال، به این فهرست تغییر مراجعه کنید.

فشرده سازی مجازی A/B

برای پشتیبانی از فشرده سازی مجازی A/B، snapuserd باید در vendor_ramdisk نصب شود. دستگاه باید از virtual_ab_ota/compression.mk که نوع vendor_ramdisk snapuserd را نصب می‌کند به ارث برده شود.

تغییرات در فرآیند بوت

روند بوت شدن در بازیابی یا اندروید تغییری نمی کند، به استثنای زیر:

  • Ramdisk build.prop به /second_stage_resources منتقل می‌شود تا init مرحله دوم بتواند مهر زمانی ساخت بوت را بخواند.

از آنجایی که منابع از ramdisk عمومی به ramdisk vendor_boot منتقل می شوند، نتیجه الحاق ramdisk عمومی به ramdisk vendor_boot تغییر نمی کند.

e2fsck را در دسترس قرار دهید

فایل‌های ساخت دستگاه می‌توانند از موارد زیر به ارث ببرند:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk اگر دستگاه از A/B مجازی پشتیبانی می کند اما از فشرده سازی پشتیبانی نمی کند.

  • virtual_ab_ota/compression.mk اگر دستگاه از فشرده سازی مجازی A/B پشتیبانی می کند.

فایل‌های ساخت محصول $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck را نصب می‌کنند. در زمان اجرا، مرحله اول init root را به /first_stage_ramdisk تغییر می دهد و سپس /system/bin/e2fsck اجرا می کند.

گزینه 2a: پارتیشن بازیابی اختصاصی و A/B

از این گزینه برای دستگاه هایی با پارتیشن های recovery A/B استفاده کنید. یعنی دستگاه دارای یک recovery_b partition recovery_a و recovery_b است. چنین دستگاه‌هایی شامل دستگاه‌های A/B و Virtual A/B هستند که پارتیشن بازیابی با پیکربندی زیر قابل به‌روزرسانی است:

AB_OTA_PARTITIONS += recovery

ramdisk vendor_boot شامل بیت‌های فروشنده ماژول‌های ramdisk و vendor kernel، از جمله موارد زیر است:

  • فایل های fstab مخصوص دستگاه

  • lib/modules (شامل ماژول‌های هسته فروشنده)

ramdisk recovery شامل تمام منابع بازیابی است. در چنین دستگاه‌هایی، پیکربندی محصول از generic_ramdisk.mk به ارث می‌رسد .

مقادیر BOARD را تنظیم کنید

مقادیر زیر را برای دستگاه های دارای پارتیشن recovery A/B تنظیم کنید:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

ramdisk recovery می‌تواند حاوی /init -> /system/bin/init و init_second_stage.recovery در /system/bin/init . با این حال، از آنجایی که ramdisk بوت پس از ramdisk recovery به هم پیوسته است، سیم پیوند /init بازنویسی می شود. هنگامی که دستگاه به حالت بازیابی راه‌اندازی می‌شود، باینری /system/bin/init برای پشتیبانی از init مرحله دوم مورد نیاز است.

هنگامی که دستگاه وارد recovery می شود، محتویات recovery + vendor_boot + ramdisks عمومی به شرح زیر است:

  • /init (از ramdisk، ساخته شده از init_first_stage )
  • /system/bin/init (از ramdisk recovery ، ساخته شده از init_second_stage.recovery و اجرا شده از /init )

هنگامی که دستگاه در اندروید بوت می شود، محتویات vendor_boot + ramdisks عمومی به شرح زیر است:

  • /init (از ramdisk عمومی، ساخته شده از init_first_stage )

انتقال فایل های fstab

هر فایل fstab را که به ramdisk عمومی نصب شده است به vendor_ramdisk منتقل کنید. برای مثال به این تغییر مراجعه کنید.

ماژول ها را نصب کنید

به صورت اختیاری، می‌توانید ماژول‌های مخصوص دستگاه را در vendor_ramdisk نصب کنید (اگر ماژول‌های مخصوص دستگاه برای نصب ندارید، از این مرحله رد شوید). Init روت را عوض نمی کند. نوع vendor_ramdisk ماژول ها در ریشه vendor_ramdisk نصب می شود. برای مثال‌هایی در مورد نصب ماژول‌ها در vendor_ramdisk ، به کنسول مرحله اول ، جمع‌های چک فراداده و فشرده‌سازی A/B مجازی مراجعه کنید.

کنسول مرحله اول

برای نصب واریانت vendor_ramdisk از ماژول ها، از موارد زیر استفاده کنید:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

این تضمین می‌کند که linker ، sh و toybox در $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin نصب می‌شوند، که سپس در /system/bin زیر vendor_ramdisk نصب می‌شود.

برای افزودن ماژول های مورد نیاز برای کنسول مرحله اول (به عنوان مثال، adbd)، نوع vendor_ramdisk این ماژول ها را با آپلود وصله های مربوطه در AOSP فعال کنید، سپس از موارد زیر استفاده کنید: 

PRODUCT_PACKAGES += adbd.vendor_ramdisk

این تضمین می کند که ماژول های مشخص شده در $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin نصب شوند. اگر ramdisk vendor_boot در حالت بازیابی بارگیری شود، ماژول در recovery نیز موجود است. اگر ramdisk vendor_boot در حالت بازیابی بارگذاری نشود، دستگاه می‌تواند به صورت اختیاری adbd.recovery نیز نصب کند.

جمع های چک فراداده

برای پشتیبانی از جمع‌های چک فراداده در مرحله اول نصب، دستگاه‌هایی که از GKI پشتیبانی نمی‌کنند، نوع ramdisk ماژول‌های زیر را نصب می‌کنند. برای افزودن پشتیبانی از GKI، ماژول ها را به $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin منتقل کنید: 

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

برای مثال، به این فهرست تغییر مراجعه کنید.

فشرده سازی مجازی A/B

برای پشتیبانی از فشرده سازی مجازی A/B، snapuserd باید در vendor_ramdisk نصب شود. دستگاه باید از virtual_ab_ota/compression.mk که نوع vendor_ramdisk snapuserd را نصب می‌کند به ارث برده شود.

تغییرات در فرآیند بوت

هنگام بوت شدن در اندروید، فرآیند بوت تغییر نمی کند. vendor_boot + ramdisk عمومی مشابه فرآیند بوت موجود است، با این تفاوت که fstab از vendor_boot بارگیری می شود. از آنجا که system/bin/recovery وجود ندارد، first_stage_init آن را به عنوان یک بوت معمولی مدیریت می کند.

هنگام بوت شدن به حالت بازیابی، فرآیند بوت تغییر می کند. بازیابی + vendor_boot + ramdisk عمومی مشابه فرآیند بازیابی موجود است، اما هسته به جای اینکه از تصویر recovery ، از تصویر boot بارگیری شود. فرآیند بوت برای حالت بازیابی به شرح زیر است.

  1. بوت لودر شروع می شود، سپس کارهای زیر را انجام می دهد:

    1. بازیابی + vendor_boot + ramdisk عمومی را به / منتقل می کند. (اگر OEM با افزودن آنها به BOARD_RECOVERY_KERNEL_MODULES ، ماژول‌های هسته را در ramdisk بازیابی کپی کند)، vendor_boot اختیاری است.)
    2. هسته را از پارتیشن boot اجرا می کند.

  2. کرنل ramdisk را به / سپس /init از ramdisk عمومی اجرا می کند.

  3. مرحله اول init شروع می شود، سپس کارهای زیر را انجام می دهد:

    1. IsRecoveryMode() == true و ForceNormalBoot() == false را تنظیم می کند.
    2. ماژول‌های هسته فروشنده را از /lib/modules بارگیری می‌کند.
    3. DoFirstStageMount() فراخوانی می کند اما از نصب می گذرد زیرا IsRecoveryMode() == true . (دستگاه ramdisk را آزاد نمی کند (زیرا / همچنان یکسان است) اما SetInitAvbVersionInRecovery() را فراخوانی می کند.)
    4. مرحله دوم init را از /system/bin/init از ramdisk recovery شروع می کند.

e2fsck را در دسترس قرار دهید

فایل‌های ساخت دستگاه می‌توانند از موارد زیر به ارث ببرند:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk اگر دستگاه از A/B مجازی پشتیبانی می کند اما از فشرده سازی پشتیبانی نمی کند.

  • virtual_ab_ota/compression.mk اگر دستگاه از فشرده سازی مجازی A/B پشتیبانی می کند.

فایل‌های ساخت محصول $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck را نصب می‌کنند. در زمان اجرا، مرحله اول init /system/bin/e2fsck را اجرا می کند.

گزینه 2b: پارتیشن بازیابی اختصاصی و غیر A/B

از این گزینه برای دستگاه هایی با پارتیشن recovery غیر A/B استفاده کنید. یعنی دستگاه دارای یک پارتیشن به نام recovery بدون پسوند اسلات است. چنین دستگاه هایی عبارتند از:

  • دستگاه های غیر A/B؛
  • دستگاه‌های A/B و Virtual A/B که پارتیشن بازیابی آن‌ها قابل به‌روزرسانی نیست. (این غیرعادی است.)

ramdisk vendor_boot شامل بیت‌های فروشنده ماژول‌های ramdisk و vendor kernel، از جمله موارد زیر است:

  • فایل های fstab مخصوص دستگاه
  • lib/modules (شامل ماژول‌های هسته فروشنده)

تصویر recovery باید مستقل باشد. باید شامل تمام منابع مورد نیاز برای راه اندازی حالت بازیابی باشد، از جمله:

  • تصویر هسته
  • تصویر DTBO
  • ماژول های هسته در lib/modules
  • init مرحله اول به عنوان یک پیوند نمادین /init -> /system/bin/init
  • مرحله دوم باینری /system/bin/init
  • فایل های fstab مخصوص دستگاه
  • همه منابع بازیابی دیگر، از جمله باینری recovery

در چنین دستگاه‌هایی، پیکربندی محصول از generic_ramdisk.mk به ارث می‌رسد .

مقادیر BOARD را تنظیم کنید

مقادیر زیر را برای دستگاه های غیر A/B تنظیم کنید: 

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

ramdisk recovery باید دارای یک /init -> /system/bin/init symlink و init_second_stage.recovery در /system/bin/init . هنگامی که دستگاه به حالت بازیابی راه‌اندازی می‌شود، باینری /system/bin/init برای پشتیبانی از مرحله اول و مرحله دوم مورد نیاز است.

هنگامی که دستگاه وارد recovery می شود، محتویات رام دیسک های recovery به شرح زیر است:

  • /init -> /system/bin/init (از ramdisk recovery )
  • /system/bin/init (از ramdisk recovery ، ساخته شده از init_second_stage.recovery و اجرا شده از /init )

هنگامی که دستگاه در اندروید بوت می شود، محتویات vendor_boot + ramdisks عمومی به شرح زیر است:

  • /init (از ramdisk، ساخته شده از init_first_stage )

انتقال فایل های fstab

فایل‌های fstab را که به ramdisk عمومی نصب شده‌اند به vendor_ramdisk و ramdisk recovery منتقل کنید. برای مثال به این تغییر مراجعه کنید.

ماژول ها را نصب کنید

می‌توانید ماژول‌های مخصوص دستگاه را در vendor_ramdisk و ramdisk recovery نصب کنید (اگر ماژول‌های مخصوص دستگاه برای نصب ندارید، از این مرحله رد شوید). init روت را عوض نمی کند. نوع vendor_ramdisk ماژول ها در ریشه vendor_ramdisk نصب می شود. نوع recovery ماژول ها در ریشه رم دیسک recovery نصب می شود. برای مثال‌هایی در مورد نصب ماژول‌ها در vendor_ramdisk و recovery ramdisk، کنسول مرحله اول و جمع‌های چک فراداده را ببینید.

کنسول مرحله اول

برای نصب واریانت vendor_ramdisk از ماژول ها، از موارد زیر استفاده کنید: 

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

این تضمین می‌کند که linker ، sh و toybox در $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin نصب می‌شوند، که سپس در /system/bin زیر vendor_ramdisk نصب می‌شود.

برای افزودن ماژول های مورد نیاز برای کنسول مرحله اول (به عنوان مثال، adbd)، نوع vendor_ramdisk این ماژول ها را با آپلود وصله های مربوطه در AOSP فعال کنید، سپس از موارد زیر استفاده کنید: 

PRODUCT_PACKAGES += adbd.vendor_ramdisk

این تضمین می کند که ماژول های مشخص شده در $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin نصب شوند.

برای نصب نوع recovery ماژول ها، vendor_ramdisk با recovery جایگزین کنید: 

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

جمع های چک فراداده

برای پشتیبانی از جمع‌های چک فراداده در مرحله اول نصب، دستگاه‌هایی که از GKI پشتیبانی نمی‌کنند، نوع ramdisk ماژول‌های زیر را نصب می‌کنند. برای افزودن پشتیبانی از GKI، ماژول ها را به $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin منتقل کنید: 

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

برای پشتیبانی از جمع‌های چک فراداده در مرحله اول نصب در بازیابی، نوع بازیابی این ماژول‌ها را فعال کرده و آنها را نیز نصب کنید.

تغییرات در فرآیند بوت

هنگام بوت شدن در اندروید، فرآیند بوت تغییر نمی کند. vendor_boot + ramdisk عمومی مشابه فرآیند بوت موجود است، با این تفاوت که fstab از vendor_boot بارگیری می شود. از آنجا که system/bin/recovery وجود ندارد، first_stage_init آن را به عنوان یک بوت معمولی مدیریت می کند.

هنگام بوت شدن به حالت بازیابی، فرآیند بوت تغییر نمی کند. ramdisk بازیابی به همان روشی که فرآیند بازیابی موجود بارگذاری می شود. هسته از تصویر recovery بارگیری می شود. فرآیند بوت برای حالت بازیابی به شرح زیر است.

  1. بوت لودر شروع می شود، سپس کارهای زیر را انجام می دهد:

    1. ramdisk بازیابی را به / فشار می دهد.
    2. هسته را از پارتیشن recovery اجرا می کند.

  2. کرنل ramdisk را در / نصب می کند و سپس /init اجرا می کند که یک پیوند نمادین به /system/bin/init از ramdisk recovery است.

  3. مرحله اول init شروع می شود، سپس کارهای زیر را انجام می دهد:

    1. IsRecoveryMode() == true و ForceNormalBoot() == false را تنظیم می کند.
    2. ماژول‌های هسته فروشنده را از /lib/modules بارگیری می‌کند.
    3. DoFirstStageMount() فراخوانی می کند اما از نصب می گذرد زیرا IsRecoveryMode() == true . (دستگاه ramdisk را آزاد نمی کند (زیرا / همچنان یکسان است) اما SetInitAvbVersionInRecovery() را فراخوانی می کند.)
    4. مرحله دوم init را از /system/bin/init از ramdisk recovery شروع می کند.

مهرهای زمانی تصویر بوت

کد زیر نمونه فایل مهر زمانی تصویر boot است: 

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

  • در زمان ساخت، یک فایل system/etc/ramdisk/build.prop به ramdisk عمومی اضافه می شود. این فایل حاوی اطلاعات مهر زمان ساخت است.

  • در زمان اجرا، مرحله اول init فایل‌ها را قبل از آزاد کردن ramdisk از ramdisk به tmpfs کپی می‌کند تا init مرحله دوم init این فایل را بخواند تا ویژگی‌های برچسب زمانی تصویر boot را تنظیم کند.

،

در اندروید 12، تصویر boot عمومی، که به عنوان تصویر هسته عمومی (GKI) شناخته می‌شود، حاوی ramdisk عمومی و هسته GKI است.

برای دستگاه‌هایی که با Android 13 راه‌اندازی می‌شوند، ramdisk عمومی از تصویر boot حذف می‌شود و در یک تصویر init_boot جداگانه قرار می‌گیرد. با این تغییر، تصویر boot تنها با هسته GKI باقی می ماند.

برای ارتقای دستگاه‌هایی که همچنان از اندروید 12 یا نسخه‌های هسته قدیمی‌تر استفاده می‌کنند، ramdisk عمومی در جایی که بود بدون نیاز به تصویر init_boot جدید باقی می‌ماند.

برای ساختن یک ramdisk عمومی، منابع خاص فروشنده را از ramdisk خارج کنید به طوری که ramdisk عمومی فقط شامل مرحله اول init و یک فایل ویژگی است که حاوی اطلاعات timestamp است.

در دستگاه هایی که:

  • از پارتیشن recovery اختصاصی استفاده نکنید، همه بیت های بازیابی از ramdisk عمومی به vendor_boot ramdisk منتقل می شوند.

  • از یک پارتیشن recovery اختصاصی استفاده کنید، هیچ تغییری در ramdisk recovery لازم نیست زیرا ramdisk recovery مستقل است.

معماری

نمودارهای زیر معماری دستگاه های دارای اندروید 12 و بالاتر را نشان می دهد. دستگاهی که با Android 13 راه اندازی می شود، یک تصویر init_boot جدید حاوی ramdisk عمومی دارد. دستگاه هایی که از اندروید 12 به اندروید 13 ارتقا می یابند از همان معماری استفاده می کنند که در اندروید 12 استفاده می کردند.

راه اندازی با اندروید 13، بدون بازیابی اختصاصی

راه اندازی/ارتقا دستگاه، GKI، بدون بازیابی اختصاصی

شکل 1. دستگاه هایی که به اندروید 13 راه اندازی یا ارتقا می یابند، با GKI، بدون بازیابی اختصاصی.

راه اندازی با اندروید 13، ریکاوری اختصاصی و A/B (رمدیسک اختصاصی)

راه اندازی/ارتقا دستگاه، GKI، اختصاصی و بازیابی A/B

شکل 2. دستگاه هایی که به اندروید 13 راه اندازی یا ارتقا می یابند، با GKI، اختصاصی و بازیابی A/B.

اگر دستگاه دارای پارتیشن های recovery_a و recovery_b است به این شکل مراجعه کنید.

راه اندازی با اندروید 13، بازیابی اختصاصی و غیر A/B (رمدیسک اختصاصی)

راه اندازی/ارتقا دستگاه، GKI، بازیابی اختصاصی و غیر A/B

شکل 3. دستگاه هایی که به اندروید 13 راه اندازی یا ارتقا می یابند، با GKI، بازیابی اختصاصی و غیر A/B.

اگر دستگاه دارای پارتیشنی به نام recovery بدون پسوند اسلات است به این شکل مراجعه کنید.

راه اندازی یا ارتقا به اندروید 12، بدون بازیابی اختصاصی

راه اندازی/ارتقا دستگاه، GKI، بدون بازیابی اختصاصی

شکل 4. دستگاه هایی که به اندروید 12 راه اندازی یا ارتقا می یابند، با GKI، بدون بازیابی اختصاصی.

راه اندازی یا ارتقا به اندروید 12، بازیابی اختصاصی و A/B (رمدیسک اختصاصی)

راه اندازی/ارتقا دستگاه، GKI، اختصاصی و بازیابی A/B

شکل 5. دستگاه هایی که به اندروید 12 راه اندازی یا ارتقا می یابند، با GKI، اختصاصی و بازیابی A/B.

اگر دستگاه دارای پارتیشن های recovery_a و recovery_b است به این شکل مراجعه کنید.

راه اندازی یا ارتقا به اندروید 12، بازیابی اختصاصی و غیر A/B (رمدیسک اختصاصی)

راه اندازی/ارتقا دستگاه، GKI، بازیابی اختصاصی و غیر A/B

شکل 6. دستگاه هایی که به اندروید 12 راه اندازی یا ارتقا می یابند، با GKI، بازیابی اختصاصی و غیر A/B.

اگر دستگاه دارای پارتیشنی به نام recovery بدون پسوند اسلات است به این شکل مراجعه کنید.

ارتقا به اندروید 12، بازیابی به عنوان بوت (بازیابی به عنوان ramdisk)

راه‌اندازی/ارتقا دستگاه، بدون GKI، بازیابی به‌عنوان بوت

شکل 7. دستگاه‌هایی که به اندروید 12 ارتقا می‌یابند، بدون GKI، بازیابی به‌عنوان بوت.

ارتقا به اندروید 12، ریکاوری اختصاصی (رمدیسک اختصاصی)

راه اندازی/ارتقا دستگاه، بدون GKI، بازیابی اختصاصی

شکل 8. دستگاه هایی که به اندروید 12 ارتقا می یابند، بدون GKI، بازیابی اختصاصی.

محتویات تصاویر را بوت کنید

تصاویر بوت اندروید شامل موارد زیر است.

  • تصویر init_boot برای دستگاه هایی که با Android 13 راه اندازی می شوند اضافه شد

    • نسخه هدر V4
    • تصویر ramdisk عمومی

  • تصویر boot عمومی

    • نسخه هدر V3 یا V4
      • یک boot_signature برای گواهی GKI boot.img (فقط نسخه 4). گواهی GKI boot.img برای بوت تایید شده امضا نشده است. OEM ها همچنان باید boot.img از پیش ساخته شده را با یک کلید AVB مخصوص دستگاه امضا کنند.
      • cmdline عمومی ( GENERIC_KERNEL_CMDLINE )
      • هسته GKI
    • تصویر ramdisk عمومی
      • فقط در تصاویر boot از اندروید 12 و نسخه های قبلی گنجانده شده است

  • تصویر vendor_boot (برای جزئیات، به پارتیشن‌های بوت فروشنده مراجعه کنید)

    • هدر vendor_boot
      • cmdline ویژه دستگاه ( BOARD_KERNEL_CMDLINE )
    • vendor_boot تصویر ramdisk
      • lib/modules
      • منابع بازیابی (در صورت عدم وجود بازیابی اختصاصی)
    • تصویر dtb

  • تصویر recovery

    • نسخه هدر V2
      • cmdline مخصوص دستگاه برای بازیابی، در صورت لزوم
      • برای پارتیشن بازیابی غیر A/B، محتویات هدر باید مستقل باشد. به تصاویر بازیابی مراجعه کنید. به عنوان مثال:
      • cmdline به boot و vendor_boot cmdline متصل نیست.
      • هدر DTBO بازیابی را در صورت لزوم مشخص می کند.
      • برای پارتیشن بازیابی A/B، محتویات را می توان از boot و vendor_boot به هم پیوست یا استنباط کرد. به عنوان مثال:
      • cmdline به boot و vendor_boot cmdline متصل است.
      • DTBO را می توان از هدر vendor_boot استنباط کرد.
    • تصویر رام دیسک recovery
      • منابع بازیابی
      • برای پارتیشن بازیابی غیر A/B، محتویات ramdisk باید مستقل باشد. به تصاویر بازیابی مراجعه کنید. به عنوان مثال:
      • lib/modules باید شامل تمام ماژول های هسته مورد نیاز برای بوت شدن حالت بازیابی باشد
      • ramdisk بازیابی باید حاوی init باشد.
      • برای پارتیشن بازیابی A/B، ramdisk بازیابی به ramdisk generic و vendor_boot اضافه شده است، بنابراین نیازی به مستقل بودن آن نیست. به عنوان مثال:
      • lib/modules ممکن است علاوه بر ماژول‌های هسته در vendor_boot ramdisk فقط شامل ماژول‌های هسته اضافی مورد نیاز برای راه‌اندازی حالت بازیابی باشد.
      • ممکن است پیوند نمادین در /init وجود داشته باشد، اما توسط باینری /init مرحله اول در تصویر راه‌اندازی تحت الشعاع قرار می‌گیرد.

محتویات تصویر ramdisk عمومی

ramdisk عمومی شامل اجزای زیر است.

  • init
  • system/etc/ramdisk/build.prop
  • ro. PRODUCT .bootimg.* build لوازم
  • دایرکتوری های خالی برای نقاط اتصال: debug_ramdisk/ ، mnt/ ، dev/ ، sys/ ، proc/ ، metadata/
  • first_stage_ramdisk/
    • دایرکتوری های خالی تکراری برای نقاط اتصال: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/

ادغام تصویر بوت

پرچم‌های ساخت نحوه ساخت تصاویر init_boot ، boot ، recovery و vendor_boot را کنترل می‌کنند. مقدار متغیر برد بولی باید رشته true یا خالی باشد (که پیش‌فرض است).

  • TARGET_NO_KERNEL . این متغیر نشان می دهد که آیا بیلد از یک تصویر بوت از پیش ساخته شده استفاده می کند. اگر این متغیر روی true تنظیم شده است، سپس BOARD_PREBUILT_BOOTIMAGE در محل تصویر بوت از پیش ساخته شده قرار دهید ( BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img )

  • BOARD_USES_RECOVERY_AS_BOOT . این متغیر نشان می دهد که آیا دستگاه از تصویر recovery به عنوان تصویر boot استفاده می کند یا خیر. هنگام استفاده از GKI ، این متغیر خالی است و منابع بازیابی باید به vendor_boot منتقل شوند.

  • BOARD_USES_GENERIC_KERNEL_IMAGE . این متغیر نشان می دهد که هیئت مدیره از GKI استفاده می کند. این متغیر روی sysprops یا PRODUCT_PACKAGES تأثیر نمی گذارد.

    این سوئیچ GKI در سطح تخته است. تمام متغیرهای زیر توسط این متغیر محدود می شوند.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT . این متغیر کنترل می کند که آیا منابع بازیابی ramdisk به vendor_boot ساخته شده است.

    • هنگامی که روی true تنظیم شده است ، منابع بازیابی به vendor-ramdisk/ فقط ساخته می شوند و برای recovery/root/ ساخته نشده اند.

    • هنگامی که خالی باشد ، منابع بازیابی برای recovery/root/ فقط ساخته می شوند و برای vendor-ramdisk/ ساخته نشده اند.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT . این متغیر کنترل می کند که آیا کلیدهای GSI AVB به vendor_boot ساخته شده اند.

    • هنگامی که روی true تنظیم شده است ، اگر BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

      • تنظیم شده است ، کلیدهای GSI AVB به $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb ساخته شده اند.

      • غیرقانونی است ، کلیدهای GSI AVB به $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb ساخته شده اند.

    • وقتی خالی است ، اگر BOARD_RECOVERY_AS_ROOT :

      • تنظیم شده است ، کلیدهای GSI AVB به $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb ساخته شده اند.

      • غیرقانونی است ، کلیدهای GSI AVB به $ANDROID_PRODUCT_OUT/ramdisk/avb ساخته شده اند.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE . این متغیر کنترل می کند که آیا تصویر recovery حاوی هسته است یا خیر. دستگاه هایی که با Android 12 راه اندازی می شوند و با استفاده از پارتیشن recovery A/B باید این متغیر را true تنظیم کنند. دستگاه هایی که با Android 12 راه اندازی می شوند و با استفاده از غیر A/B باید این متغیر را به false تنظیم کنند تا تصویر بازیابی خود به خود حفظ شود.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES . این متغیر کنترل می کند که آیا $OUT/boot*.img در IMAGES/ تحت پرونده های هدف کپی می شود.

    • aosp_arm64 باید این متغیر را بر روی true تنظیم کند.

    • دستگاه های دیگر باید این متغیر را خالی بگذارند.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE . این متغیر کنترل می کند که آیا init_boot.img تولید می شود و اندازه را تعیین می کند. در صورت تنظیم ، RamDisk عمومی به جای boot.img به init_boot.img اضافه می شود و به متغیرهای BOARD_AVB_INIT_BOOT* نیاز دارد تا برای vbmeta زنجیر شده تنظیم شود.

ترکیبات مجاز

مؤلفه یا متغیر دستگاه را بدون پارتیشن بازیابی ارتقا دهید دستگاه را با پارتیشن بازیابی ارتقا دهید دستگاه را بدون پارتیشن بازیابی راه اندازی کنید دستگاه را با پارتیشن بازیابی A/B راه اندازی کنید دستگاه را با پارتیشن بازیابی غیر A/B راه اندازی کنید AOSP_ARM64
حاوی boot است بله بله بله بله بله بله
حاوی init_boot (Android 13) نه نه بله بله بله بله
حاوی vendor_boot است اختیاری اختیاری بله بله بله نه
حاوی recovery نه بله نه بله بله نه
BOARD_USES_RECOVERY_AS_BOOT true خالی خالی خالی خالی خالی
BOARD_USES_GENERIC_KERNEL_IMAGE خالی خالی true true true true
PRODUCT_BUILD_RECOVERY_IMAGE خالی true یا خالی خالی true یا خالی true یا خالی خالی
BOARD_RECOVERYIMAGE_PARTITION_SIZE خالی > 0 خالی > 0 > 0 خالی
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT خالی خالی true خالی خالی خالی
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT خالی خالی true true true خالی
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE خالی خالی خالی true خالی خالی
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES خالی خالی خالی خالی خالی true

دستگاه هایی با یک پارتیشن recovery اختصاصی می توانند PRODUCT_BUILD_RECOVERY_IMAGE به true یا خالی تنظیم کنند. برای این دستگاه ها ، اگر BOARD_RECOVERYIMAGE_PARTITION_SIZE تنظیم شده باشد ، یک تصویر recovery ساخته می شود.

VBMeta زنجیر شده را برای بوت فعال کنید

VBMETA زنجیره ای باید برای تصاویر boot و init_boot فعال شود. موارد زیر را مشخص کنید:

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

برای مثال ، به این تغییر مراجعه کنید.

سیستمرایت

سیستم به عنوان ریشه برای دستگاه هایی که از GKI استفاده می کنند پشتیبانی نمی شود. در چنین دستگاه هایی ، BOARD_BUILD_SYSTEM_ROOT_IMAGE باید خالی باشد. سیستم به عنوان ریشه نیز برای دستگاه هایی که از پارتیشن های پویا استفاده می کنند پشتیبانی نمی شود.

تنظیمات محصول

دستگاه هایی که از RamDisk عمومی استفاده می کنند باید لیستی از پرونده هایی را که مجاز به نصب در Ramdisk هستند ، نصب کنند. برای انجام این کار ، موارد زیر را در device.mk مشخص کنید. mk:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

پرونده generic_ramdisk.mk همچنین مانع از نصب تصادفی سایر فایلهای دیگر در Ramdisk می شود (به جای آن چنین پرونده هایی را به vendor_ramdisk منتقل کنید).

دستگاه ها را تنظیم کنید

دستورالعمل های راه اندازی بین دستگاه های راه اندازی با Android 13 ، ارتقاء به Android 12 و راه اندازی با Android 12. Android 13 ، تنظیم شده است شبیه به نحوه حضور آنها با Android 12

  • دستگاه های ارتقاء به Android 12:

    • می تواند مقدار BOARD_USES_RECOVERY_AS_BOOT را حفظ کند. اگر این کار را انجام دهند ، آنها از پیکربندی های میراث استفاده می کنند و متغیرهای جدید ساخت باید خالی باشد. اگر چنین دستگاه هایی:

      • BOARD_USES_RECOVERY_AS_BOOT را true کنید ، معماری همانطور که در شکل 3 نشان داده شده است.

      • BOARD_USES_RECOVERY_AS_BOOT را تنظیم کنید ، معماری همانطور که شکل 4 نشان داده شده است.

    • می تواند BOARD_USES_RECOVERY_AS_BOOT را خالی کند. اگر این کار را انجام دهند ، آنها از تنظیمات جدید استفاده می کنند. اگر چنین دستگاه هایی:

      • از یک پارتیشن recovery اختصاصی استفاده نکنید ، معماری همانطور که در شکل 1 نشان داده شده است و گزینه تنظیم دستگاه گزینه 1 است.

      • از یک پارتیشن recovery اختصاصی استفاده کنید ، معماری همانطور که در شکل 2A یا شکل 2B نشان داده شده است و گزینه تنظیم دستگاه گزینه 2A یا گزینه 2B است.

  • دستگاه هایی که با Android 12 راه اندازی می شوند باید BOARD_USES_RECOVERY_AS_BOOT را خالی کنند و از پیکربندی های جدید استفاده کنند. اگر چنین دستگاه هایی:

    • از یک پارتیشن recovery اختصاصی استفاده نکنید ، معماری همانطور که در شکل 1 نشان داده شده است و گزینه تنظیم دستگاه گزینه 1 است.

    • از یک پارتیشن recovery اختصاصی استفاده کنید ، معماری همانطور که در شکل 2A یا شکل 2B نشان داده شده است و گزینه تنظیم دستگاه گزینه 2A یا گزینه 2B است.

از آنجا که aosp_arm64 فقط GKI (و نه vendor_boot یا بازیابی) ایجاد می کند ، یک هدف کامل نیست. برای تنظیمات ساخت aosp_arm64 ، به generic_arm64 مراجعه کنید.

گزینه 1: بدون پارتیشن بازیابی اختصاصی

دستگاه های بدون پارتیشن recovery حاوی تصویر boot عمومی در پارتیشن boot است. Ramdisk vendor_boot شامل کلیه منابع بازیابی ، از جمله lib/modules (با ماژول های هسته فروشنده) است. در چنین دستگاه هایی ، پیکربندی محصول از generic_ramdisk.mk به ارث می برد .

مقادیر صفحه را تنظیم کنید

مقادیر زیر را تنظیم کنید:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Ramdisk vendor_boot می تواند حاوی /init /system/bin/init symlink و init_second_stage.recovery at /system/bin/init . با این حال ، از آنجا که ramdisk عمومی پس از vendor_boot amdisk به دست می آید ، Symlink /init بازنویسی می شود. هنگامی که دستگاه به بازیابی می پردازد ، برای پشتیبانی از مرحله دوم ، باینری /system/bin/init لازم است. محتوای vendor_boot + ramdisks عمومی به شرح زیر است:

  • /init (از ramdisk عمومی ، ساخته شده از init_first_stage )
  • /system/bin/init (از vendor_ramdisk ، ساخته شده از init_second_stage.recovery )

پرونده های FSTAB را جابجا کنید

هر پرونده fstab را که به RamDisk عمومی نصب شده است به vendor_ramdisk منتقل کنید. برای مثال ، به این تغییر مراجعه کنید.

ماژول ها را نصب کنید

شما می توانید ماژول های خاص دستگاه را به vendor_ramdisk نصب کنید (اگر هیچ ماژول مخصوص دستگاه برای نصب ندارید ، این مرحله را پرش کنید).

  • هنگامی که ماژول به /first_stage_ramdisk نصب می شود ، از نوع vendor_ramdisk ماژول استفاده کنید. این ماژول باید بعد از سوئیچ های init Root به /first_stage_ramdisk در دسترس باشد ، اما قبل از اینکه init root را به /system سوئیچ کند. برای مثال ، به بررسی های ابرداده و فشرده سازی مجازی A/B مراجعه کنید.

  • هنگام نصب ماژول به / از نوع recovery ماژول استفاده کنید. این ماژول باید قبل از تغییر init root به /first_stage_ramdisk در دسترس باشد. برای جزئیات بیشتر در مورد نصب ماژول ها به / ، به کنسول مرحله اول مراجعه کنید.

کنسول مرحله اول

از آنجا که کنسول مرحله اول قبل از شروع init به /first_stage_ramdisk شروع می شود ، باید نوع recovery ماژول ها را نصب کنید. به طور پیش فرض ، هر دو نوع ماژول برای build/make/target/product/base_vendor.mk نصب شده اند ، بنابراین اگر دستگاه MakeFile از آن پرونده به ارث می برد ، نیازی به نصب صریح نوع recovery ندارید.

برای نصب صریح ماژول های بازیابی ، از موارد زیر استفاده کنید.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

این تضمین می کند که linker ، sh و toybox به $ANDROID_PRODUCT_OUT/recovery/root/system/bin نصب می شوند ، که سپس به /system/bin زیر vendor_ramdisk نصب می کند.

برای افزودن ماژول های مورد نیاز برای کنسول مرحله اول (به عنوان مثال ، ADBD) ، از موارد زیر استفاده کنید.

PRODUCT_PACKAGES += adbd.recovery

این تضمین می کند که ماژول های مشخص شده به $ANDROID_PRODUCT_OUT/recovery/root/system/bin نصب می شوند ، که سپس به /system/bin در زیر vendor_ramdisk نصب می کند.

چک های ابرداده

برای پشتیبانی از چک های ابرداده در مرحله اول ، دستگاه هایی که از GKI پشتیبانی نمی کنند ، نوع Ramdisk ماژول های زیر را نصب می کنند. برای افزودن پشتیبانی از GKI ، ماژول ها را به $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin منتقل کنید:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

برای مثال ، به این تغییر دهنده مراجعه کنید.

فشرده سازی A/B مجازی

برای پشتیبانی از فشرده سازی A/B مجازی ، snapuserd باید به vendor_ramdisk نصب شود. دستگاه باید از virtual_ab_ota/compression.mk به ارث ببرد ، که نوع vendor_ramdisk از snapuserd را نصب می کند.

تغییر در فرآیند بوت

روند بوت شدن به بازیابی یا به اندروید تغییر نمی کند ، با استثناء زیر:

  • Ramdisk build.prop به /second_stage_resources حرکت می کند تا مرحله دوم init بتواند زمان ساخت بوت را بخواند.

از آنجا که منابع از Ramdisk عمومی به vendor_boot Ramdisk منتقل می شوند ، نتیجه جمع آوری RamDisk عمومی به vendor_boot ramdisk تغییر نمی کند.

E2FSCK را در دسترس قرار دهید

دستگاه Makefiles می تواند از:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk اگر دستگاه از A/B مجازی پشتیبانی می کند اما فشرده سازی ندارد.

  • virtual_ab_ota/compression.mk اگر دستگاه از فشرده سازی A/B مجازی پشتیبانی می کند.

محصول MakeFiles $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck نصب می کند. در زمان اجرا ، مرحله اول init ریشه را به /first_stage_ramdisk تغییر می دهد و سپس /system/bin/e2fsck اجرا می کند.

گزینه 2A: پارتیشن بازیابی اختصاصی و A/B

از این گزینه برای دستگاه هایی با پارتیشن های recovery A/B استفاده کنید. یعنی دستگاه دارای پارتیشن recovery_a و recovery_b partition است. چنین دستگاه هایی شامل A/B و دستگاه های A/B مجازی هستند که پارتیشن بازیابی به روز می شود ، با پیکربندی زیر:

AB_OTA_PARTITIONS += recovery

Ramdisk vendor_boot حاوی بیت های فروشنده ماژول های هسته Ramdisk و فروشنده ، از جمله موارد زیر است:

  • پرونده های fstab خاص دستگاه

  • lib/modules (شامل ماژول های هسته فروشنده)

Ramdisk recovery شامل تمام منابع بازیابی است. در چنین دستگاه هایی ، پیکربندی محصول از generic_ramdisk.mk به ارث می برد .

مقادیر صفحه را تنظیم کنید

مقادیر زیر را برای دستگاه هایی با پارتیشن recovery A/B تنظیم کنید:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

recovery ramdisk می تواند حاوی /init -> /system/bin/init symlink و init_second_stage.recovery at /system/bin/init . با این حال ، از آنجا که Ramdisk بوت پس از recovery RAMDISK به هم پیوسته است ، Symlink /init بازنویسی می شود. هنگامی که دستگاه به حالت بازیابی بوت می شود ، برای پشتیبانی از مرحله دوم ، باینری /system/bin/init لازم است.

هنگامی که دستگاه در حال recovery است ، محتوای recovery + vendor_boot + ramdisks عمومی به شرح زیر است:

  • /init (از ramdisk ، ساخته شده از init_first_stage )
  • /system/bin/init (از Ramdisk recovery ، ساخته شده از init_second_stage.recovery ، و از /init اجرا شده است)

هنگامی که دستگاه به Android بوت می شود ، محتوای RamDisks Generic vendor_boot به شرح زیر است:

  • /init (از ramdisk عمومی ، ساخته شده از init_first_stage )

پرونده های FSTAB را جابجا کنید

هر پرونده fstab را که به RamDisk عمومی نصب شده است به vendor_ramdisk منتقل کنید. برای مثال ، به این تغییر مراجعه کنید.

ماژول ها را نصب کنید

به صورت اختیاری ، می توانید ماژول های خاص دستگاه را به vendor_ramdisk نصب کنید (اگر هیچ ماژول مخصوص دستگاه برای نصب ندارید ، از این مرحله پرش کنید). Init ریشه را تغییر نمی دهد. vendor_ramdisk نوع ماژول ها به ریشه vendor_ramdisk نصب می شود. برای مثال در مورد نصب ماژول ها به vendor_ramdisk ، به کنسول مرحله اول ، چک های ابرداده و فشرده سازی مجازی A/B مراجعه کنید.

کنسول مرحله اول

برای نصب vendor_ramdisk نوع ماژول ها ، از موارد زیر استفاده کنید:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

این تضمین می کند که linker ، sh و toybox به $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin نصب می شوند ، که سپس به /system/bin زیر vendor_ramdisk نصب می شود.

برای افزودن ماژول های مورد نیاز برای کنسول مرحله اول (به عنوان مثال ، ADBD) ، با بارگذاری تکه های مربوطه به AOSP ، نوع vendor_ramdisk این ماژول ها را فعال کنید ، سپس از موارد زیر استفاده کنید. 

PRODUCT_PACKAGES += adbd.vendor_ramdisk

این تضمین می کند که ماژول های مشخص شده به $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin نصب می شوند. اگر Ramdisk vendor_boot در حالت بازیابی بارگیری شود ، ماژول در recovery نیز موجود است. اگر Ramdisk vendor_boot در حالت بازیابی بارگیری نشود ، دستگاه می تواند به صورت اختیاری adbd.recovery نیز نصب کند.

چک های ابرداده

برای پشتیبانی از چک های ابرداده در مرحله اول ، دستگاه هایی که از GKI پشتیبانی نمی کنند ، نوع Ramdisk ماژول های زیر را نصب می کنند. برای افزودن پشتیبانی از GKI ، ماژول ها را به $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin منتقل کنید: 

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

برای مثال ، به این تغییر دهنده مراجعه کنید.

فشرده سازی A/B مجازی

برای پشتیبانی از فشرده سازی A/B مجازی ، snapuserd باید به vendor_ramdisk نصب شود. دستگاه باید از virtual_ab_ota/compression.mk به ارث ببرد ، که نوع vendor_ramdisk از snapuserd را نصب می کند.

تغییر در فرآیند بوت

هنگام بوت شدن به Android ، روند بوت تغییر نمی کند. Ramdisk vendor_boot + عمومی شبیه به فرآیند بوت موجود است ، به جز اینکه fstab از vendor_boot بار می کند. از آنجا که system/bin/recovery وجود ندارد ، first_stage_init آن را به عنوان یک چکمه معمولی اداره می کند.

هنگام بوت شدن در حالت بازیابی ، فرآیند بوت تغییر می کند. بازیابی + vendor_boot + generic ramdisk شبیه به فرآیند بازیابی موجود است ، اما هسته به جای تصویر recovery از تصویر boot بارگیری می شود. فرآیند بوت برای حالت بازیابی به شرح زیر است.

  1. bootloader شروع می شود ، سپس موارد زیر را انجام می دهد:

    1. بازیابی + vendor_boot + Generic ramdisk to / . (اگر OEM با اضافه کردن آنها به BOARD_RECOVERY_KERNEL_MODULES ، ماژول های هسته را در بازیابی ramdisk کپی می کند ، vendor_boot اختیاری است.)
    2. هسته را از پارتیشن boot اجرا می کند.

  2. هسته Ramdisk را به / سپس از Ramdisk عمومی /init می کند.

  3. مرحله اول شروع می شود ، سپس موارد زیر را انجام می دهد:

    1. IsRecoveryMode() == true و ForceNormalBoot() == false .
    2. ماژول های هسته فروشنده را از /lib/modules بارگیری می کنند.
    3. DoFirstStageMount() فراخوانی می کند اما از آنجا می رود زیرا IsRecoveryMode() == true . / SetInitAvbVersionInRecovery()
    4. شروع مرحله دوم را از /system/bin/init از recovery ramdisk شروع می کند.

E2FSCK را در دسترس قرار دهید

دستگاه Makefiles می تواند از:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk اگر دستگاه از A/B مجازی پشتیبانی می کند اما فشرده سازی ندارد.

  • virtual_ab_ota/compression.mk اگر دستگاه از فشرده سازی A/B مجازی پشتیبانی می کند.

محصول MakeFiles $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck را نصب می کند. در زمان اجرا ، مرحله اول init /system/bin/e2fsck را اجرا می کند.

گزینه 2B: پارتیشن بازیابی اختصاصی و غیر A/B

از این گزینه برای دستگاه هایی با پارتیشن recovery غیر A/B استفاده کنید. یعنی دستگاه دارای یک پارتیشن به نام recovery بدون پسوند شکاف است. چنین دستگاه هایی عبارتند از:

  • دستگاه های غیر A/B ؛
  • دستگاه های A/B و مجازی A/B ، که پارتیشن بازیابی به روز نمی شود. (این غیر معمول است.)

Ramdisk vendor_boot حاوی بیت های فروشنده ماژول های هسته Ramdisk و فروشنده ، از جمله موارد زیر است:

  • پرونده های fstab خاص دستگاه
  • lib/modules (شامل ماژول های هسته فروشنده)

تصویر recovery باید دارای خود باشد. این باید شامل تمام منابع مورد نیاز برای بوت شدن حالت بازیابی باشد ، از جمله:

  • تصویر هسته
  • تصویر DTBO
  • ماژول های هسته در lib/modules
  • مرحله اول به عنوان یک Symlink /init -> /system/bin/init
  • مرحله دوم باینری /system/bin/init
  • پرونده های fstab خاص دستگاه
  • تمام منابع بهبودی دیگر ، از جمله باینری recovery

در چنین دستگاه هایی ، پیکربندی محصول از generic_ramdisk.mk به ارث می برد .

مقادیر صفحه را تنظیم کنید

مقادیر زیر را برای دستگاه های غیر A/B تنظیم کنید: 

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

recovery ramdisk باید حاوی یک /init -> /system/bin/init symlink و init_second_stage.recovery at /system/bin/init . هنگامی که دستگاه به حالت بازیابی بوت می شود ، برای پشتیبانی از هر دو مرحله اول و مرحله دوم /system/bin/init مورد نیاز است.

هنگامی که دستگاه در حال recovery است ، محتوای Ramdisks recovery به شرح زیر است:

  • /init -> /system/bin/init (از recovery ramdisk)
  • /system/bin/init (از Ramdisk recovery ، ساخته شده از init_second_stage.recovery ، و از /init اجرا شده است)

هنگامی که دستگاه به Android بوت می شود ، محتوای RamDisks Generic vendor_boot به شرح زیر است:

  • /init (از ramdisk ، ساخته شده از init_first_stage )

پرونده های FSTAB را جابجا کنید

هر پرونده fstab را که به RamDisk عمومی نصب شده است به vendor_ramdisk و Ramdisk recovery منتقل کنید. برای مثال ، به این تغییر مراجعه کنید.

ماژول ها را نصب کنید

شما می توانید ماژول های خاص دستگاه را به vendor_ramdisk و recovery RAMDISK نصب کنید (اگر هیچ ماژول مخصوص دستگاه برای نصب ندارید ، این مرحله را پرش کنید). init ریشه را تغییر نمی دهد. vendor_ramdisk نوع ماژول ها به ریشه vendor_ramdisk نصب می شود. نوع recovery ماژول ها به ریشه recovery Ramdisk نصب می شود. برای نمونه هایی در مورد نصب ماژول ها به vendor_ramdisk و recovery Ramdisk ، SE Console Stage و Checksums .

کنسول مرحله اول

برای نصب vendor_ramdisk نوع ماژول ها ، از موارد زیر استفاده کنید: 

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

این تضمین می کند که linker ، sh و toybox به $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin نصب می شوند ، که سپس به /system/bin زیر vendor_ramdisk نصب می شود.

برای افزودن ماژول های مورد نیاز برای کنسول مرحله اول (به عنوان مثال ، ADBD) ، با بارگذاری تکه های مربوطه به AOSP ، نوع vendor_ramdisk این ماژول ها را فعال کنید ، سپس از موارد زیر استفاده کنید. 

PRODUCT_PACKAGES += adbd.vendor_ramdisk

این تضمین می کند که ماژول های مشخص شده به $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin نصب می شوند.

برای نصب نوع recovery ماژول ها ، vendor_ramdisk با recovery جایگزین کنید: 

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

چک های ابرداده

برای پشتیبانی از چک های ابرداده در مرحله اول ، دستگاه هایی که از GKI پشتیبانی نمی کنند ، نوع Ramdisk ماژول های زیر را نصب می کنند. برای افزودن پشتیبانی از GKI ، ماژول ها را به $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin منتقل کنید: 

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

برای پشتیبانی از چک های ابرداده در مرحله اول در مرحله بازیابی ، نوع بازیابی این ماژول ها را فعال کرده و آنها را نیز نصب کنید.

تغییر در فرآیند بوت

هنگام بوت شدن به Android ، روند بوت تغییر نمی کند. Ramdisk vendor_boot + عمومی شبیه به فرآیند بوت موجود است ، به جز اینکه fstab از vendor_boot بار می کند. از آنجا که system/bin/recovery وجود ندارد ، first_stage_init آن را به عنوان یک چکمه معمولی اداره می کند.

هنگام بوت شدن در حالت بازیابی ، روند بوت تغییر نمی کند. Ramdisk Recovery به همان روشی که فرآیند بازیابی موجود بارگیری می شود ، بارگیری می شود. هسته از تصویر recovery بارگیری می شود. فرآیند بوت برای حالت بازیابی به شرح زیر است.

  1. bootloader شروع می شود ، سپس موارد زیر را انجام می دهد:

    1. بازیابی Ramdisk را به / .
    2. هسته را از پارتیشن recovery اجرا می کند.

  2. هسته Ramdisk را به / سپس اجرا /init می کند ، که یک Symlink به /system/bin/init از Ramdisk recovery است.

  3. مرحله اول شروع می شود ، سپس موارد زیر را انجام می دهد:

    1. IsRecoveryMode() == true و ForceNormalBoot() == false .
    2. ماژول های هسته فروشنده را از /lib/modules بارگیری می کنند.
    3. DoFirstStageMount() فراخوانی می کند اما از آنجا می رود زیرا IsRecoveryMode() == true . / SetInitAvbVersionInRecovery()
    4. شروع مرحله دوم را از /system/bin/init از recovery ramdisk شروع می کند.

زمان سنجی تصویر بوت

کد زیر یک فایل Timestamp تصویر boot است: 

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

  • در زمان ساخت ، یک پرونده system/etc/ramdisk/build.prop به ramdisk عمومی اضافه می شود. این پرونده حاوی اطلاعات زمانی از ساخت است.

  • در زمان Runtime ، Stage init فایلهایی را از RamDisk به tmpfs قبل از آزاد کردن RAMDISK کپی می کند تا Stage Stage init بتواند این فایل را بخواند تا ویژگی های Timestamp boot Image را تنظیم کند.

،

در Android 12 ، تصویر boot عمومی ، که از آن به عنوان تصویر هسته عمومی (GKI) یاد می شود ، حاوی Ramdisk عمومی و هسته GKI است.

برای دستگاه هایی که با Android 13 راه اندازی می شوند ، Ramdisk عمومی از تصویر boot خارج می شود و در یک تصویر جداگانه init_boot قرار می گیرد. این تغییر تصویر boot را فقط با هسته GKI ترک می کند.

برای به روزرسانی دستگاه هایی که به استفاده از نسخه های هسته Android 12 یا قدیمی تر ادامه می دهند ، RamDisk عمومی در جایی باقی می ماند که بدون نیاز به یک تصویر جدید init_boot است.

برای ساختن یک Ramdisk عمومی ، منابع خاص فروشنده را از Ramdisk جابجا کنید به گونه ای که Ramdisk عمومی فقط شامل مرحله اول init اول و یک پرونده خاص است که حاوی اطلاعات Timestamp است.

در دستگاه هایی که:

  • از یک پارتیشن recovery اختصاصی استفاده نکنید ، تمام بیت های بازیابی از Ramdisk عمومی به vendor_boot RAMDISK منتقل می شوند.

  • آیا از یک پارتیشن recovery اختصاصی استفاده کنید ، هیچ تغییری در Ramdisk recovery لازم نیست زیرا Ramdisk recovery دارای خود است.

معماری

نمودارهای زیر معماری دستگاههای دارای Android 12 و بالاتر را نشان می دهد. راه اندازی دستگاه با Android 13 دارای یک تصویر جدید init_boot است که حاوی ramdisk عمومی است. دستگاه های ارتقاء از Android 12 به Android 13 از همان معماری که با Android 12 انجام داده اند استفاده می کنند.

راه اندازی با Android 13 ، بدون بازیابی اختصاصی

دستگاه راه اندازی/به روزرسانی ، GKI ، بدون بازیابی اختصاصی

شکل 1. دستگاه هایی که به Android 13 راه اندازی یا به روز می شوند ، با GKI ، هیچ بازیابی اختصاصی ندارند.

راه اندازی با Android 13 ، بازیابی اختصاصی و A/B (اختصاصی RAMDISK)

دستگاه راه اندازی/به روزرسانی ، GKI ، اختصاصی و بازیابی A/B

شکل 2. دستگاه هایی که به Android 13 راه اندازی یا به روز می شوند ، با GKI ، اختصاصی و بازیابی A/B.

اگر دستگاه دارای پارتیشن های recovery_a و recovery_b است ، به این شکل مراجعه کنید.

راه اندازی با Android 13 ، بازیابی اختصاصی و غیر A/B (اختصاصی RAMDISK)

دستگاه راه اندازی/به روزرسانی ، GKI ، بازیابی اختصاصی و غیر A/B

شکل 3 دستگاه های راه اندازی یا به روزرسانی به Android 13 ، با GKI ، بازیابی اختصاصی و غیر A/B.

اگر دستگاه دارای یک پارتیشن به نام recovery بدون پسوند شکاف است ، به این شکل مراجعه کنید.

راه اندازی یا به روزرسانی به Android 12 ، بدون بازیابی اختصاصی

دستگاه راه اندازی/به روزرسانی ، GKI ، بدون بازیابی اختصاصی

شکل 4. دستگاه های راه اندازی یا به روزرسانی به Android 12 ، با GKI ، بدون بازیابی اختصاصی.

راه اندازی یا به روزرسانی در Android 12 ، اختصاصی و بازیابی A/B (اختصاصی RAMDISK)

دستگاه راه اندازی/به روزرسانی ، GKI ، اختصاصی و بازیابی A/B

شکل 5 دستگاه های راه اندازی یا به روزرسانی به Android 12 ، با GKI ، اختصاصی و بازیابی A/B.

اگر دستگاه دارای پارتیشن های recovery_a و recovery_b است ، به این شکل مراجعه کنید.

راه اندازی یا به روزرسانی در Android 12 ، بازیابی اختصاصی و غیر A/B (اختصاصی RAMDISK)

دستگاه راه اندازی/به روزرسانی ، GKI ، بازیابی اختصاصی و غیر A/B

شکل 6 دستگاه های راه اندازی یا به روزرسانی به Android 12 ، با GKI ، بازیابی اختصاصی و غیر A/B.

اگر دستگاه دارای یک پارتیشن به نام recovery بدون پسوند شکاف است ، به این شکل مراجعه کنید.

به روزرسانی به Android 12 ، Recovery-as-Boot (Recovery-as-ramdisk)

دستگاه راه اندازی/به روزرسانی ، بدون GKI ، بازیابی به عنوان بوت

شکل 7. دستگاه های به روزرسانی به Android 12 ، No GKI ، بازیابی به عنوان بوت.

ارتقا به Android 12 ، Recovery Recovery (اختصاصی Ramdisk)

دستگاه راه اندازی/به روزرسانی ، بدون GKI ، بازیابی اختصاصی

شکل 8. دستگاه های ارتقاء یافته به Android 12 ، بدون GKI ، بازیابی اختصاصی.

محتویات تصاویر بوت

تصاویر بوت Android شامل موارد زیر است.

  • init_boot تصویر اضافه شده برای دستگاه های راه اندازی با Android 13

    • نسخه هدر v4
    • تصویر عمومی ramdisk

  • تصویر boot عمومی

    • نسخه هدر V3 یا V4
      • boot_signature برای صدور گواهینامه GKI boot.img (فقط V4). GKI boot.img معتبر برای بوت تأیید شده امضا نشده است. OEM ها هنوز هم باید boot.img preduilt را با یک کلید AVB خاص دستگاه امضا کنند.
      • cmdline عمومی ( GENERIC_KERNEL_CMDLINE )
      • هسته GKI
    • تصویر عمومی ramdisk
      • فقط در تصاویر boot از Android 12 و قبل از آن گنجانده شده است

  • تصویر vendor_boot (برای جزئیات بیشتر ، به پارتیشن های بوت فروشنده مراجعه کنید)

    • هدر vendor_boot
      • cmdline خاص دستگاه ( BOARD_KERNEL_CMDLINE )
    • تصویر Ramdisk vendor_boot
      • lib/modules
      • منابع بازیابی (در صورت عدم بهبودی اختصاصی)
    • تصویر dtb

  • تصویر recovery

    • نسخه هدر v2
      • در صورت لزوم cmdline خاص دستگاه برای بازیابی
      • برای پارتیشن بازیابی غیر A/B ، محتوای هدر باید مستقل باشد. به تصاویر بازیابی مراجعه کنید. به عنوان مثال:
      • cmdline برای boot و cmdline boot و vendor_boot جمع نمی شود.
      • هدر در صورت لزوم بازیابی DTBO را مشخص می کند.
      • برای پارتیشن بازیابی A/B ، محتویات را می توان از boot و vendor_boot جدا کرد یا استنباط کرد. به عنوان مثال:
      • cmdline برای boot و cmdline boot و vendor_boot جمع شده است.
      • DTBO را می توان از هدر vendor_boot استنباط کرد.
    • recovery تصویر ramdisk
      • منابع بازیابی
      • برای پارتیشن بازیابی غیر A/B ، محتوای Ramdisk باید مستقل باشد. به تصاویر بازیابی مراجعه کنید. به عنوان مثال:
      • lib/modules باید حاوی تمام ماژول های هسته مورد نیاز برای راه اندازی حالت بازیابی باشند
      • Ramdisk Recovery باید حاوی init باشد.
      • برای پارتیشن بازیابی A/B ، Ramdisk Recovery به Generic و vendor_boot Ramdisk آماده می شود ، از این رو نیازی به مستقل بودن ندارد. به عنوان مثال:
      • lib/modules ممکن است فقط حاوی ماژول های هسته اضافی مورد نیاز برای بوت شدن حالت بازیابی علاوه بر ماژول های هسته در vendor_boot RAMDISK باشند.
      • Symlink at /init ممکن است وجود داشته باشد ، اما تحت الشعاع باینری مرحله اول /init در تصویر بوت است.

محتوای تصویر ramdisk عمومی

ramdisk عمومی حاوی مؤلفه های زیر است.

  • init
  • system/etc/ramdisk/build.prop
  • ro. PRODUCT .bootimg.* build غرفه ها
  • دایرکتوری های خالی برای Mount Points: debug_ramdisk/ ، mnt/ ، dev/ ، sys/ ، proc/ ، metadata/
  • first_stage_ramdisk/
    • دایرکتوری های خالی کپی شده برای Mount Points: debug_ramdisk/ ، mnt/ ، dev/ ، sys/ ، proc/ ، metadata/

ادغام تصویر بوت

ساخت پرچم ها کنترل چگونگی ساخت تصاویر init_boot ، boot ، recovery و vendor_boot را کنترل می کنند. مقدار یک متغیر تخته بولی باید رشته true باشد یا خالی باشد (که پیش فرض است).

  • TARGET_NO_KERNEL . این متغیر نشان می دهد که آیا ساخت از یک تصویر بوت از پیش ساخته استفاده می کند یا خیر. اگر این متغیر روی true تنظیم شده است ، سپس BOARD_PREBUILT_BOOTIMAGE روی محل تصویر بوت پیش ساخته ( BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img ) تنظیم کنید.

  • BOARD_USES_RECOVERY_AS_BOOT . این متغیر نشان می دهد که آیا دستگاه از تصویر recovery به عنوان تصویر boot استفاده می کند. هنگام استفاده از GKI ، این متغیر خالی است و منابع بازیابی باید به vendor_boot منتقل شوند.

  • BOARD_USES_GENERIC_KERNEL_IMAGE . این متغیر نشان می دهد که هیئت مدیره از GKI استفاده می کند. این متغیر روی sysprops یا PRODUCT_PACKAGES تأثیر نمی گذارد.

    این سوئیچ GKI در سطح تخته است. تمام متغیرهای زیر توسط این متغیر محدود می شوند.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT . این متغیر کنترل می کند که آیا منابع بازیابی ramdisk به vendor_boot ساخته شده است.

    • هنگامی که روی true تنظیم شده است ، منابع بازیابی به vendor-ramdisk/ فقط ساخته می شوند و برای recovery/root/ ساخته نشده اند.

    • هنگامی که خالی باشد ، منابع بازیابی برای recovery/root/ فقط ساخته می شوند و برای vendor-ramdisk/ ساخته نشده اند.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT . این متغیر کنترل می کند که آیا کلیدهای GSI AVB به vendor_boot ساخته شده اند.

    • هنگامی که روی true تنظیم شده است ، اگر BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :

      • تنظیم شده است ، کلیدهای GSI AVB به $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb ساخته شده اند.

      • غیرقانونی است ، کلیدهای GSI AVB به $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb ساخته شده اند.

    • وقتی خالی است ، اگر BOARD_RECOVERY_AS_ROOT :

      • تنظیم شده است ، کلیدهای GSI AVB به $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb ساخته شده اند.

      • غیرقانونی است ، کلیدهای GSI AVB به $ANDROID_PRODUCT_OUT/ramdisk/avb ساخته شده اند.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE . این متغیر کنترل می کند که آیا تصویر recovery حاوی هسته است یا خیر. دستگاه هایی که با Android 12 راه اندازی می شوند و با استفاده از پارتیشن recovery A/B باید این متغیر را true تنظیم کنند. دستگاه هایی که با Android 12 راه اندازی می شوند و با استفاده از غیر A/B باید این متغیر را به false تنظیم کنند تا تصویر بازیابی خود به خود حفظ شود.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES . این متغیر کنترل می کند که آیا $OUT/boot*.img در IMAGES/ تحت پرونده های هدف کپی می شود.

    • aosp_arm64 باید این متغیر را بر روی true تنظیم کند.

    • دستگاه های دیگر باید این متغیر را خالی بگذارند.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE . این متغیر کنترل می کند که آیا init_boot.img تولید می شود و اندازه را تعیین می کند. در صورت تنظیم ، RamDisk عمومی به جای boot.img به init_boot.img اضافه می شود و به متغیرهای BOARD_AVB_INIT_BOOT* نیاز دارد تا برای vbmeta زنجیر شده تنظیم شود.

ترکیبات مجاز

مؤلفه یا متغیر دستگاه را بدون پارتیشن بازیابی ارتقا دهید دستگاه را با پارتیشن بازیابی ارتقا دهید دستگاه را بدون پارتیشن بازیابی راه اندازی کنید دستگاه را با پارتیشن بازیابی A/B راه اندازی کنید دستگاه را با پارتیشن بازیابی غیر A/B راه اندازی کنید AOSP_ARM64
حاوی boot است بله بله بله بله بله بله
حاوی init_boot (Android 13) نه نه بله بله بله بله
حاوی vendor_boot است اختیاری اختیاری بله بله بله نه
حاوی recovery نه بله نه بله بله نه
BOARD_USES_RECOVERY_AS_BOOT true خالی خالی خالی خالی خالی
BOARD_USES_GENERIC_KERNEL_IMAGE خالی خالی true true true true
PRODUCT_BUILD_RECOVERY_IMAGE خالی true یا خالی خالی true یا خالی true یا خالی خالی
BOARD_RECOVERYIMAGE_PARTITION_SIZE خالی > 0 خالی > 0 > 0 خالی
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT خالی خالی true خالی خالی خالی
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT خالی خالی true true true خالی
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE خالی خالی خالی true خالی خالی
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES خالی خالی خالی خالی خالی true

دستگاه هایی با یک پارتیشن recovery اختصاصی می توانند PRODUCT_BUILD_RECOVERY_IMAGE به true یا خالی تنظیم کنند. برای این دستگاه ها ، اگر BOARD_RECOVERYIMAGE_PARTITION_SIZE تنظیم شده باشد ، یک تصویر recovery ساخته می شود.

VBMeta زنجیر شده را برای بوت فعال کنید

VBMETA زنجیره ای باید برای تصاویر boot و init_boot فعال شود. موارد زیر را مشخص کنید:

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

برای مثال ، به این تغییر مراجعه کنید.

سیستمرایت

سیستم به عنوان ریشه برای دستگاه هایی که از GKI استفاده می کنند پشتیبانی نمی شود. در چنین دستگاه هایی ، BOARD_BUILD_SYSTEM_ROOT_IMAGE باید خالی باشد. سیستم به عنوان ریشه نیز برای دستگاه هایی که از پارتیشن های پویا استفاده می کنند پشتیبانی نمی شود.

تنظیمات محصول

دستگاه هایی که از RamDisk عمومی استفاده می کنند باید لیستی از پرونده هایی را که مجاز به نصب در Ramdisk هستند ، نصب کنند. برای انجام این کار ، موارد زیر را در device.mk مشخص کنید. mk:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

پرونده generic_ramdisk.mk همچنین مانع از نصب تصادفی سایر فایلهای دیگر در Ramdisk می شود (به جای آن چنین پرونده هایی را به vendor_ramdisk منتقل کنید).

دستگاه ها را تنظیم کنید

دستورالعمل های راه اندازی بین دستگاه های راه اندازی با Android 13 ، ارتقاء به Android 12 و راه اندازی با Android 12. Android 13 ، تنظیم شده است شبیه به نحوه حضور آنها با Android 12

  • دستگاه های ارتقاء به Android 12:

    • می تواند مقدار BOARD_USES_RECOVERY_AS_BOOT را حفظ کند. اگر این کار را انجام دهند ، آنها از پیکربندی های میراث استفاده می کنند و متغیرهای جدید ساخت باید خالی باشد. اگر چنین دستگاه هایی:

      • BOARD_USES_RECOVERY_AS_BOOT را true کنید ، معماری همانطور که در شکل 3 نشان داده شده است.

      • BOARD_USES_RECOVERY_AS_BOOT را تنظیم کنید ، معماری همانطور که شکل 4 نشان داده شده است.

    • می تواند BOARD_USES_RECOVERY_AS_BOOT را خالی کند. اگر این کار را انجام دهند ، آنها از تنظیمات جدید استفاده می کنند. اگر چنین دستگاه هایی:

      • از یک پارتیشن recovery اختصاصی استفاده نکنید ، معماری همانطور که در شکل 1 نشان داده شده است و گزینه تنظیم دستگاه گزینه 1 است.

      • از یک پارتیشن recovery اختصاصی استفاده کنید ، معماری همانطور که در شکل 2A یا شکل 2B نشان داده شده است و گزینه تنظیم دستگاه گزینه 2A یا گزینه 2B است.

  • دستگاه هایی که با Android 12 راه اندازی می شوند باید BOARD_USES_RECOVERY_AS_BOOT را خالی کنند و از پیکربندی های جدید استفاده کنند. اگر چنین دستگاه هایی:

    • از یک پارتیشن recovery اختصاصی استفاده نکنید ، معماری همانطور که در شکل 1 نشان داده شده است و گزینه تنظیم دستگاه گزینه 1 است.

    • از یک پارتیشن recovery اختصاصی استفاده کنید ، معماری همانطور که در شکل 2A یا شکل 2B نشان داده شده است و گزینه تنظیم دستگاه گزینه 2A یا گزینه 2B است.

از آنجا که aosp_arm64 فقط GKI (و نه vendor_boot یا بازیابی) ایجاد می کند ، یک هدف کامل نیست. برای تنظیمات ساخت aosp_arm64 ، به generic_arm64 مراجعه کنید.

گزینه 1: بدون پارتیشن بازیابی اختصاصی

دستگاه های بدون پارتیشن recovery حاوی تصویر boot عمومی در پارتیشن boot است. Ramdisk vendor_boot شامل کلیه منابع بازیابی ، از جمله lib/modules (با ماژول های هسته فروشنده) است. در چنین دستگاه هایی ، پیکربندی محصول از generic_ramdisk.mk به ارث می برد .

مقادیر صفحه را تنظیم کنید

مقادیر زیر را تنظیم کنید:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Ramdisk vendor_boot می تواند حاوی /init /system/bin/init symlink و init_second_stage.recovery at /system/bin/init . با این حال ، از آنجا که ramdisk عمومی پس از vendor_boot amdisk به دست می آید ، Symlink /init بازنویسی می شود. هنگامی که دستگاه به بازیابی می پردازد ، برای پشتیبانی از مرحله دوم ، باینری /system/bin/init ابتکار لازم است. محتوای vendor_boot + ramdisks عمومی به شرح زیر است:

  • /init (از ramdisk عمومی ، ساخته شده از init_first_stage )
  • /system/bin/init (from vendor_ramdisk , built from init_second_stage.recovery )

Move fstab files

Move any fstab files that were installed to the generic ramdisk to vendor_ramdisk . For an example, refer to this change .

ماژول ها را نصب کنید

You can install device-specific modules to vendor_ramdisk (skip this step if you don't have any device-specific modules to install).

  • Use the vendor_ramdisk variant of the module when the module installs to the /first_stage_ramdisk . This module should be available after init switches root into /first_stage_ramdisk but before init switches root into /system . For examples, see Metadata checksums and Virtual A/B compression .

  • Use the recovery variant of the module when the module installs to / . This module should be available before init switches root into /first_stage_ramdisk . For details on installing modules to / , see First stage console .

First stage console

Because the first stage console starts before init switches root into /first_stage_ramdisk , you need to install the recovery variant of modules. By default, both module variants are installed to build/make/target/product/base_vendor.mk , so if the device makefile inherits from that file you don't need to explicitly install the recovery variant.

To explicitly install the recovery modules, use the following.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

This ensures that the linker , sh , and toybox install to $ANDROID_PRODUCT_OUT/recovery/root/system/bin , which then installs to /system/bin under the vendor_ramdisk .

To add modules needed for the first stage console (for example, adbd), use the following.

PRODUCT_PACKAGES += adbd.recovery

This ensures that the specified modules install to $ANDROID_PRODUCT_OUT/recovery/root/system/bin , which then installs to /system/bin under the vendor_ramdisk .

Metadata checksums

To support metadata checksums during first stage mount, devices that don't support GKI install the ramdisk variant of the following modules. To add support for GKI, move the modules to $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin :

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

For an example, refer to this changelist .

Virtual A/B compression

To support virtual A/B compression, snapuserd must be installed to vendor_ramdisk . The device should inherit from virtual_ab_ota/compression.mk , which installs the vendor_ramdisk variant of snapuserd .

Changes to the boot process

The process of booting into recovery or into Android doesn't change, with the following exception:

  • Ramdisk build.prop moves into /second_stage_resources so that second stage init can read the build timestamp of boot.

Because resources move from generic ramdisk to vendor_boot ramdisk, the result of concatenating generic ramdisk to vendor_boot ramdisk doesn't change.

Make e2fsck available

The device makefiles can inherit from:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk if the device supports virtual A/B but not compression.

  • virtual_ab_ota/compression.mk if the device supports virtual A/B compression.

The product makefiles install $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck . At runtime, the first stage init switches root into /first_stage_ramdisk then executes /system/bin/e2fsck .

Option 2a: Dedicated and A/B recovery partition

Use this option for devices with A/B recovery partitions; that is, the device has a recovery_a and recovery_b partition . Such devices include A/B and Virtual A/B devices of which the recovery partition is updateable, with the following configuration:

AB_OTA_PARTITIONS += recovery

The vendor_boot ramdisk contains the vendor bits of the ramdisk and vendor kernel modules, including the following:

  • Device-specific fstab files

  • lib/modules (includes vendor kernel modules)

The recovery ramdisk contains all recovery resources. On such devices, the product configuration inherits from generic_ramdisk.mk .

Set BOARD values

Set the following values for devices with A/B recovery partition:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

The recovery ramdisk can contain an /init -> /system/bin/init symlink, and init_second_stage.recovery at /system/bin/init . However, because the boot ramdisk is concatenated after the recovery ramdisk, the /init symlink is overwritten. When the device boots into recovery mode, the /system/bin/init binary is needed to support second stage init.

When the device boots into recovery , the contents of recovery + vendor_boot + generic ramdisks are as follows:

  • /init (from ramdisk, built from init_first_stage )
  • /system/bin/init (from recovery ramdisk, built from init_second_stage.recovery , and executed from /init )

When the device boots into Android, the contents of vendor_boot + generic ramdisks are as follows:

  • /init (from generic ramdisk, built from init_first_stage )

Move fstab files

Move any fstab files that were installed to the generic ramdisk to the vendor_ramdisk . For an example, refer to this change .

ماژول ها را نصب کنید

Optionally, you can install device-specific modules to vendor_ramdisk (skip this step if you don't have any device-specific modules to install). Init doesn't switch root. The vendor_ramdisk variant of modules installs to the root of vendor_ramdisk . For examples on installing modules to vendor_ramdisk , see First stage console , Metadata checksums , and Virtual A/B compression .

First stage console

To install the vendor_ramdisk variant of the modules, use the following:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

This ensures that the linker , sh , and toybox install to $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , which then installs to /system/bin under the vendor_ramdisk .

To add modules needed for the first stage console (for example, adbd), enable the vendor_ramdisk variant of these modules by uploading relevant patches to AOSP, then use the following, 

PRODUCT_PACKAGES += adbd.vendor_ramdisk

This ensures that the specified modules install to $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin . If the vendor_boot ramdisk is loaded in recovery mode, the module is also available in recovery . If the vendor_boot ramdisk isn't loaded in recovery mode, the device can optionally install adbd.recovery as well.

Metadata checksums

To support metadata checksums during first stage mount, devices that don't support GKI install the ramdisk variant of the following modules. To add support for GKI, move the modules to $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin : 

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

For an example, refer to this changelist .

Virtual A/B compression

To support Virtual A/B compression, snapuserd must be installed to vendor_ramdisk . The device should inherit from virtual_ab_ota/compression.mk , which installs the vendor_ramdisk variant of snapuserd .

Changes to the boot process

When booting into Android, the boot process doesn't change. The vendor_boot + generic ramdisk is similar to the existing boot process, except that fstab loads from vendor_boot . Because system/bin/recovery doesn't exist, first_stage_init handles it as a normal boot.

When booting into recovery mode, the boot process changes. The recovery + vendor_boot + generic ramdisk is similar to the existing recovery process, but the kernel is loaded from the boot image instead of from the recovery image. The boot process for recovery mode is as follows.

  1. Bootloader starts, then does the following:

    1. Pushes recovery + vendor_boot + generic ramdisk to / . (If the OEM duplicates kernel modules in recovery ramdisk by adding them to BOARD_RECOVERY_KERNEL_MODULES ), vendor_boot is optional.)
    2. Runs the kernel from the boot partition.

  2. Kernel mounts ramdisk to / then executes /init from the generic ramdisk.

  3. First stage init starts, then does the following:

    1. Sets IsRecoveryMode() == true and ForceNormalBoot() == false .
    2. Loads vendor kernel modules from /lib/modules .
    3. Calls DoFirstStageMount() but skips mounting because IsRecoveryMode() == true . (The device doesn't free ramdisk (because / is still the same) but does call SetInitAvbVersionInRecovery() .)
    4. Starts second stage init from /system/bin/init from recovery ramdisk.

Make e2fsck available

The device makefiles can inherit from:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk if the device supports virtual A/B but not compression.

  • virtual_ab_ota/compression.mk if the device supports virtual A/B compression.

The product makefiles install $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck . At runtime, the first stage init executes /system/bin/e2fsck .

Option 2b: Dedicated and non-A/B recovery partition

Use this option for devices with a non-A/B recovery partition; that is, the device has a partition named recovery without a slot suffix. چنین دستگاه هایی عبارتند از:

  • non-A/B devices;
  • A/B and Virtual A/B devices, of which the recovery partition isn't updateable. (This is unusual.)

The vendor_boot ramdisk contains the vendor bits of the ramdisk and vendor kernel modules, including the following:

  • Device-specific fstab files
  • lib/modules (includes vendor kernel modules)

The recovery image must be self-contained. It must contain all required resources to boot the recovery mode, including:

  • The kernel image
  • The DTBO image
  • Kernel modules in lib/modules
  • First-stage init as a symlink /init -> /system/bin/init
  • Second-stage init binary /system/bin/init
  • Device-specific fstab files
  • All other recovery resources, including the recovery binary

On such devices, the product configuration inherits from generic_ramdisk.mk .

Set BOARD values

Set the following values for non-A/B devices: 

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

The recovery ramdisk must contain an /init -> /system/bin/init symlink, and init_second_stage.recovery at /system/bin/init . When the device boots into recovery mode, the /system/bin/init binary is needed to support both first stage and second stage init.

When the device boots into recovery , the contents of recovery ramdisks are as follows:

  • /init -> /system/bin/init (from recovery ramdisk)
  • /system/bin/init (from recovery ramdisk, built from init_second_stage.recovery , and executed from /init )

When the device boots into Android, the contents of vendor_boot + generic ramdisks are as follows:

  • /init (from ramdisk, built from init_first_stage )

Move fstab files

Move any fstab files that were installed to the generic ramdisk to the vendor_ramdisk and recovery ramdisk. For an example, refer to this change .

ماژول ها را نصب کنید

You can install device-specific modules to vendor_ramdisk and recovery ramdisk (skip this step if you don't have any device-specific modules to install). init doesn't switch root. The vendor_ramdisk variant of modules installs to the root of vendor_ramdisk . The recovery variant of modules installs to the root of recovery ramdisk. For examples on installing modules to vendor_ramdisk and recovery ramdisk, se First stage console and Metadata checksums .

First stage console

To install the vendor_ramdisk variant of the modules, use the following: 

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

This ensures that the linker , sh , and toybox install to $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , which then installs to /system/bin under the vendor_ramdisk .

To add modules needed for the first stage console (for example, adbd), enable the vendor_ramdisk variant of these modules by uploading relevant patches to AOSP, then use the following, 

PRODUCT_PACKAGES += adbd.vendor_ramdisk

This ensures that the specified modules install to $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin .

To install the recovery variant of the modules, replace vendor_ramdisk with recovery : 

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

Metadata checksums

To support metadata checksums during first stage mount, devices that don't support GKI install the ramdisk variant of the following modules. To add support for GKI, move the modules to $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin : 

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

To support metadata checksums during first stage mount in recovery, enable the recovery variant of these modules and install them as well.

Changes to the boot process

When booting into Android, the boot process doesn't change. The vendor_boot + generic ramdisk is similar to the existing boot process, except that fstab loads from vendor_boot . Because system/bin/recovery doesn't exist, first_stage_init handles it as a normal boot.

When booting into recovery mode, the boot process doesn't change. The recovery ramdisk is loaded in the same way as the existing recovery process. The kernel is loaded from the recovery image. The boot process for recovery mode is as follows.

  1. Bootloader starts, then does the following:

    1. Pushes recovery ramdisk to / .
    2. Runs the kernel from the recovery partition.

  2. Kernel mounts ramdisk to / then executes /init , which is a symlink to /system/bin/init from the recovery ramdisk.

  3. First stage init starts, then does the following:

    1. Sets IsRecoveryMode() == true and ForceNormalBoot() == false .
    2. Loads vendor kernel modules from /lib/modules .
    3. Calls DoFirstStageMount() but skips mounting because IsRecoveryMode() == true . (The device doesn't free ramdisk (because / is still the same) but does call SetInitAvbVersionInRecovery() .)
    4. Starts second stage init from /system/bin/init from recovery ramdisk.

Boot image timestamps

The following code is an example boot image timestamp file: 

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

  • At build time, a system/etc/ramdisk/build.prop file is added to the generic ramdisk. This file contains timestamp information of the build.

  • At runtime, first stage init copies files from the ramdisk to tmpfs before freeing the ramdisk so that second stage init can read this file to set boot image timestamp properties.