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

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

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

بالنسبة إلى ترقية الأجهزة التي تواصل استخدام الإصدار 12 من Android أو إصدارات أقدم من النواة، سيبقى قرص RAM العام في مكانه بدون الحاجة إلى صورة 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. الأجهزة التي يتم طرحها أو ترقيتها إلى Android 13، والتي تتضمّن GKI، ووضع الاسترداد المخصّص، ووضع الاسترداد A/B

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

الإطلاق مع Android 13، واسترداد البيانات المخصّص وغير A/B (ramdisk مخصّص)

إطلاق/ترقية الجهاز، و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 لشهادة اعتماد boot.img في GKI (الإصدار 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، يتم إلحاق مساحة التخزين المؤقت للاسترداد بملفَي مساحة التخزين المؤقت العام و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 وتستخدم قسم 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 ويضبط الحجم. عند ضبط هذا الخيار، تتم إضافة ramdisk العام إلى 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. الإصدار 13 من نظام التشغيل Android، يتم إعدادها بشكل مشابه لما كان عليه الحال في الإصدار 12 من نظام التشغيل Android

  • الأجهزة التي سيتم ترقيتها إلى 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 على قيمة فارغة. وفي حال إجراء ذلك، سيتم استخدام إعدادات جديدة. في حال توفّر هذه الأجهزة:

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

وبما أنّ 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 (من قرص RAM عام، تم إنشاؤه من init_first_stage)
  • /system/bin/init (من vendor_ramdisk، تم إنشاؤه من init_second_stage.recovery)

نقل ملفات fstab

انقل أي ملفات fstab تم تثبيتها إلى قرص RAM عام إلى 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، الذي يثبّت حزمة APK الخاصة بالصيغة 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

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

AB_OTA_PARTITIONS += recovery

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

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

  • lib/modules (بما في ذلك وحدات نواة البائع)

يحتوي 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

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

نقل ملفات fstab

انقل أي ملفات fstab تم تثبيتها إلى قرص RAM عام إلى 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، ثم تثبيت $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 الافتراضي

لاستخدام ميزة "الضغط الافتراضي لاختبار أ/ب"، يجب تثبيت snapuserd على vendor_ramdisk. يجب أن يكتسب الجهاز الإعدادات من virtual_ab_ota/compression.mk، الذي يثبّت حزمة APK الخاصة بالصيغة 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 اختياري في حال كان المصنّع الأصلي للجهاز يكرّر وحدات النواة في قرص RAM الخاص بوضع الاسترداد من خلال إضافتها إلى 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 (بما في ذلك وحدات نواة البائع)

يجب أن تكون صورة 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 كما يلي:

  • /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. يربط النواة ramdisk بـ / ثم ينفّذ /init، وهو عبارة عن رابط رمزي إلى /system/bin/init من ramdisk 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 إلى ذاكرة الوصول العشوائي العامة. يحتوي هذا الملف على معلومات الطابع الزمني للإنشاء.

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