อิมเมจระบบทั่วไป

Generic System Image (GSI) คืออิมเมจระบบที่มีการกำหนดค่าที่ปรับแล้ว สำหรับอุปกรณ์ Android โดยถือเป็นการใช้งาน Android แบบเพียวๆ ด้วยโค้ด โครงการโอเพนซอร์ส Android (AOSP) ที่ไม่ได้แก้ไข ซึ่งอุปกรณ์ Android ที่ใช้ Android 9 ขึ้นไปจะเรียกใช้ได้สำเร็จ

GSI ใช้สำหรับการเรียกใช้การทดสอบ VTS และ CTS-on-GSI ระบบจะแทนที่อิมเมจระบบของอุปกรณ์ Android ด้วย GSI แล้วทดสอบด้วย Vendor Test Suite (VTS) และ ชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) เพื่อให้แน่ใจ ว่าอุปกรณ์จะใช้อินเทอร์เฟซของผู้ผลิตอย่างถูกต้องด้วย Android เวอร์ชันล่าสุด

หากต้องการเริ่มต้นใช้งาน GSI โปรดดูรายละเอียดเกี่ยวกับ การกำหนดค่า GSI (และการเปลี่ยนแปลงที่อนุญาต ) และ ประเภทต่างๆ ในส่วนต่อไปนี้ เมื่อพร้อมที่จะใช้ GSI แล้ว ให้ดาวน์โหลดและสร้าง GSI สำหรับอุปกรณ์ เป้าหมาย จากนั้นแฟลช GSI ลงในอุปกรณ์ Android

การกำหนดค่าและการเปลี่ยนแปลงของ GSI

GSI ของ Android ปัจจุบันมีการกำหนดค่าดังนี้

  • เสียงแหลม GSI รองรับการเปลี่ยนแปลงทางสถาปัตยกรรมที่อิงตาม AIDL/HIDL อย่างเต็มรูปแบบ (หรือที่เรียกว่า Treble) ซึ่งรวมถึงการรองรับ อินเทอร์เฟซ AIDL และ อินเทอร์เฟซ HIDL คุณสามารถใช้ GSI ใน อุปกรณ์ Android ใดก็ได้ที่ใช้อินเทอร์เฟซของผู้ผลิต AIDL/HIDL (ดูรายละเอียดเพิ่มเติมได้ที่ แหล่งข้อมูลสถาปัตยกรรม.)
  • ระบบไฟล์ GSI ใช้ระบบไฟล์ ext4

GSI ของ Android ปัจจุบันมีการเปลี่ยนแปลงที่สำคัญดังนี้

  • สถาปัตยกรรม CPU การรองรับคำสั่ง CPU ที่แตกต่างกัน (ARM, x86 ฯลฯ) และความกว้างของบิต CPU (32 บิตหรือ 64 บิต)

เป้าหมาย GSI สำหรับการทดสอบการปฏิบัติตามข้อกำหนดของ Treble

ระบบจะกำหนด GSI ที่ใช้สำหรับการทดสอบการปฏิบัติตามข้อกำหนดตามเวอร์ชัน Android ที่อุปกรณ์เปิดตัว

ประเภทอุปกรณ์ เป้าหมายบิลด์
อุปกรณ์ที่เปิดตัวด้วย Android 15 gsi_$arch-user (ลงชื่อแล้ว)
อุปกรณ์ที่เปิดตัวด้วย Android 14 gsi_$arch-user (ลงชื่อแล้ว)
อุปกรณ์ที่เปิดตัวด้วย Android 13 gsi_$arch-user (ลงชื่อแล้ว)
อุปกรณ์ที่เปิดตัวด้วย Android 12L gsi_$arch-user (ลงชื่อแล้ว)
อุปกรณ์ที่เปิดตัวด้วย Android 12 gsi_$arch-user (ลงชื่อแล้ว)
อุปกรณ์ที่เปิดตัวด้วย Android 11 gsi_$arch-user (ลงชื่อแล้ว)

GSI ทั้งหมดสร้างขึ้นจากฐานของโค้ด Android 12 และ สถาปัตยกรรม CPU แต่ละรายการจะมีไบนารี GSI ที่เกี่ยวข้อง (ดูรายการเป้าหมายบิลด์ ใน การสร้าง GSI)

การเปลี่ยนแปลง GSI ของ Android 12

อุปกรณ์ที่เปิดตัวด้วยหรืออัปเดตเป็น Android 12 ต้องใช้ GSI ของ Android 12 สำหรับการทดสอบการปฏิบัติตามข้อกำหนด ซึ่งรวมถึงการเปลี่ยนแปลงที่สำคัญต่อไปนี้จาก GSI ก่อนหน้า

  • ชื่อเป้าหมาย ชื่อเป้าหมาย GSI สำหรับการทดสอบการปฏิบัติตามข้อกำหนดจะเปลี่ยนเป็น gsi_$arch ระบบจะเก็บ GSI ที่มีชื่อเป้าหมาย aosp_$arch ไว้สำหรับนักพัฒนาแอป Android นอกจากนี้ ระบบยังลดแผนการทดสอบ CTS-on-GSI สำหรับการทดสอบอินเทอร์เฟซของผู้ผลิตด้วย
  • เลิกใช้ GSI รุ่นเดิม GSI 12 จะนำวิธีแก้ปัญหาที่รองรับอุปกรณ์ Android 8.0 หรือ 8.1 ที่ ไม่ได้ใช้ Treble อย่างเต็มรูปแบบออก
  • SEPolicy ของ Userdebug GSI gsi_$arch มี userdebug_plat_sepolicy.cil เมื่อแฟลช ที่เฉพาะเจาะจงของ OEM vendor_boot-debug.img หรือ boot-debug.img, /system/bin/init จะโหลด userdebug_plat_sepolicy.cil จาก system.img ของ GSI โปรดดูรายละเอียดที่หัวข้อการทดสอบ VTS ด้วย Debug Ramdisk

การเปลี่ยนแปลง GSI ของ Android 11

อุปกรณ์ที่เปิดตัวด้วยหรืออัปเดตเป็น Android 11 ต้องใช้ GSI ของ Android 11 สำหรับการทดสอบการปฏิบัติตามข้อกำหนด ซึ่งรวมถึงการเปลี่ยนแปลงที่สำคัญต่อไปนี้จาก GSI ก่อนหน้า

  • เนื้อหา system_ext Android 11 กำหนดพาร์ทิชันใหม่ system_ext GSI จะวางเนื้อหาส่วนขยายระบบไว้ในโฟลเดอร์ system/system_ext.
  • APEX GSI มีทั้ง APEX แบบแฟลตและแบบบีบอัด ระบบจะกำหนดว่าจะใช้ APEX แบบใดโดยพิจารณาจากพร็อพเพอร์ตี้ระบบ ro.apex.updatable ในพาร์ทิชันของผู้ผลิตระหว่างรันไทม์ โปรดดูรายละเอียดที่หัวข้อการกำหนดค่าระบบเพื่อรองรับการอัปเดต APEX

การเปลี่ยนแปลง GSI ของ Android 10

อุปกรณ์ที่เปิดตัวด้วยหรืออัปเดตเป็น Android 10 ต้องใช้ GSI ของ Android 10 สำหรับการทดสอบการปฏิบัติตามข้อกำหนด ซึ่งรวมถึงการเปลี่ยนแปลงที่สำคัญต่อไปนี้จาก GSI ก่อนหน้า

  • บิลด์ของผู้ใช้ GSI มีบิลด์ของผู้ใช้จาก Android 10 ใน Android 10 คุณสามารถใช้ GSI ของบิลด์ของผู้ใช้ในการทดสอบการปฏิบัติตามข้อกำหนด CTS-on-GSI/VTS โปรดดูรายละเอียดที่หัวข้อ การทดสอบ VTS ด้วย Debug Ramdisk
  • รูปแบบ Unsparsed GSI ที่มีเป้าหมาย aosp_$arch สร้างขึ้นด้วยรูปแบบ Unsparsed คุณสามารถใช้ img2simg เพื่อแปลง GSI แบบ Unsparsed เป็นรูปแบบ Sparse ได้หาก จำเป็น
  • System-as-root ระบบได้เลิกใช้เป้าหมายบิลด์ GSI รุ่นเดิมที่ชื่อ aosp_$arch_a แล้ว สำหรับอุปกรณ์ที่อัปเกรด จาก Android 8 หรือ 8.1 เป็น Android 10 ที่มี Ramdisk และ ไม่ใช่ System-as-root ให้ใช้ GSI รุ่นเดิม aosp_$arch_ab init ที่อัปเกรดแล้วใน Ramdisk รองรับ OEM system.img ที่มีเลย์เอาต์ System-as-root
  • การเปิดเครื่องที่ได้รับการยืนยัน เมื่อใช้ GSI คุณจะต้องปลดล็อกอุปกรณ์เท่านั้น ไม่จำเป็นต้องปิดใช้การเปิดเครื่องที่ได้รับการยืนยัน

การเปลี่ยนแปลง GSI ของ Android 9

อุปกรณ์ที่เปิดตัวด้วยหรืออัปเดตเป็น Android 9 ต้องใช้ GSI ของ Android 9 สำหรับการทดสอบการปฏิบัติตามข้อกำหนด ซึ่งรวมถึงการเปลี่ยนแปลงที่สำคัญต่อไปนี้จาก GSI ก่อนหน้า

  • ผสานรวม GSI และโปรแกรมจำลอง GSI สร้างขึ้นจากอิมเมจระบบของผลิตภัณฑ์โปรแกรมจำลอง เช่น aosp_arm64 และ aosp_x86
  • System-as-root ใน Android เวอร์ชันก่อนหน้า อุปกรณ์ ที่ไม่รองรับการอัปเดต A/B สามารถต่อเชื่อมกับอิมเมจระบบภายใต้ /system ไดเรกทอรีได้ ใน Android 9 ระบบจะต่อเชื่อมรูทของอิมเมจระบบเป็นรูทของอุปกรณ์
  • อินเทอร์เฟซ Binder แบบ 64 บิต ใน Android 8.x, GSI แบบ 32 บิต ใช้อินเทอร์เฟซ Binder แบบ 32 บิต Android 9 ไม่รองรับอินเทอร์เฟซ Binder แบบ 32 บิต ดังนั้นทั้ง GSI แบบ 32 บิตและ GSI แบบ 64 บิตจึงใช้อินเทอร์เฟซ Binder แบบ 64 บิต
  • การบังคับใช้ VNDK ใน Android 8.1 VNDK เป็นตัวเลือก ตั้งแต่ Android 9 เป็นต้นไป VNDK เป็นสิ่งที่จำเป็น ดังนั้นจึง BOARD_VNDK_VERSION ต้อง ตั้งค่า
  • พร็อพเพอร์ตี้ระบบที่เข้ากันได้ Android 9 เปิดใช้การตรวจสอบการเข้าถึงสำหรับพร็อพเพอร์ตี้ระบบที่เข้ากันได้ (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true)

การเปลี่ยนแปลง Keymaster ของ Android 9

ใน Android เวอร์ชันก่อนหน้า อุปกรณ์ที่ใช้ Keymaster 3 หรือต่ำกว่าจะต้อง ยืนยันว่าข้อมูลเวอร์ชัน (ro.build.version.release และ ro.build.version.security_patch) ที่ระบบที่ทำงานอยู่รายงาน ตรงกับข้อมูลเวอร์ชันที่ Bootloader รายงาน โดยปกติแล้วข้อมูลดังกล่าวจะได้รับจากส่วนหัวของอิมเมจบูต

ใน Android 9 ขึ้นไป ข้อกำหนดนี้มีการเปลี่ยนแปลงเพื่อให้ ผู้ผลิตสามารถบูต GSI ได้ โดยเฉพาะอย่างยิ่ง Keymaster ไม่ควรทำการยืนยัน เนื่องจากข้อมูลเวอร์ชันที่ GSI รายงานอาจไม่ตรงกับข้อมูลเวอร์ชัน ที่ Bootloader ของผู้ผลิตรายงาน สำหรับอุปกรณ์ที่ใช้ Keymaster 3 หรือ ต่ำกว่า ผู้ผลิตต้องแก้ไขการใช้งาน Keymaster เพื่อข้ามการยืนยัน (หรืออัปเกรดเป็น Keymaster 4) ดูรายละเอียดเกี่ยวกับ Keymaster ได้ที่ Keystore ที่อิงฮาร์ดแวร์

ดาวน์โหลด GSI

คุณสามารถดาวน์โหลด GSI ที่สร้างไว้ล่วงหน้าได้จากเว็บไซต์การรวมอย่างต่อเนื่อง (CI) ของ AOSP ที่ ci.android.com หากดาวน์โหลด GSI ประเภทที่ใช้กับแพลตฟอร์มฮาร์ดแวร์ ของคุณไม่ได้ โปรดดูรายละเอียดเกี่ยวกับการสร้าง GSI สำหรับเป้าหมายที่เฉพาะเจาะจงในส่วนต่อไปนี้

สร้าง GSI

ตั้งแต่ Android 9 เป็นต้นมา Android แต่ละเวอร์ชันจะมี สาขา GSI ชื่อ DESSERT-gsi ใน AOSP (เช่น android12-gsi คือสาขา GSI ใน Android 12) สาขา GSI มีเนื้อหาของ Android พร้อม แพตช์ความปลอดภัย และ แพตช์ GSI ทั้งหมด

หากต้องการสร้าง GSI ให้ตั้งค่าแผนผังซอร์สโค้ด Android โดย ดาวน์โหลดจาก Branch GSI และ เลือกเป้าหมายบิลด์ GSI ใช้ตารางเป้าหมายบิลด์ด้านล่างเพื่อกำหนดเวอร์ชัน GSI ที่ถูกต้องสำหรับอุปกรณ์ หลังจากบิลด์เสร็จสมบูรณ์แล้ว GSI จะเป็นอิมเมจระบบ (นั่นคือ system.img) และจะปรากฏในโฟลเดอร์เอาต์พุต out/target/product/generic_arm64

ตัวอย่างเช่น หากต้องการสร้างเป้าหมายบิลด์ GSI gsi_arm64-userdebug ใน Branch GSI android12-gsi, ให้เรียกใช้คำสั่งต่อไปนี้

$ repo init -u https://android.googlesource.com/platform/manifest -b android12-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch gsi_arm64-userdebug
$ make -j4

เป้าหมายบิลด์ GSI ของ Android

เป้าหมายบิลด์ GSI ต่อไปนี้มีไว้สำหรับอุปกรณ์ที่เปิดตัวใน Android 9 ขึ้นไป

ชื่อ GSI สถาปัตยกรรม CPU ความกว้างของบิตอินเทอร์เฟซ Binder System-as-root เป้าหมายบิลด์
gsi_arm กลุ่ม 32 Y gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Y gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 32 Y gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86-64 64 Y gsi_x86_64-user
gsi_x86_64-userdebug

ข้อกำหนดสำหรับการแฟลช GSI

อุปกรณ์ Android อาจมีการออกแบบที่แตกต่างกัน ดังนั้นจึงไม่มีคำสั่งหรือ ชุดวิธีการทั่วไปสำหรับการแฟลช GSI เพื่อใช้กับอุปกรณ์ทั้งหมด โปรดตรวจสอบวิธีการแฟลชที่ชัดเจนกับผู้ผลิตอุปกรณ์ Android และใช้ขั้นตอนต่อไปนี้เป็นหลักเกณฑ์ทั่วไป

  1. ตรวจสอบว่าอุปกรณ์มีคุณสมบัติดังนี้
    • ใช้ Treble
    • มีวิธีปลดล็อกอุปกรณ์ (เพื่อให้แฟลชโดยใช้ fastboot ได้)
    • อยู่ในสถานะปลดล็อกเพื่อให้แฟลชผ่าน fastboot (ตรวจสอบว่าคุณมี fastboot เวอร์ชันล่าสุดโดยสร้าง จากแผนผังซอร์สโค้ด Android)
  2. ลบพาร์ทิชันระบบปัจจุบัน แล้วแฟลช GSI ลงในพาร์ทิชันระบบ
  3. ล้างข้อมูลผู้ใช้และล้างข้อมูลจากพาร์ทิชันอื่นๆ ที่จำเป็น (เช่น พาร์ทิชันข้อมูลผู้ใช้และพาร์ทิชันระบบ)
  4. รีบูตอุปกรณ์

ตัวอย่างเช่น หากต้องการแฟลช GSI ลงในอุปกรณ์ Pixel ให้ทำดังนี้

  1. บูตเข้าสู่ fastboot โหมด และ ปลดล็อก Bootloader.
  2. อุปกรณ์ที่รองรับ fastbootd จะต้องบูตเข้าสู่ fastbootd ด้วยการทำดังนี้
    $ fastboot reboot fastboot
  3. ลบและแฟลช GSI ลงในพาร์ทิชันระบบ
    $ fastboot erase system
    $ fastboot flash system system.img
  4. หากอุปกรณ์รองรับ Android Virtual Framework ให้แฟลชเฟิร์มแวร์ Protected Virtual Machine
    $ fastboot flash pvmfw pvmfw.img
    
  5. ล้างข้อมูลผู้ใช้และล้างข้อมูลจากพาร์ทิชันอื่นๆ ที่จำเป็น (สำหรับ ตัวอย่าง พาร์ทิชันข้อมูลผู้ใช้และพาร์ทิชันระบบ)
    $ fastboot -w
  6. รีบูตกลับเข้าสู่ Bootloader
    $ fastboot reboot-bootloader
  7. ปิดใช้การยืนยันการเปิดเครื่องที่ได้รับการยืนยันขณะแฟลช vbmeta ที่ให้ไว้
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  8. Reboot:
    $ fastboot reboot
ในอุปกรณ์ Android 10 ขึ้นไปที่มีพาร์ทิชันระบบขนาดเล็กกว่า ข้อความแสดงข้อผิดพลาดต่อไปนี้อาจปรากฏขึ้นเมื่อแฟลช GSI
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
ใช้คำสั่งต่อไปนี้เพื่อลบพาร์ทิชันผลิตภัณฑ์และเพิ่มพื้นที่ว่างสำหรับพาร์ทิชันระบบ ซึ่งจะเพิ่มพื้นที่ว่างสำหรับการแฟลช GSI
$ fastboot delete-logical-partition product_a
คำต่อท้าย _a ควรตรงกับรหัสสล็อตของพาร์ทิชันระบบ เช่น system_a ในตัวอย่างนี้

มีส่วนร่วมในการพัฒนา GSI

Android ยินดีรับการมีส่วนร่วมของคุณในการพัฒนา GSI คุณสามารถมีส่วนร่วม และช่วยปรับปรุง GSI ได้โดยทำดังนี้

  • สร้างแพตช์ GSI DESSERT-gsi ไม่ใช่ สาขาการพัฒนา และยอมรับเฉพาะ Cherrypick จาก สาขาการเผยแพร่ล่าสุดของ AOSP (android17-release) ดังนั้นหากต้องการส่งแพตช์ GSI คุณต้องทำดังนี้:
    1. ส่งแพตช์ไปยังสาขา AOSP android17-release
    2. Cherrypick แพตช์ไปยัง DESSERT-gsi
    3. ยื่นรายงานข้อบกพร่องเพื่อให้มีการตรวจสอบ Cherrypick
  • รายงานข้อบกพร่องของ GSI หรือให้คำแนะนำอื่นๆ อ่านวิธีการในหัวข้อการรายงานข้อบกพร่อง แล้วเรียกดูหรือยื่นรายงานข้อบกพร่องของGSI

เคล็ดลับ

เปลี่ยนโหมดแถบนำทางโดยใช้ adb

เมื่อบูตด้วย GSI ผู้ผลิตจะเป็นผู้กำหนดค่าโหมดแถบนำทาง คุณสามารถ เปลี่ยนโหมดแถบนำทางได้โดยเรียกใช้คำสั่ง adb ต่อไปนี้ระหว่างรันไทม์

adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode

โดย mode อาจเป็น threebutton, twobutton, gestural และอื่นๆ