قسم التمهيد العام

في نظام التشغيل Android 12، تحتوي صورة boot العامة، والتي يُشار إليها باسم صورة النواة العامة (GKI)، على ملف ramdisk العام ونواة GKI.

في الأجهزة التي تعمل بنظام التشغيل Android 13، تتم إزالة ramdisk العام من صورة boot ووضعه في صورة init_boot منفصلة. سيؤدي هذا التغيير إلى أن تحتوي صورة boot على نواة GKI فقط.

بالنسبة إلى ترقية الأجهزة التي تواصل استخدام الإصدار 12 من نظام التشغيل Android أو إصدارات أقدم من النواة، يظل ملف ramdisk العام في مكانه بدون الحاجة إلى صورة init_boot جديدة.

لإنشاء ملف ramdisk عام، يجب نقل الموارد الخاصة بالمورّد خارج ملف ramdisk، بحيث لا يحتوي ملف ramdisk العام إلا على init في المرحلة الأولى وملف خصائص يحتوي على معلومات الطوابع الزمنية.

على الأجهزة التي:

  • لا تستخدِم قسم recovery مخصّصًا، بل يتم نقل جميع وحدات الاسترداد من ملف ramdisk العام إلى ملف ramdisk vendor_boot.

  • استخدِم قسم recovery مخصّصًا، ولن تحتاج إلى إجراء أي تغيير في recovery ramdisk لأنّ recovery ramdisk مستقل.

هندسة معمارية

توضّح المخططات التالية بنية الأجهزة التي تعمل بالإصدار 12 من نظام التشغيل Android والإصدارات الأحدث. تتضمّن الأجهزة التي تعمل بالإصدار 13 من نظام التشغيل Android صورة init_boot جديدة تحتوي على ملف ramdisk العام. تستخدم الأجهزة التي تمت ترقيتها من Android 12 إلى Android 13 البنية نفسها التي كانت تستخدمها مع Android 12.

إطلاق الجهاز باستخدام Android 13 بدون وضع استرداد مخصّص

إطلاق/ترقية الجهاز، وواجهة GKI، وعدم توفّر وضع استرداد مخصّص

الشكل 1: الأجهزة التي يتم طرحها أو ترقيتها إلى Android 13، مع توفّر GKI، بدون وضع استرداد مخصّص

الإطلاق باستخدام Android 13، مع إمكانية إجراء عملية استرداد مخصّصة واختبار A/B (قرص RAM مخصّص)

تشغيل/ترقية الجهاز، وGKI، والاسترداد المخصّص والاسترداد باستخدام تقسيم A/B

الشكل 2: الأجهزة التي يتم طرحها أو ترقيتها إلى الإصدار 13 من نظام التشغيل Android، والتي تتضمّن GKI، ووضعَي الاسترداد المخصّص وA/B

راجِع هذا الشكل إذا كان الجهاز يحتوي على قسمَي recovery_a وrecovery_b.

الإطلاق مع نظام التشغيل Android 13، وإمكانية الاسترداد المخصّص وغير A/B (قرص RAM مخصّص)

تشغيل/ترقية الجهاز، وGKI، والاسترداد المخصّص وغير A/B

الشكل 3: الأجهزة التي يتم طرحها أو ترقيتها إلى الإصدار 13 من نظام التشغيل Android، والتي تتضمّن GKI، ووضع الاسترداد المخصّص وغير A/B

راجِع هذا الشكل إذا كان الجهاز يحتوي على قسم باسم recovery بدون لاحقة فتحة.

تشغيل الإصدار 12 من نظام التشغيل Android أو الترقية إليه، بدون إمكانية استرداد مخصّصة

إطلاق/ترقية الجهاز، وواجهة GKI، وعدم توفّر وضع استرداد مخصّص

الشكل 4. الأجهزة التي يتم طرحها أو ترقيتها إلى Android 12، مع GKI، بدون وضع استرداد مخصّص

تشغيل Android 12 أو الترقية إليه، واسترداد البيانات المخصّص واسترداد البيانات باستخدام اختبار A/B (قرص RAM مخصّص)

تشغيل/ترقية الجهاز، وGKI، والاسترداد المخصّص والاسترداد باستخدام تقسيم A/B

الشكل 5. الأجهزة التي يتم طرحها أو ترقيتها إلى Android 12، والتي تتضمّن GKI، ووضع الاسترداد المخصّص، ووضع الاسترداد A/B

راجِع هذا الشكل إذا كان الجهاز يحتوي على قسمَي recovery_a وrecovery_b.

تشغيل الإصدار 12 من نظام التشغيل Android أو الترقية إليه، واسترداد البيانات المخصّص وغير A/B (ملف ramdisk مخصّص)

تشغيل/ترقية الجهاز، وGKI، والاسترداد المخصّص وغير A/B

الشكل 6. الأجهزة التي يتم طرحها أو ترقيتها إلى Android 12، والتي تتضمّن واجهة GKI، ووضع الاسترداد المخصّص وغير A/B

راجِع هذا الشكل إذا كان الجهاز يحتوي على قسم باسم recovery بدون لاحقة فتحة.

الترقية إلى Android 12، ميزة "الاسترداد كتمهيد" (الاسترداد كقرص RAM)

تشغيل/ترقية الجهاز، بدون GKI، استرداد كعملية تمهيد

الشكل 7. الأجهزة التي تتم ترقيتها إلى Android 12، بدون GKI، واستعادة البيانات عند إعادة التشغيل

الترقية إلى Android 12، وضع الاسترداد المخصّص (ملف ramdisk مخصّص)

تشغيل/ترقية الجهاز، بدون GKI، وضع استرداد مخصّص

الشكل 8. الأجهزة التي تتم ترقيتها إلى Android 12، بدون GKI، مع توفّر قسم مخصّص للاسترداد

محتوى صور التشغيل

تحتوي صور تمهيد Android على ما يلي:

  • تمت إضافة صورة init_boot للأجهزة التي سيتم طرحها مع نظام التشغيل Android 13

    • إصدار العنوان V4
    • صورة ramdisk عامة

  • صورة boot عامة

    • إصدار العنوان V3 أو V4
      • boot_signature لشهادة اعتماد GKI boot.img (الإصدار 4 فقط) لم يتم توقيع نواة GKI المعتمَدة boot.img لعملية "التشغيل المتحقَّق منه". سيظل على المصنّعين الأصليين للأجهزة توقيع boot.img المُنشأ مسبقًا باستخدام مفتاح AVB خاص بالجهاز.
      • cmdline عام (GENERIC_KERNEL_CMDLINE)
      • نواة GKI
    • صورة ramdisk عامة
      • يتم تضمينها فقط في صور boot من الإصدار 12 من نظام التشغيل Android والإصدارات الأقدم

  • vendor_boot صورة (للحصول على التفاصيل، يُرجى الاطّلاع على أقسام التشغيل الخاصة بالمورّد)

    • vendor_boot header
      • cmdline خاص بالجهاز (BOARD_KERNEL_CMDLINE)
    • vendor_boot صورة ramdisk
      • lib/modules
      • مراجع الاسترداد (في حال عدم توفّر عملية استرداد مخصّصة)
    • صورة واحدة (dtb)

  • صورة واحدة (recovery)

    • الإصدار الثاني من العنوان
      • cmdline خاص بالجهاز لاسترداد البيانات، إذا لزم الأمر
      • بالنسبة إلى قسم الاسترداد غير A/B، يجب أن تكون محتويات العنوان مستقلة، راجِع صور الاسترداد. على سبيل المثال:
      • لا يتم ربط cmdline بـ boot وvendor_boot cmdline.
      • يحدّد العنوان قسم DTBO للاسترداد، إذا لزم الأمر.
      • بالنسبة إلى قسم الاسترداد A/B، يمكن ربط المحتويات أو استنتاجها من boot وvendor_boot. على سبيل المثال:
      • يتم ربط cmdline بـ boot وvendor_boot cmdline.
      • يمكن استنتاج DTBO من عنوان vendor_boot.
    • recovery صورة ramdisk
      • مراجع حول التعافي
      • بالنسبة إلى قسم الاسترداد غير A/B، يجب أن تكون محتويات ramdisk مستقلة، ويُرجى الاطّلاع على صور الاسترداد. على سبيل المثال:
      • يجب أن يحتوي lib/modules على جميع وحدات النواة المطلوبة لتشغيل وضع الاسترداد
      • يجب أن يحتوي ملف ramdisk الخاص باسترداد البيانات على init.
      • بالنسبة إلى قسم الاسترداد A/B، يتم إلحاق قرص RAM للاسترداد بقرص RAM العام وقرص RAM 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:

      • إذا تم ضبطها، يتم إنشاء مفاتيح AVB الخاصة بحزمة GSI لتكون $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb.

      • إذا لم يتم ضبطها، يتم إنشاء مفاتيح AVB الخاصة بحِزم GSI الثنائية على $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.

    • عندما يكون الحقل فارغًا، إذا كان BOARD_RECOVERY_AS_ROOT:

      • إذا تم ضبطها، يتم إنشاء مفاتيح AVB الخاصة بحزمة GSI لتكون $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb.

      • إذا لم يتم ضبطها، يتم إنشاء مفاتيح AVB الخاصة بحِزم GSI الثنائية على $ANDROID_PRODUCT_OUT/ramdisk/avb.

  • ‫BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE: يتحكّم هذا المتغيّر في ما إذا كانت صورة recovery تحتوي على نواة أم لا. يجب أن تضبط الأجهزة التي تعمل بالإصدار 12 من نظام التشغيل Android وتستخدم قسم 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 ويضبط الحجم. عند ضبطها، تتم إضافة قرص RAM عام إلى init_boot.img بدلاً من boot.img، ويتطلّب ذلك ضبط المتغيرات BOARD_AVB_INIT_BOOT* من أجل vbmeta المتسلسلة.

المجموعات المسموح بها

المكوّن أو المتغيّر ترقية الجهاز بدون قسم الاسترداد ترقية الجهاز باستخدام قسم الاسترداد تشغيل الجهاز بدون قسم الاسترداد تشغيل الجهاز باستخدام قسم الاسترداد A/B إطلاق جهاز مزوّد بقسم استرداد غير A/B aosp_arm64
تحتوي على boot نعم نعم نعم نعم نعم نعم
يتضمّن init_boot (الإصدار 13 من نظام التشغيل Android) لا لا نعم نعم نعم نعم
تحتوي على 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 أيضًا ملفات makefile الأخرى من تثبيت ملفات أخرى في 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 مخصّصًا، وستكون البنية كما هو موضّح في الشكل 2أ أو الشكل 2ب، وسيكون خيار إعداد الجهاز هو الخيار 2أ أو الخيار 2ب.

  • يجب أن تضبط الأجهزة التي تعمل بالإصدار 12 من نظام التشغيل Android قيمة BOARD_USES_RECOVERY_AS_BOOT على فارغة وأن تستخدم إعدادات جديدة. في حال توفّر هذه الأجهزة:

    • لا تستخدِم قسم recovery مخصّصًا، ويكون التصميم كما هو موضّح في الشكل 1، ويكون خيار إعداد الجهاز هو الخيار 1.

    • استخدِم قسم recovery مخصّصًا، ويجب أن تكون البنية كما هو موضّح في الشكل 2أ أو الشكل 2ب، وأن يكون خيار إعداد الجهاز هو الخيار 2أ أو الخيار 2ب.

وبما أنّ aosp_arm64 لا ينشئ سوى GKI (وليس vendor_boot أو عملية الاسترداد)، فهو ليس هدفًا كاملاً. للاطّلاع على aosp_arm64إعدادات الإنشاء، يُرجى الرجوع إلى generic_arm64.

الخيار 1: عدم توفّر قسم مخصّص للاسترداد

تحتوي الأجهزة التي لا تتضمّن قسم recovery على صورة boot عامة في قسم boot. يحتوي vendor_boot ramdisk على جميع موارد الاسترداد، بما في ذلك lib/modules (مع وحدات kernel الخاصة بالمورّد). على هذه الأجهزة، تتضمّن إعدادات المنتج 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

يمكن أن يحتوي vendor_boot ramdisk على رابط رمزي من /init إلى /system/bin/init، وinit_second_stage.recovery في /system/bin/init. ومع ذلك، بما أنّ ramdisk العام يتم ربطه بعد ramdisk vendor_boot، يتم استبدال الرابط الرمزي /init. عندما يتم تشغيل الجهاز في وضع الاسترداد، يجب توفُّر ملف /system/bin/init الثنائي لدعم عملية التهيئة في المرحلة الثانية. في ما يلي محتويات vendor_boot بالإضافة إلى أقراص RAM العامة:

  • ‫/init (من ملف ramdisk العام، تم إنشاؤه من init_first_stage)
  • /system/bin/init (من vendor_ramdisk، تم إنشاؤه من init_second_stage.recovery)

نقل ملفات fstab

انقل أي ملفات fstab تم تثبيتها في ملف ramdisk العام إلى vendor_ramdisk. للاطّلاع على مثال، يُرجى الرجوع إلى هذا التغيير.

تثبيت الوحدات

يمكنك تثبيت وحدات خاصة بالجهاز على vendor_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، ثم تثبيت $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.

التغييرات في عملية التشغيل

لا تتغيّر عملية التشغيل في وضع الاسترداد أو في نظام التشغيل Android، باستثناء ما يلي:

  • يتم نقل Ramdisk build.prop إلى /second_stage_resources حتى يتمكّن init من قراءة الطابع الزمني لإنشاء عملية التشغيل.

وبما أنّ الموارد تنتقل من ملف ramdisk العام إلى ملف ramdisk الخاص بـ vendor_boot، لن تتغير نتيجة ربط ملف ramdisk العام بملف ramdisk الخاص بـ vendor_boot.

إتاحة e2fsck

يمكن أن تستند ملفات makefile الخاصة بالأجهزة إلى ما يلي:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk إذا كان الجهاز يتيح تقسيم A/B الافتراضي ولكنّه لا يتيح الضغط

  • ‫virtual_ab_ota/compression.mk إذا كان الجهاز يتيح ضغط A/B الافتراضي.

تثبِّت ملفات makefile الخاصة بالمنتج $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck. أثناء وقت التشغيل، تحوّل المرحلة الأولى init الجذر إلى /first_stage_ramdisk ثم تنفّذ /system/bin/e2fsck.

الخيار 2(أ): قسم مخصّص للاسترداد وقسم اختبار A/B

استخدِم هذا الخيار للأجهزة التي تحتوي على أقسام recovery A/B، أي أنّ الجهاز يحتوي على recovery_a وrecovery_b partition. تشمل هذه الأجهزة أجهزة A/B وأجهزة Virtual A/B التي يمكن تحديث قسم الاسترداد فيها، وذلك باستخدام الإعدادات التالية:

AB_OTA_PARTITIONS += recovery

يحتوي vendor_boot ramdisk على أجزاء البائع من ramdisk ووحدات kernel الخاصة بالبائع، بما في ذلك ما يلي:

  • ملفات fstab خاصة بالجهاز

  • ‫lib/modules (بما في ذلك وحدات kernel الخاصة بالمورّد)

يحتوي recovery ramdisk على جميع موارد الاسترداد. على هذه الأجهزة، تتضمّن إعدادات المنتج 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 ramdisk على /init -> /system/bin/init symlink، وinit_second_stage.recovery في /system/bin/init. ومع ذلك، بما أنّ ramdisk الخاص بعملية التشغيل يتم ربطه بعد ramdisk الخاص بـ recovery، تتم الكتابة فوق الرابط الرمزي /init. عندما يتم تشغيل الجهاز في وضع الاسترداد (Recovery mode)، يجب توفُّر /system/bin/init برنامج ثنائي لدعم عملية التهيئة في المرحلة الثانية.

عندما يتم تشغيل الجهاز في recovery، تكون محتويات recovery وvendor_boot ومساحات التخزين المؤقت للذاكرة العشوائية العامة كما يلي:

  • /init (من ramdisk، تم إنشاؤه من init_first_stage)
  • ‫/system/bin/init (من ملف ramdisk recovery، تم إنشاؤه من init_second_stage.recovery، ويتم تنفيذه من /init)

عندما يتم تشغيل الجهاز في Android، تكون محتويات vendor_boot + generic ramdisks على النحو التالي:

  • ‫/init (من ملف ramdisk العام، تم إنشاؤه من init_first_stage)

نقل ملفات fstab

انقل أي ملفات fstab تم تثبيتها في ملف ramdisk العام إلى vendor_ramdisk. للاطّلاع على مثال، يُرجى الرجوع إلى هذا التغيير.

تثبيت الوحدات

يمكنك اختياريًا تثبيت وحدات خاصة بالجهاز على vendor_ramdisk (تخطَّ هذه الخطوة إذا لم يكن لديك أي وحدات خاصة بالجهاز لتثبيتها). لا يغيّر Init الجذر. يتم تثبيت الصيغة vendor_ramdisk من الوحدات في الجذر vendor_ramdisk. للاطّلاع على أمثلة حول تثبيت الوحدات النمطية في vendor_ramdisk، راجِع وحدة تحكّم المرحلة الأولى والمجموعات الاختبارية من النوع أ/ب الافتراضية وضغط البيانات الوصفية.

وحدة تحكّم المرحلة الأولى

لتثبيت صيغة vendor_ramdisk من الوحدات، استخدِم ما يلي:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

يضمن ذلك تثبيت linker وsh وtoybox على $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin، ثم تثبيت $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.

التغييرات في عملية التشغيل

عند التمهيد في Android، لا تتغيّر عملية التمهيد. إنّ vendor_boot + generic ramdisk تشبه عملية التشغيل الحالية، باستثناء أنّ fstab يتم تحميلها من vendor_boot. بما أنّ system/bin/recovery غير متوفّر، يتعامل first_stage_init معه على أنّه عملية تشغيل عادية.

عند التمهيد في وضع الاسترداد، تتغيّر عملية التمهيد. تشبه عملية الاسترداد + vendor_boot + ramdisk العام عملية الاسترداد الحالية، ولكن يتم تحميل النواة من صورة boot بدلاً من صورة recovery. في ما يلي عملية التشغيل في وضع الاسترداد.

  1. يبدأ مُحمِّل بدء التشغيل، ثم ينفّذ ما يلي:

    1. يتم نقل عملية الاسترداد + vendor_boot + ramdisk العام إلى /. (vendor_boot هو خيار غير إلزامي في حال كان المصنّع الأصلي للجهاز يكرّر وحدات النواة في ramdisk المخصّص للاسترداد من خلال إضافتها إلى BOARD_RECOVERY_KERNEL_MODULES).
    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 من recovery ramdisk.

إتاحة e2fsck

يمكن أن تستند ملفات makefile الخاصة بالأجهزة إلى ما يلي:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk إذا كان الجهاز يتيح تقسيم A/B الافتراضي ولكنّه لا يتيح الضغط

  • ‫virtual_ab_ota/compression.mk إذا كان الجهاز يتيح ضغط A/B الافتراضي.

تثبِّت ملفات makefile الخاصة بالمنتج $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck. أثناء وقت التشغيل، تنفّذ المرحلة الأولى init /system/bin/e2fsck.

الخيار 2ب: قسم مخصّص للاسترداد وغير A/B

استخدِم هذا الخيار للأجهزة التي تحتوي على قسم recovery غير A/B، أي أنّ الجهاز يحتوي على قسم باسم recovery بدون لاحقة فتحة. وتشمل هذه الأجهزة ما يلي:

  • الأجهزة غير المتوافقة مع بنية A/B
  • أجهزة A/B وأجهزة Virtual A/B التي لا يمكن تحديث قسم الاسترداد فيها (هذا أمر غير معتاد).

يحتوي vendor_boot ramdisk على أجزاء البائع من ramdisk ووحدات kernel الخاصة بالبائع، بما في ذلك ما يلي:

  • ملفات fstab خاصة بالجهاز
  • ‫lib/modules (بما في ذلك وحدات kernel الخاصة بالمورّد)

يجب أن تكون صورة recovery مكتفية ذاتيًا. يجب أن يحتوي على جميع الموارد المطلوبة لتشغيل وضع الاسترداد، بما في ذلك:

  • صورة النواة
  • صورة DTBO
  • وحدات النواة في lib/modules
  • First-stage init as a symlink /init -> /system/bin/init
  • ملف 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

يجب أن يحتوي recovery ramdisk على رابط رمزي /init -> /system/bin/init، وinit_second_stage.recovery في /system/bin/init. عندما يتم تشغيل الجهاز في وضع الاسترداد، يكون البرنامج الثنائي /system/bin/init مطلوبًا لتوفير الدعم لكل من عملية التهيئة في المرحلة الأولى والثانية.

عندما يتم تشغيل الجهاز في recovery، تكون محتويات أقراص recovery ramdisks كما يلي:

  • ‫/init -> /system/bin/init (من recovery ramdisk)
  • ‫/system/bin/init (من ملف ramdisk recovery، تم إنشاؤه من init_second_stage.recovery، ويتم تنفيذه من /init)

عندما يتم تشغيل الجهاز في Android، تكون محتويات vendor_boot + generic ramdisks على النحو التالي:

  • /init (من ramdisk، تم إنشاؤه من init_first_stage)

نقل ملفات fstab

انقل أي ملفات fstab تم تثبيتها في ملف ramdisk العام إلى ملف ramdisk vendor_ramdisk وrecovery. للاطّلاع على مثال، يُرجى الرجوع إلى هذا التغيير.

تثبيت الوحدات

يمكنك تثبيت وحدات خاصة بالجهاز على 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، ثم تثبيت $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 \

لإتاحة استخدام المجموع الاختباري للبيانات الوصفية أثناء عملية التحميل في المرحلة الأولى من عملية الاسترداد، فعِّل إصدار الاسترداد من هذه الوحدات وثبِّتها أيضًا.

التغييرات في عملية التشغيل

عند التمهيد في Android، لا تتغيّر عملية التمهيد. إنّ vendor_boot + generic ramdisk تشبه عملية التشغيل الحالية، باستثناء أنّ fstab يتم تحميلها من vendor_boot. بما أنّ system/bin/recovery غير متوفّر، يتعامل first_stage_init معه على أنّه عملية تشغيل عادية.

عند التمهيد في وضع الاسترداد، لا تتغيّر عملية التمهيد. يتم تحميل قرص RAM الخاص بعملية الاسترداد بالطريقة نفسها المتبعة في عملية الاسترداد الحالية. يتم تحميل النواة من صورة recovery. في ما يلي عملية بدء التشغيل في وضع الاسترداد.

  1. يبدأ مُحمِّل بدء التشغيل، ثم ينفّذ ما يلي:

    1. يدفع هذا الأمر ramdisk الاسترداد إلى /.
    2. يتم تشغيل النواة من القسم recovery.

  2. يربط النواة قرص RAM بـ / ثم ينفّذ /init، وهو رابط رمزي إلى /system/bin/init من قرص RAM recovery.

  3. تبدأ عملية التهيئة في المرحلة الأولى، ثم يتم تنفيذ ما يلي:

    1. تضبط هذه السمة IsRecoveryMode() == true وForceNormalBoot() == false.
    2. تحميل وحدات نواة المورِّد من /lib/modules
    3. يتم استدعاء DoFirstStageMount() ولكن يتم تخطّي عملية الربط بسبب IsRecoveryMode() == true. (لا يحرّر الجهاز مساحة ramdisk (لأنّ / لا يزال كما هو)، ولكنّه ينفّذ SetInitAvbVersionInRecovery()).
    4. يبدأ تهيئة المرحلة الثانية من /system/bin/init من recovery ramdisk.

الطوابع الزمنية لصورة التشغيل

في ما يلي مثال على ملف طابع زمني لصورة 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 إلى قرص RAM العام. يحتوي هذا الملف على معلومات الطابع الزمني للإصدار.

  • في وقت التشغيل، init في المرحلة الأولى ينسخ الملفات من قرص ذاكرة الوصول العشوائي إلى tmpfs قبل إخلاء قرص ذاكرة الوصول العشوائي لكي تتمكّن init في المرحلة الثانية من قراءة هذا الملف لضبط خصائص الطابع الزمني لصورة boot.