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

در اندروید ۱۲، تصویر boot عمومی که به آن تصویر هسته عمومی (GKI) گفته می‌شود، شامل ramdisk عمومی و هسته GKI است.

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

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

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

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

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

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

معماری

نمودارهای زیر معماری دستگاه‌هایی که اندروید ۱۲ و بالاتر را اجرا می‌کنند را نشان می‌دهند. دستگاه‌هایی که با اندروید ۱۳ راه‌اندازی می‌شوند، یک ایمیج init_boot جدید دارند که حاوی ramdisk عمومی است. دستگاه‌هایی که از اندروید ۱۲ به اندروید ۱۳ ارتقا می‌یابند، از همان معماری اندروید ۱۲ استفاده می‌کنند.

با اندروید ۱۳ اجرا می‌شود، بدون ریکاوری اختصاصی

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

شکل ۱. دستگاه‌هایی که در حال راه‌اندازی یا ارتقاء به اندروید ۱۳ هستند، با GKI، بدون بازیابی اختصاصی.

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

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

شکل ۲. دستگاه‌هایی که در حال راه‌اندازی یا ارتقاء به اندروید ۱۳ هستند، با GKI اختصاصی و بازیابی A/B.

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

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

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

شکل ۳. دستگاه‌هایی که در حال راه‌اندازی یا ارتقاء به اندروید ۱۳ هستند، با GKI، بازیابی اختصاصی و غیر A/B.

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

راه‌اندازی یا ارتقا به اندروید ۱۲، بدون نیاز به ریکاوری اختصاصی

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

شکل ۴. دستگاه‌هایی که در حال راه‌اندازی یا ارتقاء به اندروید ۱۲ هستند، با GKI، بدون بازیابی اختصاصی.

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

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

شکل ۵. دستگاه‌هایی که در حال راه‌اندازی یا ارتقاء به اندروید ۱۲ هستند، با GKI اختصاصی و بازیابی A/B.

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

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

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

شکل ۶. دستگاه‌هایی که در حال راه‌اندازی یا ارتقاء به اندروید ۱۲ هستند، با GKI، بازیابی اختصاصی و غیر A/B.

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

ارتقا به اندروید ۱۲، بازیابی هنگام بوت (بازیابی به عنوان رم دیسک)

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

شکل ۷. دستگاه‌های در حال ارتقا به اندروید ۱۲، بدون GKI، بازیابی هنگام بوت.

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

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

شکل ۸. دستگاه‌های در حال ارتقا به اندروید ۱۲، بدون GKI، بازیابی اختصاصی.

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

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

  • ایمیج init_boot برای دستگاه‌هایی که با اندروید ۱۳ عرضه می‌شوند اضافه شد

    • نسخه هدر V4
    • ایمیج عمومی رم‌دیسک

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

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

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

    • هدر vendor_boot
      • cmdline مخصوص دستگاه ( BOARD_KERNEL_CMDLINE )
    • ایمیج ramdisk vendor_boot
      • 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، عبارت recovery ramdisk به صورت پیش‌فرض به generic و vendor_boot ramdisk اضافه شده است، از این رو نیازی به مستقل بودن ندارد. برای مثال:
      • lib/modules ممکن است علاوه بر ماژول‌های هسته در vendor_boot ramdisk، فقط شامل ماژول‌های هسته اضافی مورد نیاز برای راه‌اندازی حالت بازیابی باشد.
      • ممکن است پیوند نمادین در /init وجود داشته باشد، اما توسط فایل باینری مرحله اول /init در تصویر بوت، تحت الشعاع قرار گرفته است.

محتویات عمومی تصویر رم‌دیسک

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

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

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

پرچم‌های ساخت، نحوه ساخت ایمیج‌های init_boot ، boot ، recovery و vendor_boot را کنترل می‌کنند. مقدار یک متغیر boolean board باید رشته 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 حاوی هسته است یا خیر. دستگاه‌هایی که با اندروید ۱۲ راه‌اندازی می‌شوند و از پارتیشن recovery A/B استفاده می‌کنند باید این متغیر را روی true تنظیم کنند. دستگاه‌هایی که با اندروید ۱۲ راه‌اندازی می‌شوند و از پارتیشن‌های غیر 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 (اندروید ۱۳) است خیر خیر بله بله بله بله
شامل 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 یا empty تنظیم کنند. برای این دستگاه‌ها، اگر 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 همچنین از نصب تصادفی فایل‌های دیگر توسط makefileها روی ramdisk جلوگیری می‌کند (به جای آن، چنین فایل‌هایی را به vendor_ramdisk منتقل کنید).

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

دستورالعمل‌های راه‌اندازی بین دستگاه‌هایی که با اندروید ۱۳ راه‌اندازی می‌شوند، دستگاه‌هایی که به اندروید ۱۲ ارتقا می‌دهند و دستگاه‌هایی که با اندروید ۱۲ راه‌اندازی می‌شوند، متفاوت است. اندروید ۱۳، تنظیماتی مشابه با اندروید ۱۲ دارد.

  • دستگاه‌هایی که به اندروید ۱۲ ارتقا می‌یابند:

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

      • مقدار BOARD_USES_RECOVERY_AS_BOOT را روی true تنظیم کنید، معماری مطابق شکل ۳ خواهد بود.

      • مقدار BOARD_USES_RECOVERY_AS_BOOT را روی خالی تنظیم کنید، معماری مطابق شکل ۴ است.

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

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

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

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

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

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

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

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

دستگاه‌هایی که پارتیشن recovery ندارند، حاوی فایل ایمیج boot عمومی در پارتیشن boot هستند. فایل vendor_boot ramdisk شامل تمام منابع ریکاوری، از جمله 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 رونویسی می‌شود. هنگامی که دستگاه به حالت بازیابی بوت می‌شود، برای پشتیبانی از 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 ریشه را به /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 را نصب می‌کند.

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

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

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

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

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 را اجرا می‌کند.

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

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

AB_OTA_PARTITIONS += recovery

فایل vendor_boot ramdisk شامل بیت‌های vendor مربوط به ماژول‌های 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

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

وقتی دستگاه در حالت recovery بوت می‌شود، محتویات recovery + vendor_boot + generic ramdisks به شرح زیر است:

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

وقتی دستگاه در اندروید بوت می‌شود، محتویات vendor_boot + generic 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 نصب شوند. اگر vendor_boot ramdisk در حالت ریکاوری بارگذاری شده باشد، ماژول نیز در recovery موجود است. اگر vendor_boot ramdisk در حالت ریکاوری بارگذاری نشده باشد، دستگاه می‌تواند به صورت اختیاری 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 + generic ramdisk مشابه فرآیند بوت موجود است، با این تفاوت که fstab از vendor_boot بارگذاری می‌شود. از آنجا که system/bin/recovery وجود ندارد، first_stage_init آن را به عنوان یک بوت معمولی مدیریت می‌کند.

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

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

    1. recovery + vendor_boot + generic ramdisk را به / منتقل می‌کند. (اگر تولیدکننده اصلی (OEM) ماژول‌های هسته را با اضافه کردن آنها به BOARD_RECOVERY_KERNEL_MODULES در recovery 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 مرحله اول init /system/bin/e2fsck را اجرا می‌کند.

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

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

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

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

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

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

  • تصویر هسته
  • تصویر DTBO
  • ماژول‌های هسته در lib/modules
  • init مرحله اول به عنوان یک پیوند نمادین /init -> /system/bin/init
  • فایل باینری /system/bin/init مرحله دوم 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

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

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

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

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

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

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

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

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

شما می‌توانید ماژول‌های مخصوص دستگاه را در vendor_ramdisk و recovery ramdisk نصب کنید (اگر هیچ ماژول مخصوص دستگاهی برای نصب ندارید، از این مرحله صرف نظر کنید). init به ریشه تغییر نمی‌کند. نوع vendor_ramdisk ماژول‌ها در ریشه vendor_ramdisk نصب می‌شود. نوع recovery ماژول‌ها در ریشه recovery ramdisk نصب می‌شود. برای مثال در مورد نصب ماژول‌ها در 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 + generic ramdisk مشابه فرآیند بوت موجود است، با این تفاوت که fstab از vendor_boot بارگذاری می‌شود. از آنجا که system/bin/recovery وجود ندارد، first_stage_init آن را به عنوان یک بوت معمولی مدیریت می‌کند.

هنگام بوت شدن در حالت ریکاوری، فرآیند بوت تغییر نمی‌کند. رم‌دیسک ریکاوری به همان روشی که فرآیند ریکاوری موجود است، بارگذاری می‌شود. هسته از فایل ایمیج 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 مرحله دوم بتواند این فایل را بخواند تا ویژگی‌های برچسب زمانی تصویر boot را تنظیم کند.