اختبار VTS باستخدام ذاكرة الوصول العشوائي (RAM) لتصحيح الأخطاء

في الإصدار 10 من نظام التشغيل Android والإصدارات الأحدث، تم تغيير صورة النظام العامة (GSI) المستخدَمة لتشغيل اختبار التوافق CTS-on-GSI/VTS من نوع التصميم userdebug إلى نوع التصميم user لكي يتم توقيع الإصدار. وهذه مشكلة في اختبار VTS لأنّه يتطلّب تشغيل adb root، ولكن adb root غير متاح على جهاز إصدار المستخدم.

تم طرح ملف ramdisk لتصحيح الأخطاء (أو صورة التشغيل لتصحيح الأخطاء) لتفعيل adb root على جهاز يعمل بإصدار غير مقفَل من برنامج الإقلاع. ويؤدي ذلك إلى تبسيط عملية الاختبار من خلال استخدام إصدار المستخدم نفسه من صورة نظام GSI system.img لكل من اختبار التوافق CTS على صورة نظام GSI واختبار VTS على صورة نظام GSI. بالنسبة إلى إعداد STS، لا يزال من الضروري استخدام إصدار آخر من OEM system.img المخصّص لتصحيح الأخطاء.

يوضّح الجدول التالي التغييرات التي تم إجراؤها على نوعَي الصور ونوع التصميم لاختبار التوافق في Android 10.

نظرة عامة

يتم إنشاء ملفات الصور الإضافية هذه ضمن مجلد الإنشاء (${ANDROID_PRODUCT_OUT}):

• boot-debug.img
• vendor_boot-debug.img

عندما يتم تثبيت boot-debug.img على قسم boot في الجهاز، يتم تحميل إصدار userdebug من ملف sepolicy الخاص بالنظام وملف خصائص إضافي، وهو adb_debug.prop. يتيح ذلك adb root مع إصدار المستخدم system.img (إما GSI أو إصدار الشركة المصنّعة للجهاز الأصلي).

بالنسبة إلى الأجهزة التي تستخدم صورة نواة عامة (GKI) والتي تحتوي على قسم vendor_boot، يجب عدم تثبيت boot-debug.img، لأنّه يجب تثبيت قسم boot باستخدام صورة GKI معتمَدة. بدلاً من ذلك، يجب نقل vendor_boot-debug.img إلى قسم vendor_boot لتسهيل استخدام مساحة التخزين المؤقت للذاكرة العشوائية المخصّصة لتصحيح الأخطاء.

المتطلبات الأساسية لاستخدام قرص RAM لتصحيح الأخطاء

يوفّر الشركة المصنّعة للأجهزة الأصلية (OEM) قرص RAM للتصحيح والأخطاء الذي يتم تشغيله أثناء اختبارات التوافق. يجب ألا يكون الإصدار موقّعًا، ولا يمكن استخدامه إلا إذا كان الجهاز غير مقفل.

لن يتم إنشاء قرص RAM للتصحيح أو استخدامه لترقية الأجهزة التي تتضمّن ما يلي:

• BOARD_BUILD_SYSTEM_ROOT_IMAGE صحيح
• ‫skip_initramfs في سطر أوامر النواة

‫Android 12 GSI

لا يلزم توفير تعليمات إضافية لاستخدام قرص ذاكرة الوصول العشوائي المخصّص لتصحيح الأخطاء مع صورة نظام Android 12 العامة.

اعتبارًا من 29/09/2021، لم يعُد من الضروري تعديل أقراص RAM المخصّصة لتصحيح الأخطاء باستخدام الأداة repack_bootimg. يتضمّن إصدار Android 12 GSI بعد SGR1.210929.001 (7777720) ملف userdebug_plat_sepolicy.cil محدّثًا في system.img ويتجاهل userdebug_plat_sepolicy.cil من قرص RAM لتصحيح الأخطاء. راجِع قوائم التغيير للحصول على التفاصيل.

‫Android 11 GSI

عند استخدام boot-debug.img أو vendor_boot-debug.img، يتم تحميل سياسة الأمان SELinux من ملف userdebug_plat_sepolicy.cil في ramdisk لتصحيح الأخطاء في boot-debug.img أو vendor_boot-debug.img. لتشغيل صور GSI، يُرجى دائمًا دمج آخر التغييرات في sepolicy من فرع android11-gsi لإعادة إنشاء boot-debug.img أو vendor_boot-debug.img.

بدلاً من ذلك، يمكن استخدام الأداة repack_bootimg لإعادة إنشاء boot-debug.img أو vendor_boot-debug.img باستخدام سياسة الأمان المحدّثة لواجهة GSI.

إعادة حزم ramdisk لتصحيح الأخطاء

بدلاً من دمج تغييرات sepolicy لإعادة إنشاء boot-debug.img، يمكن للشركاء استخدام repack_bootimg لتعديل ملف sepolicy الخاص بصورة النظام العامة (GSI) إلى boot-debug.img (أو vendor_boot-debug.img إذا كان الجهاز يستخدم GKI).

في ما يلي الخطوات التي يجب اتّباعها:

1. نزِّل otatools.zip من https://ci.android.com. ننصحك بتنزيلها من عناصر الإصدار aosp_cf_arm64_only_phone-userdebug على فرع aosp-android-latest-release.

2. إعداد بيئة التنفيذ لـ repack_bootimg:

   unzip otatools.zip -d otatools
   export PATH="${PWD}/otatools/bin:${PATH}"
   repack_bootimg --help

3. نزِّل userdebug_plat_sepolicy.cil أو boot-with-debug-ramdisk-${KERNEL_VERSION}.img من إصدار GSI الذي تستخدمه. على سبيل المثال، إذا كنت تستخدم صورة نظام عام arm64 من RJR1.211020.001 (7840830)، يمكنك تنزيلها من https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest.

4. عدِّل الجهاز boot-debug.img أو vendor_boot-debug.img باستخدام userdebug_plat_sepolicy.cil:

   repack_bootimg --local --dst_bootimg boot-debug.img \
       --ramdisk_add userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
       --ramdisk_add userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
   # If using GKI
   repack_bootimg --local --dst_bootimg vendor_boot-debug.img \
       --ramdisk_add userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
       --ramdisk_add userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil

   باستخدام boot-with-debug-ramdisk-${KERNEL_VERSION}.img:

   repack_bootimg --src_bootimg boot-with-debug-ramdisk-5.4.img \
       --dst_bootimg boot-debug.img \
       --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
       --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
   # If using GKI
   repack_bootimg --src_bootimg boot-with-debug-ramdisk-5.4.img \
       --dst_bootimg vendor_boot-debug.img \
       --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
       --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil

   يمكن تعديل وسيطات --ramdisk_add وفقًا لإعدادات الجهاز. يُرجى الاطّلاع على القسم التالي للحصول على شرح مفصّل.

مسار sepolicy الخاص بـ userdebug

ينسخ الأمر أعلاه repack_bootimg الملف userdebug_plat_sepolicy.cil من ramdisk الخاص بالجهاز --src_bootimg إلى ramdisk الخاص بالجهاز --dst_bootimg. ومع ذلك، قد يختلف المسار داخل قرص RAM للتصحيح والأخطاء في إصدارات Android المختلفة. في نظامَي التشغيل Android 10 و11، يكون المسار first_stage_ramdisk/userdebug_plat_sepolicy.cil للأجهزة التي تتضمّن androidboot.force_normal_boot=1 في سطر أوامر النواة. في ما عدا ذلك، يكون المسار userdebug_plat_sepolicy.cil.

نفِّذ الأمر التالي للتحقّق مما إذا كان هناك androidboot.force_normal_boot في سطر أوامر النواة:

adb root
adb shell cat /proc/cmdline | grep force_normal_boot

في نظام التشغيل Android 12 والإصدارات الأحدث، يكون المسار ضِمن ramdisk لتصحيح الأخطاء هو userdebug_plat_sepolicy.cil دائمًا، بغض النظر عن توفّر androidboot.force_normal_boot=1 في سطر أوامر النواة. يوضّح الجدول التالي المسارات داخل قرص RAM للتصحيح في إصدارات Android المختلفة.

يمكنك تحديد --ramdisk_add لنسخ الملفات من مسارات مختلفة وإليها باستخدام قائمة بأزواج src_path:dst_path. على سبيل المثال، ينسخ الأمر التالي الملف first_stage_ramdisk/userdebug_plat_sepolicy.cil من boot-with-debug-ramdisk-5.4.img (جهاز Android 11) إلى first_stage_ramdisk/userdebug_plat_sepolicy.cil في vendor_boot-debug.img (جهاز Android 11).

repack_bootimg \
    --src_bootimg boot-with-debug-ramdisk-5.4.img \
    --dst_bootimg vendor_boot-debug.img \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil

إذا لم يكن هناك androidboot.force_normal_boot=1 في سطر أوامر النواة، يجب تعديل الأمر على النحو التالي لتغيير مسار الوجهة إلى userdebug_plat_sepolicy.cil.

repack_bootimg \
    --src_bootimg boot-with-debug-ramdisk-5.4.img \
    --dst_bootimg vendor_boot-debug.img \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil

إضافة تذييل AVB

إذا تم ضبط الصورة التي تم تمريرها إلى --dst_bootimg كقسم AVB-chained، يجب إضافة تذييل AVB بعد تنفيذ الأمر repack_bootimg.

على سبيل المثال، قبل تنفيذ repack_bootimg، نفِّذ الأمر التالي للتحقّق مما إذا كان vendor_boot-debug.img يتضمّن تذييلاً متسلسلاً من AVB.

avbtool info_image --image vendor_boot-debug.img

إذا كان يحتوي في الأصل على تذييل AVB متسلسل، يجب إضافة تذييل AVB بعد تنفيذ الأمر repack_bootimg. يمكن استخدام أي مفتاح اختبار لتوقيع vendor_boot-debug.img لأنّه لا يمكن استخدام قرص RAM المخصّص لتصحيح الأخطاء إلا عند فتح قفل الجهاز، ما يتيح استخدام صور موقّعة بمفتاح غير مخصّص للإصدار على القسم boot أو vendor_boot.

avbtool add_hash_footer --partition_name vendor_boot \
    --partition_size 100663296 \
    --algorithm SHA256_RSA4096 \
    --key otatools/external/avb/test/data/testkey_rsa4096.pem \
    --image vendor_boot-debug.img