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

در اندروید 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 مستقل است.

معماری

نمودارهای زیر معماری دستگاه‌های دارای Android 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. دستگاه‌هایی که به Android 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 زنجیره ای تنظیم شوند.

ترکیبات مجاز

جزء یا متغیر ارتقای دستگاه بدون پارتیشن recovery ارتقا دستگاه با پارتیشن recovery راه اندازی دستگاه بدون پارتیشن recovery دستگاه را با پارتیشن recovery A/B راه اندازی کنید دستگاه را با پارتیشن recovery غیر 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 توسط سایر فایل‌ها جلوگیری می‌کند (به جای آن چنین فایل‌هایی را به 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 root را به /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 عمومی به vendor_boot ramdisk منتقل می شوند، نتیجه الحاق 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 را اجرا می کند.

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

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