การทดสอบ VTS ด้วย RAM การแก้ไขข้อบกพร่อง

ตั้งแต่ Android 10 เป็นต้นไป Generic System Image (GSI) ที่ใช้เรียกใช้การทดสอบการปฏิบัติตามข้อกำหนด CTS-on-GSI/VTS ได้เปลี่ยนจากประเภท userdebug เป็นประเภทบิลด์ผู้ใช้เพื่อให้ได้รับการรับรองรุ่น ปัญหานี้ส่งผลต่อการทดสอบ 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 แทน เพื่อให้ RAM แก้ไขข้อบกพร่องในการแก้ไขข้อบกพร่องได้ง่ายขึ้น

ข้อกําหนดเบื้องต้นในการใช้ RAMdisk ที่ใช้แก้ไขข้อบกพร่อง

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

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

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

GSI ของ Android 12

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

ตั้งแต่วันที่ 29/09/2021 เป็นต้นไป RAM การแก้ไขข้อบกพร่องจะไม่ต้องอัปเดตด้วยเครื่องมือ 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 ระบบจะโหลดนโยบายของระบบจากไฟล์ userdebug_plat_sepolicy.cil ใน RAM การแก้ไขข้อบกพร่องของ 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 ที่อัปเดตแล้วก็ได้

แพ็กแรมดิสก์ที่ใช้แก้ไขข้อบกพร่องอีกครั้ง

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

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

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 ที่คุณใช้อยู่ เช่น หากคุณใช้ arm64 GSI จาก 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 จากแรมดิสก์ของ --src_bootimg ไปยังแรมดิสก์ของ --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 เป็นต้นไป เส้นทางภายในไฟล์ RAM ที่ใช้แก้ไขข้อบกพร่องจะเป็น userdebug_plat_sepolicy.cil เสมอ ไม่ว่าจะมี androidboot.force_normal_boot=1 ในบรรทัดคำสั่งเคอร์เนลหรือไม่ก็ตาม ตารางต่อไปนี้แสดงเส้นทางภายใน RAM disk ที่ใช้แก้ไขข้อบกพร่องใน 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 หลังจากเรียกใช้คำสั่ง 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