การทดสอบ VTS ด้วย RAMdisk สำหรับการแก้ไขข้อบกพร่อง

จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

ตั้งแต่ Android 10 เป็นต้นไป Generic System Image (GSI) ที่ใช้เรียกใช้การทดสอบการปฏิบัติตามข้อกำหนด CTS-on-GSI/VTS ได้เปลี่ยนจากประเภท userdebug เป็น user build เพื่อรับการรับรองรุ่น นี่คือ ปัญหาสำหรับการทดสอบ VTS เพราะ VTS ต้องใช้ adb root เพื่อเรียกใช้ แต่ adb root ไม่พร้อมใช้งานในอุปกรณ์บิลด์ผู้ใช้

เราได้เปิดตัว RAMdisk ที่ใช้แก้ไขข้อบกพร่อง (หรืออิมเมจการบูตที่ใช้แก้ไขข้อบกพร่อง) เพื่อเปิดใช้ adb root ในอุปกรณ์รุ่นที่ผู้ใช้สร้างขึ้นซึ่ง Bootloader ปลดล็อกแล้ว วิธีนี้ช่วยให้ขั้นตอนการทดสอบง่ายขึ้นโดยใช้ 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 ของอุปกรณ์ ระบบจะโหลดไฟล์ sepolicy เวอร์ชัน userdebug ของระบบและไฟล์พร็อพเพอร์ตี้เพิ่มเติม adb_debug.prop ซึ่งจะช่วยให้ adb root ใช้งานรุ่นที่ผู้ใช้สร้างขึ้นได้ system.img (ของ GSI หรือ OEM)

สำหรับ อิมเมจเคอร์เนลทั่วไป (GKI) ใช้อุปกรณ์ที่มีพาร์ติชัน vendor_boot boot-debug.img ต้องไม่มี กะพริบ เนื่องจากพาร์ติชัน boot ต้องกะพริบด้วยอิมเมจ GKI ที่ได้รับการรับรอง แต่ควรแฟลช vendor_boot-debug.img ลงในพาร์ติชัน vendor_boot เพื่ออำนวยความสะดวกในการแก้ไขข้อบกพร่องของ RAMdisk

ข้อกำหนดเบื้องต้นในการใช้ RAMdisk สำหรับการแก้ไขข้อบกพร่อง

OEM ที่ทำการทดสอบการปฏิบัติตามข้อกำหนดจะเป็นผู้จัดหา RAMdisk ที่ใช้แก้ไขข้อบกพร่อง ทั้งนี้ ต้องไม่มีที่เซ็นชื่อกำกับรุ่น และจะใช้ได้เฉพาะเมื่ออุปกรณ์ปลดล็อกอยู่เท่านั้น

ระบบจะไม่สร้างหรือใช้ RAMdisk สำหรับการแก้ไขข้อบกพร่องในการอัปเกรดอุปกรณ์ที่มีสิ่งต่อไปนี้

• BOARD_BUILD_SYSTEM_ROOT_IMAGE จริง
• skip_initramfs ในบรรทัดคำสั่งของเคอร์เนล

GSI ของ Android 12

คุณไม่จำเป็นต้องทำตามวิธีการเพิ่มเติมเพื่อใช้การแก้ไขข้อบกพร่องใน RAMdisk กับ GSI ของ Android 12

ตั้งแต่วันที่ 29/09/2021 เป็นต้นไป แรมดิสก์ที่ใช้แก้ไขข้อบกพร่องจะไม่จำเป็นต้องอัปเดตด้วยเครื่องมือ repack_bootimg อีกต่อไป บิลด์ GSI ของ Android 12 หลัง SGR1.210929.001 (7777720) รวมไฟล์ userdebug_plat_sepolicy.cil ที่อัปเดตแล้วไว้ใน system.img และละเว้น userdebug_plat_sepolicy.cil จากแรมดิสก์สำหรับการแก้ไขข้อบกพร่อง โปรดดู CL สำหรับ รายละเอียด

GSI ของ Android 11

เมื่อใช้ boot-debug.img หรือ vendor_boot-debug.img ระบบจะ โหลด sepolicy จากไฟล์ userdebug_plat_sepolicy.cil ในการแก้ไขข้อบกพร่อง ramdisk ของ boot-debug.img หรือ vendor_boot-debug.img ในการเปิดเครื่อง GSI โปรดรวมการเปลี่ยนแปลง sepolicy ล่าสุดจาก android11-gsi Branch เพื่อสร้าง boot-debug.img หรือ vendor_boot-debug.img ของคุณใหม่

หรือจะใช้เครื่องมือ repack_bootimg เพื่อสร้าง boot-debug.img หรือ vendor_boot-debug.img ที่มีนโยบาย GSI ที่อัปเดตแล้ว

แพ็ค RAM การแก้ไขข้อบกพร่องอีกครั้ง

พาร์ทเนอร์สามารถใช้ repack_bootimg เพื่ออัปเดตไฟล์นโยบายความปลอดภัย GSI เป็น boot-debug.img (หรือ vendor_boot-debug.img หากอุปกรณ์ใช้ GKI) แทนการรวมการเปลี่ยนแปลงนโยบายความปลอดภัยเพื่อสร้าง boot-debug.img ขึ้นมาใหม่

ขั้นตอนมีดังนี้

1. ดาวน์โหลด otatools.zip จาก https://ci.android.com เราขอแนะนำให้ดาวน์โหลดจากอาร์ติแฟกต์ของบิลด์ของ aosp_arm64-userdebug ในวันที่ aosp-main

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 ที่คุณเป็น ด้วย เช่น หากคุณใช้ 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 ในการแก้ไขข้อบกพร่อง

repack_bootimg ข้างต้นคัดลอกไฟล์ userdebug_plat_sepolicy.cil จาก ramdisk ของ --src_bootimg ไปยัง RAM ของ --dst_bootimg อย่างไรก็ตาม เส้นทางภายใน RAMdisk ที่ใช้แก้ไขข้อบกพร่องอาจแตกต่างกันไปใน 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 จาก Android 11 boot-with-debug-ramdisk-5.4.img ไปยัง first_stage_ramdisk/userdebug_plat_sepolicy.cil ภายใน Android 11 vendor_boot-debug.img

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 ต้องเพิ่มส่วนท้ายของ AVB หลังจากเรียกใช้ repack_bootimg คำสั่ง

ตัวอย่างเช่น ก่อนเรียกใช้ repack_bootimg ให้เรียกใช้คําสั่งต่อไปนี้เพื่อตรวจสอบว่า vendor_boot-debug.img มีส่วนท้าย AVB ที่เชื่อมโยงกันหรือไม่

avbtool info_image --image vendor_boot-debug.img

หากเดิมมีส่วนท้ายของ AVB เป็นเชน ต้องเพิ่มส่วนท้ายของ AVB after เรียกใช้คำสั่ง repack_bootimg การใช้คีย์ทดสอบใดก็ได้เพื่อลงนามใน vendor_boot-debug.img จะใช้งานได้เนื่องจากใช้ RAMdisk สำหรับการแก้ไขข้อบกพร่องได้ก็ต่อเมื่อปลดล็อกอุปกรณ์เท่านั้น ซึ่งจะอนุญาตให้ใช้รูปภาพที่ลงนามด้วยคีย์ที่ไม่ใช่รุ่นในพาร์ติชัน 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