في نظام التشغيل 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
مخصّصًا، ولن تحتاج إلى إجراء أي تغيير فيrecovery
ramdisk لأنّrecovery
ramdisk مستقل.
البنية
توضّح المخططات التالية بنية الأجهزة التي تعمل بالإصدار 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_boot
headercmdline
خاص بالجهاز (BOARD_KERNEL_CMDLINE
)
vendor_boot
صورة ramdisklib/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/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
من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
ملفات init الثنائية وروابطها الرمزية
يجب أن يحتوي 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
(من ملف 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
من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
.