پارتیشن راه‌اندازی عمومی

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

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

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

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

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

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

  • از افراز اختصاصی recovery استفاده کنید، نیازی به تغییر در ramdisk recovery نیست زیرا ramdisk recovery خودکفا است.

معماری

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

با Android 13 عرضه می‌شود، بازیابی اختصاصی ندارد

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

شکل ۱. دستگاه‌هایی که با Android 13 عرضه می‌شوند یا به آن ارتقا می‌یابند، با GKI، بدون بازیابی اختصاصی.

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

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

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

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

عرضه‌شده با Android 13، بازیابی اختصاصی و غیر A/B (دیسک مجازی اختصاصی)

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

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

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

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

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

شکل ۴. دستگاه‌هایی که با Android 12 عرضه می‌شوند یا به آن ارتقا می‌یابند، با GKI، بدون بازیابی اختصاصی.

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

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

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

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

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

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

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

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

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

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

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

به Android 12 ارتقا دهید، بازیابی اختصاصی (رام‌دیسک اختصاصی)

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

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

محتوای تصاویر راه‌اندازی

تصاویر راه‌اندازی Android شامل موارد زیر است.

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

    • نسخه سرایند V4
    • تصویر دیسک حافظه عمومی

  • تصویر کلی boot

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

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

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

محتوای تصویر 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 نسخه ۱۲ عرضه می‌شوند و از پارتیشن A/B recovery استفاده می‌کنند باید این متغیر را روی 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 تولید شود و اندازه آن را تنظیم می‌کند. وقتی تنظیم شود، دیسک مجازی عمومی به‌جای boot.img به init_boot.img اضافه می‌شود و لازم است متغیرهای BOARD_AVB_INIT_BOOT* برای vbmeta زنجیره‌ای تنظیم شوند.

ترکیب‌های مجاز

مؤلفه یا متغیر ارتقا دادن دستگاه بدون پارتیشن بازیابی ارتقا دادن دستگاه با پارتیشن بازیابی راه‌اندازی دستگاه بدون پارتیشن بازیابی راه‌اندازی دستگاه با پارتیشن بازیابی A/B راه‌اندازی دستگاه با پارتیشن بازیابی غیر A/B aosp_arm64
حاوی boot بله بله بله بله بله بله
حاوی init_boot (Android 13) no no بله بله بله بله
حاوی vendor_boot اختیاری اختیاری بله بله بله no
حاوی recovery no بله no بله بله no
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 به‌شدت توصیه می‌شود تا OTA مستقل امکان‌پذیر شود. موارد زیر را مشخص کنید:

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 باید خالی باشد. ‫System-as-root برای دستگاه‌هایی که از پارتیشن‌های پویا استفاده می‌کنند نیز پشتیبانی نمی‌شود.

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

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

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

فایل generic_ramdisk.mk همچنین از نصب تصادفی فایل‌های دیگر در ramdisk توسط فایل‌های makefile دیگر جلوگیری می‌کند (این فایل‌ها را به‌جای آن به 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 تنظیم کنید، معماری همان‌طور که در شکل ۳ نشان داده شده است.

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

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

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

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

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

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

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

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

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

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

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

  • ‫/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 ریشه را به /system تغییر دهد دردسترس باشد. برای مثال، مجموع‌های وارسی فراداده و فشرده‌سازی مجازی A/B را ببینید.

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

تغییرات در فرایند راه‌اندازی

فرایند راه‌اندازی در حالت بازیابی یا در Android تغییر نمی‌کند، با استثنای زیر:

  • ‫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 ریشه را به /first_stage_ramdisk تغییر می‌دهد سپس /system/bin/e2fsck را اجرا می‌کند.

گزینه ۲الف: پارتیشن بازیابی اختصاصی و آ/ب

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

AB_OTA_PARTITIONS += recovery

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

  • ‫fstab فایل ویژه دستگاه

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

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

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

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

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 باشد، و init_second_stage.recovery در /system/bin/init. بااین‌حال، چون ramdisk بوت پس‌از ramdisk recovery به‌هم متصل می‌شود، پیوند نمادین /init بازنویسی می‌شود. وقتی دستگاه در حالت بازیابی راه‌اندازی می‌شود، برای پشتیبانی از مقداردهی اولیه مرحله دوم، به باینری /system/bin/init نیاز است.

وقتی دستگاه با recovery راه‌اندازی می‌شود، محتویات recovery + vendor_boot + ramdisk عمومی به‌صورت زیر است:

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

وقتی دستگاه در Android راه‌اندازی می‌شود، محتوای 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 نصب شوند. اگر vendor_boot ramdisk در حالت بازیابی بارگیری شود، واحد در recovery نیز دردسترس است. اگر vendor_boot ramdisk در حالت بازیابی بار نشود، دستگاه می‌تواند به‌طور اختیاری adbd.recovery را نیز نصب کند.

مجموع‌های وارسی فراداده

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

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

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

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

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

تغییرات در فرایند راه‌اندازی

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

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

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

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

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

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

    1. ‫IsRecoveryMode() == true و ForceNormalBoot() == false را تنظیم می‌کند.
    2. واحدهای هسته فروشنده را از /lib/modules بار می‌کند.
    3. DoFirstStageMount() را فراخوانی می‌کند اما از سوار کردن رد می‌شود زیرا IsRecoveryMode() == true. (دستگاه ramdisk را آزاد نمی‌کند (زیرا / همچنان یکسان است) اما SetInitAvbVersionInRecovery() را فراخوانی می‌کند.)
    4. راه‌اندازی مرحله دوم از /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 را اجرا می‌کند.

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

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

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

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

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

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

  • تصویر هسته
  • تصویر DTBO
  • واحدهای هسته در lib/modules
  • راه‌اندازی مرحله اول به‌عنوان پیوند نمادین /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 باید حاوی پیوند نمادین /init -> /system/bin/init و init_second_stage.recovery در /system/bin/init باشد. وقتی دستگاه در حالت بازیابی راه‌اندازی می‌شود، برای پشتیبانی از مقداردهی اولیه مرحله اول و مرحله دوم، به باینری /system/bin/init نیاز است.

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

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

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

  • /init (از دیسک حافظه، ساخته‌شده از init_first_stage)

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

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

نصب واحدها

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

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

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

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

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

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

    1. ‫IsRecoveryMode() == true و ForceNormalBoot() == false را تنظیم می‌کند.
    2. واحدهای هسته فروشنده را از /lib/modules بار می‌کند.
    3. DoFirstStageMount() را فراخوانی می‌کند اما از سوار کردن رد می‌شود زیرا IsRecoveryMode() == true. (دستگاه ramdisk را آزاد نمی‌کند (زیرا / همچنان یکسان است) اما SetInitAvbVersionInRecovery() را فراخوانی می‌کند.)
    4. راه‌اندازی مرحله دوم از /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 به دیسک مجازی عمومی اضافه می‌شود. این فایل حاوی اطلاعات مُهر زمان ساخت است.

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