في نظام التشغيل 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 العام إلى ملف ramdiskvendor_boot.استخدِم قسم
recoveryمخصّصًا، ولن تحتاج إلى إجراء أي تغيير فيrecoveryramdisk لأنّrecoveryramdisk مستقل.
البنية
توضّح المخططات التالية بنية الأجهزة التي تعمل بالإصدار 12 من نظام التشغيل Android والإصدارات الأحدث.
تحتوي الأجهزة التي تعمل بالإصدار 13 من نظام التشغيل Android على صورة init_boot جديدة تتضمّن مساحة التخزين المؤقت للذاكرة العشوائية (ramdisk) العامة.
تستخدم الأجهزة التي تمت ترقيتها من Android 12 إلى Android 13 البنية نفسها التي كانت تستخدمها مع Android 12.
إطلاق الجهاز باستخدام Android 13 بدون بيئة مخصّصة للاسترداد
الشكل 1. الأجهزة التي يتم إطلاقها أو ترقيتها إلى Android 13، والتي تتضمّن GKI، بدون وضع استرداد مخصّص
الإطلاق باستخدام نظام التشغيل Android 13، مع إمكانية الاسترداد المخصّص واختبار A/B (قرص RAM مخصّص)
الشكل 2. الأجهزة التي يتم طرحها أو ترقيتها إلى Android 13، والتي تتضمّن GKI، ووضع الاسترداد المخصّص، ووضع الاسترداد A/B
راجِع هذا الشكل إذا كان الجهاز يحتوي على قسمَي recovery_a وrecovery_b.
الإطلاق مع Android 13، واسترداد البيانات المخصّص وغير A/B (ramdisk مخصّص)
الشكل 3. الأجهزة التي يتم طرحها أو ترقيتها إلى الإصدار 13 من نظام التشغيل Android، مع توفّر GKI، وإمكانية الاسترداد المخصّصة وغير A/B
راجِع هذا الشكل إذا كان الجهاز يحتوي على قسم باسم recovery بدون لاحقة فتحة.
تشغيل الإصدار 12 من نظام التشغيل Android أو الترقية إليه، بدون وضع استرداد مخصّص
الشكل 4. الأجهزة التي يتم طرحها أو ترقيتها إلى Android 12، مع GKI، بدون وضع استرداد مخصّص
تشغيل Android 12 أو الترقية إليه، واسترداد البيانات المخصّص واختبار A/B (قرص RAM مخصّص)
الشكل 5. الأجهزة التي يتم طرحها أو ترقيتها إلى Android 12، والتي تتضمّن GKI وعملية استرداد مخصّصة وعملية استرداد A/B
راجِع هذا الشكل إذا كان الجهاز يحتوي على قسمَي recovery_a وrecovery_b.
تشغيل الإصدار 12 من نظام التشغيل Android أو الترقية إليه، واسترداد البيانات المخصّص وغير A/B (ramdisk مخصّص)
الشكل 6. الأجهزة التي يتم طرحها أو ترقيتها إلى Android 12، والتي تتضمّن GKI، ووضع الاسترداد المخصّص وغير A/B
راجِع هذا الشكل إذا كان الجهاز يحتوي على قسم باسم recovery بدون لاحقة فتحة.
الترقية إلى Android 12، ميزة "الاسترداد كتمهيد" (الاسترداد كقرص RAM)
الشكل 7. الأجهزة التي تتم ترقيتها إلى Android 12، بدون GKI، واستعادة البيانات عند إعادة التشغيل
الترقية إلى Android 12، وضع الاسترداد المخصّص (ملف ramdisk مخصّص)
الشكل 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 والإصدارات الأقدم
- يتم تضمينها فقط في صور
- إصدار العنوان V3 أو
V4
vendor_bootصورة (للحصول على التفاصيل، يُرجى الاطّلاع على أقسام التشغيل الخاصة بالمورّد)vendor_bootheadercmdlineخاص بالجهاز (BOARD_KERNEL_CMDLINE)
vendor_bootصورة ramdisklib/modules- موارد الاسترداد (في حال عدم توفّر عملية استرداد مخصّصة)
- صورة واحدة (
dtb)
صورة واحدة (
recovery)- الإصدار الثاني من العنوان
cmdlineخاص بالجهاز لاسترداد البيانات، إذا لزم الأمر- بالنسبة إلى قسم الاسترداد غير A/B، يجب أن تكون محتويات العنوان مستقلة، راجِع صور الاسترداد. مثلاً:
- لا يتم ربط
cmdlineبـbootوvendor_bootcmdline. - يحدّد العنوان DTBO للاسترداد، إذا لزم الأمر.
- بالنسبة إلى قسم الاسترداد A/B، يمكن ربط المحتويات أو استنتاجها من
bootوvendor_boot. مثلاً: - يتم ربط
cmdlineبـbootوvendor_bootcmdline. - يمكن استنتاج DTBO من العنوان
vendor_boot.
recoveryصورة ramdisk- مراجع الاسترداد
- بالنسبة إلى قسم الاسترداد غير A/B، يجب أن تكون محتويات ramdisk مستقلة، ويُرجى الاطّلاع على صور الاسترداد. مثلاً:
- يجب أن يحتوي
lib/modulesعلى جميع وحدات النواة المطلوبة لتشغيل وضع الاسترداد - يجب أن يحتوي ملف ramdisk الخاص باسترداد البيانات على
init. - بالنسبة إلى قسم الاسترداد A/B، يتم إلحاق مساحة التخزين المؤقت للاسترداد بملفَي مساحة التخزين المؤقت العام و
vendor_boot، وبالتالي لا يلزم أن يكون ملفًا مستقلاً. مثلاً: - قد يحتوي
lib/modulesعلى وحدات نواة إضافية فقط مطلوبة لتشغيل وضع الاسترداد، بالإضافة إلى وحدات النواة فيvendor_bootramdisk. - قد يكون الرابط الرمزي في
/initمتوفّرًا، ولكن يتم حظره بواسطة الثنائي/initفي المرحلة الأولى في صورة التمهيد.
- الإصدار الثاني من العنوان
محتويات صورة ramdisk العامة
يحتوي ملف ramdisk العام على المكوّنات التالية.
initsystem/etc/ramdisk/build.propro.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/Brecoveryهذا المتغير على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على قيمة فارغة. وفي حال إجراء ذلك، سيتم استخدام إعدادات جديدة. في حال توفّر هذه الأجهزة:لا تستخدِم قسم
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
ملفات init الثنائية وروابطها الرمزية
يمكن أن يحتوي 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 (تخطَّ هذه الخطوة إذا لم يكن لديك أي وحدات خاصة بالجهاز لتثبيتها).
استخدِم صيغة
vendor_ramdiskللوحدة عند تثبيتها في/first_stage_ramdisk. من المفترض أن تكون هذه الوحدة متاحة بعد أن ينتقلinitمن الجذر إلى/first_stage_ramdiskولكن قبل أن ينتقلinitمن الجذر إلى/system. للاطّلاع على أمثلة، راجِع مجموعات التحقّق من سلامة البيانات الوصفية وضغط اختبارات أ/ب الافتراضية.استخدِم صيغة
recoveryمن الوحدة عند تثبيت الوحدة في/. يجب أن يكون هذا النموذج متاحًا قبل أن يحوّلinitالجذر إلى/first_stage_ramdisk. للحصول على تفاصيل حول تثبيت الوحدات في/، راجِع وحدة تحكّم المرحلة الأولى.
وحدة التحكّم في المرحلة الأولى
بما أنّ وحدة التحكّم في المرحلة الأولى تبدأ قبل أن يحوّل init الجذر إلى /first_stage_ramdisk، عليك تثبيت صيغة recovery من الوحدات.
يتم تلقائيًا تثبيت كلا نوعَي الوحدات النمطية في build/make/target/product/base_vendor.mk، لذا إذا كان ملف makefile الخاص بالجهاز يتضمّن هذا الملف، لن تحتاج إلى تثبيت النوع recovery بشكل صريح.
لتثبيت وحدات الاسترداد بشكلٍ صريح، استخدِم ما يلي.
PRODUCT_PACKAGES += \
linker.recovery \
shell_and_utilities_recovery \
يضمن ذلك تثبيت linker وsh وtoybox على $ANDROID_PRODUCT_OUT/recovery/root/system/bin، ثم تثبيت $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
ملفات init الثنائية وروابطها الرمزية
يمكن أن يحتوي قرص 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(من ملف ramdiskrecovery، تم إنشاؤه من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.
في ما يلي عملية التشغيل في وضع الاسترداد.
يبدأ مُحمِّل بدء نظام التشغيل، ثم ينفّذ ما يلي:
- يدفع عملية الاسترداد +
vendor_boot+ ramdisk عام إلى/. (vendor_bootاختياري في حال كان المصنّع الأصلي للجهاز يكرّر وحدات النواة في قرص RAM الخاص بوضع الاسترداد من خلال إضافتها إلىBOARD_RECOVERY_KERNEL_MODULES). - يتم تشغيل النواة من القسم
boot.
- يدفع عملية الاسترداد +
تثبّت النواة ملف ramdisk في
/ثم تنفّذ/initمن ملف ramdisk العام.تبدأ عملية تهيئة المرحلة الأولى، ثم يتم تنفيذ ما يلي:
- تضبط هذه السمة
IsRecoveryMode() == trueوForceNormalBoot() == false. - تحميل وحدات نواة المورّد من
/lib/modules - يتم استدعاء
DoFirstStageMount()ولكن يتم تخطّي عملية الربط بسببIsRecoveryMode() == true. (لا يحرّر الجهاز مساحة ramdisk (لأنّ/لا يزال كما هو)، ولكنّه ينفّذSetInitAvbVersionInRecovery()). - يبدأ تهيئة المرحلة الثانية من
/system/bin/initمنrecoveryramdisk.
- تضبط هذه السمة
إتاحة 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
ملفات init الثنائية وروابطها الرمزية
يجب أن يحتوي recovery ramdisk على رابط رمزي /init -> /system/bin/init،
وinit_second_stage.recovery في /system/bin/init. عندما يتم تشغيل الجهاز في وضع الاسترداد، يكون البرنامج الثنائي /system/bin/init مطلوبًا لتوفير الدعم لكل من عملية التهيئة في المرحلة الأولى والمرحلة الثانية.
عندما يبدأ الجهاز في التشغيل في recovery، تكون محتويات أقراص ذاكرة الوصول العشوائي recovery كما يلي:
-
/init -> /system/bin/init(منrecoveryramdisk) -
/system/bin/init(من ملف ramdiskrecovery، تم إنشاؤه من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. في ما يلي عملية بدء التشغيل في وضع الاسترداد.
يبدأ مُحمِّل بدء نظام التشغيل، ثم ينفّذ ما يلي:
- يدفع هذا الأمر ramdisk الاسترداد إلى
/. - يتم تشغيل النواة من القسم
recovery.
- يدفع هذا الأمر ramdisk الاسترداد إلى
يربط النواة ramdisk بـ
/ثم ينفّذ/init، وهو عبارة عن رابط رمزي إلى/system/bin/initمن ramdiskrecovery.تبدأ عملية تهيئة المرحلة الأولى، ثم يتم تنفيذ ما يلي:
- تضبط هذه السمة
IsRecoveryMode() == trueوForceNormalBoot() == false. - تحميل وحدات نواة المورّد من
/lib/modules - يتم استدعاء
DoFirstStageMount()ولكن يتم تخطّي عملية الربط بسببIsRecoveryMode() == true. (لا يحرّر الجهاز مساحة ramdisk (لأنّ/لا يزال كما هو)، ولكنّه ينفّذSetInitAvbVersionInRecovery()). - يبدأ تهيئة المرحلة الثانية من
/system/bin/initمنrecoveryramdisk.
- تضبط هذه السمة
الطوابع الزمنية لصورة التشغيل
في ما يلي مثال على ملف 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.