Google มุ่งมั่นที่จะพัฒนาความเท่าเทียมทางเชื้อชาติสำหรับชุมชนคนผิวดำ มาดูกันว่า
หน้านี้ได้รับการแปลโดย Cloud Translation API
Switch to English

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

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

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

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

การกำหนดค่าและความแปรปรวนของ GSI

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

  • ตรีคูณ GSI รวมถึงการสนับสนุนอย่างเต็มที่สำหรับการ เปลี่ยนแปลงสถาปัตยกรรมที่ใช้ HIDL (หรือที่รู้จักกันในชื่อ Treble ) ซึ่งเปิดตัวใน Android 8.0 รวมถึงการรองรับ อินเตอร์เฟส HIDL คุณสามารถใช้ GSI บนอุปกรณ์ Android ใด ๆ ที่ใช้อินเทอร์เฟซผู้ขาย HIDL (สำหรับรายละเอียดเพิ่มเติมดู ทรัพยากรสถาปัตยกรรม )
  • ตรวจสอบการบูต GSI ไม่ได้รวมโซลูชันการตรวจสอบการบู๊ต (เช่น vboot 1.0 หรือ AVB ) หากต้องการแฟลช GSI ไปยังอุปกรณ์ที่เปิดตัวใน Android 9 หรือรุ่นก่อนหน้าอุปกรณ์จะต้องมีวิธีปิดใช้งานการตรวจสอบการบูต
  • ระบบไฟล์ GSI ใช้ระบบไฟล์ ext4
  • เค้าโครงพาร์ติชัน GSI ใช้โครงร่างพาร์ติชัน ระบบเป็นรู

Android GSI ปัจจุบันมีความแปรปรวนหลักดังต่อไปนี้:

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

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

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

ประเภทอุปกรณ์ สร้างเป้าหมาย
อุปกรณ์ที่เปิดตัวพร้อม Android 10 aosp_$arch-user
อุปกรณ์ที่เปิดตัวพร้อมกับ Android 9 aosp_$arch-userdebug
อุปกรณ์ที่เปิดตัวพร้อมกับ Android 8.0 หรือ Android 8.1 aosp_$arch_ab-userdebug

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

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

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

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

ในการทดสอบอุปกรณ์ที่เปิดตัวใน Android 9 หรือ 10 ด้วย CTS-on-GSI ให้ใช้ เป้าหมายการสร้าง Android GSI

GSI ดั้งเดิม

GSIs ดั้งเดิมที่ตั้งชื่อด้วยส่วนต่อท้าย _ab (ตัวอย่างเช่น aosp_arm64_ab ) GSIs เหล่านี้สร้างขึ้นจากต้นกำเนิด Android 10 แต่มีการกำหนดค่าที่เข้ากันได้แบบย้อนหลังสำหรับอุปกรณ์ที่อัปเกรดจาก Android 8 หรือ 8.1:

  • userspace แบบ 32 บิต + ส่วนต่อประสาน binder 32 บิต GSIs แบบ 32 บิตสามารถใช้อินเตอร์เฟส Binder แบบต่อเนื่องได้
  • 8.1 VNDK อุปกรณ์สามารถใช้ 8.1 VNDK ที่ให้มา
  • เมานต์ไดเรกทอรี อุปกรณ์ดั้งเดิมบางตัวใช้ไดเรกทอรีเป็นตัวชี้เมานต์ (ตัวอย่างเช่น /bluetooth , /firmware/radio , และ /persist )

ในการทดสอบอุปกรณ์ที่เปิดตัวบน Android 8 หรือ 8.1 ด้วย CTS-on-GSI ให้ใช้ Legacy GSI build เป้าหมาย

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

Android 9 GSIs รวมการเปลี่ยนแปลงที่สำคัญต่อไปนี้จาก GSIs ก่อนหน้า:

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

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

ใน 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 ที่ ฮาร์ดแวร์สำรอง

ไบนารีผู้ขายและการพึ่งพา VNDK

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

ใช้กรณี ผู้ขาย
ไบนารี
รุ่น
BOARD_VNDK_VERSION GSI ดั้งเดิม
เวอร์ชันไบนารีระบบ
การสนับสนุน GSI ดั้งเดิม
0 8.0 (ใด ๆ ) 10 ไม่
1 8.1 (ว่าง) 10 ไม่
2 8.1 current 10 ใช่
3 10 current 10 ใช่

กรณีการใช้งานที่ได้รับการสนับสนุนที่พบมากที่สุดคือ # 2 ซึ่งอุปกรณ์สนับสนุน GSIs ดั้งเดิมที่ใช้ Android 8.1 ซึ่งสร้างขึ้นด้วย BOARD_VNDK_VERSION จะถูกตั้งค่าเป็น current

ไม่รองรับเคส # 1 ในกรณีนี้ GSIs ดั้งเดิมไม่รองรับอุปกรณ์ที่ใช้ Android 8.1 โดยไม่ BOARD_VNDK_VERSION มี BOARD_VNDK_VERSION จากการสร้าง ไม่สามารถรองรับอุปกรณ์เหล่านี้ได้เนื่องจากไบนารีผู้จำหน่ายของพวกเขาขึ้นอยู่กับห้องสมุดที่ใช้ร่วมกันของ Android 8.1 ที่ไม่ใช่ VNDK ซึ่งไม่รวมอยู่ใน GSIs ดั้งเดิม ในการทำให้อุปกรณ์เหล่านี้ใช้งานร่วมกับ GSI รุ่นเก่าได้คุณต้องทำอย่างใดอย่างหนึ่งต่อไปนี้:

  • เปิดใช้งาน BOARD_VNDK_VERSION โดยไม่ใช้ BOARD_VNDK_RUNTIME_DISABLE (ใช้ตัวพิมพ์ # 2)

    หรือ

  • พอร์ต / อัปเกรดไบนารีของผู้จัดจำหน่ายเพื่อพึ่งพาไลบรารีที่แชร์จาก Android 10 (ใช้กรณี # 3)

กำลังดาวน์โหลด GSIs

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

อาคาร GSIs

เริ่มต้นด้วย Android 9 แต่ละรุ่น Android มีสาขา GSI ชื่อ DESSERT -gsi บน AOSP (ตัวอย่างเช่น android10-gsi เป็นสาขา GSI บน Android 10) สาขา GSI รวมถึงเนื้อหาของ Android ที่มีโปรแกรม รักษาความปลอดภัย ทั้งหมดและใช้โปรแกรมแก้ไข GSI

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

ตัวอย่างเช่นหากต้องการสร้าง GSI build เป้าหมาย aosp_arm64-userdebug บนสาขา GSI android10-gsi ให้รันคำสั่งต่อไปนี้

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

Android GSI สร้างเป้าหมาย

เป้าหมายการสร้าง GSI ต่อไปนี้มีไว้สำหรับอุปกรณ์ที่เปิดตัวใน Android 9 หรือสูงกว่า เนื่องจากการลดความแปรปรวนระหว่างสถาปัตยกรรม Android 10 จึงรวมผลิตภัณฑ์ GSI เพียงสี่รายการเท่านั้น

ชื่อ GSI CPU arch เป็นพยานในการเชื่อมต่อ Binder ระบบเป็นราก สร้างเป้าหมาย
aosp_arm แขน 64 Y aosp_arm-user
aosp_arm-userdebug
aosp_arm64 ARM64 64 Y aosp_arm64-user
aosp_arm64-userdebug
aosp_x86 x86 64 Y aosp_x86-user
aosp_x86-userdebug
aosp_x86_64 x86-64 64 Y aosp_x86_64-user
aosp_x86_64-userdebug

GSI ดั้งเดิมสร้างเป้าหมาย

GSI build เป้าหมายดั้งเดิมต่อไปนี้สำหรับอุปกรณ์ที่อัพเกรดจาก Android 8.0 หรือ 8.1 เป็น Android 10. ชื่อ GSI ดั้งเดิมประกอบด้วยส่วนต่อท้าย _ab เพื่อแยกความแตกต่างจากชื่อ Android 10 GSI

ชื่อ GSI CPU arch เป็นพยานในการเชื่อมต่อ Binder ระบบเป็นราก สร้างเป้าหมาย
aosp_arm_ab แขน 32 Y aosp_arm_ab-userdebug
aosp_arm_64b_ab แขน 64 Y aosp_arm_64b_ab-userdebug
aosp_arm64_ab ARM64 64 Y aosp_arm64_ab-userdebug
aosp_x86_ab x86 32 Y aosp_x86_ab-userdebug
aosp_x86_64_ab x86-64 64 Y aosp_x86_64_ab-userdebug

ข้อกำหนดสำหรับการกระพริบ GSIs

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

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

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

  1. Boot ไปที่โหมด fastboot และ ปลดล็อค bootloader อุปกรณ์ที่รองรับ fastbootd นั้นจำเป็นต้องบู๊ตเป็น fastbootd ด้วย:
    $ fastboot reboot fastboot
  2. ปิดการใช้งานตรวจสอบการบูต (AVB) โดยการกระพริบ vbmeta.img :
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  3. ลบและแฟลช GSI ไปยังพาร์ติชันระบบ:
    $ fastboot erase system
    $ fastboot flash system system.img
    
  4. ล้างข้อมูลผู้ใช้และล้างข้อมูลจากพาร์ติชันที่จำเป็นอื่น ๆ (ตัวอย่างเช่นข้อมูลผู้ใช้และพาร์ติชันระบบ):
    $ fastboot -w
  5. 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
postfix _a ควรตรงกับ slot slot ของพาร์ติชันระบบเช่น system_a ในตัวอย่างนี้

บริจาคให้ GSIs

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

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

เคล็ดลับ

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

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

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

โดยที่ mode สามารถเป็น threebutton , twobutton , gestural และอื่น ๆ