อิมเมจระบบที่แชร์

หน้านี้แสดงกลไกหลายอย่างที่ OEM ของ Android สามารถใช้เพื่อมี อิมเมจระบบที่ใช้ร่วมกัน (SSI) ในกลุ่มผลิตภัณฑ์ต่างๆ นอกจากนี้ ยังเสนอขั้นตอนการใช้ SSI ที่ OEM เป็นเจ้าของโดยอิงตามอิมเมจระบบทั่วไป (GSI) ที่สร้างขึ้นจาก AOSP

ฉากหลัง

เฟรมเวิร์กของโครงการโอเพนซอร์ส Android (AOSP) เป็นไปตามสถาปัตยกรรม Mainline เพื่อรักษาความเข้ากันได้แบบย้อนหลังกับการติดตั้งใช้งานของผู้ให้บริการรุ่นเก่า เช่น อิมเมจระบบทั่วไป (GSI) ที่สร้างจากแหล่งที่มาของ AOSP ใน Android 10 สามารถทำงานในอุปกรณ์ที่รองรับ Treble ซึ่งใช้ Android 8 ขึ้นไป

Mainline ทำได้โดยการแยก Android ออกเป็น 2 ส่วนที่แตกต่างกัน ได้แก่ การใช้งานของผู้ให้บริการที่เฉพาะเจาะจงกับฮาร์ดแวร์และเฟรมเวิร์กระบบปฏิบัติการ Android ทั่วไป โดยจะติดตั้งคอมโพเนนต์แต่ละรายการในพาร์ติชันแยกต่างหาก ได้แก่ พาร์ติชันของผู้ให้บริการสำหรับ ซอฟต์แวร์เฉพาะฮาร์ดแวร์ และพาร์ติชันของระบบสำหรับระบบปฏิบัติการทั่วไป มีการบังคับใช้ อินเทอร์เฟซที่มีการควบคุมเวอร์ชันที่เรียกว่าอินเทอร์เฟซของผู้ให้บริการ (VINTF) ระหว่างทั้ง 2 ส่วน ระบบการแบ่งพาร์ติชันนี้ช่วยให้ OEM แก้ไขพาร์ติชันระบบ โดยไม่ต้องแตะต้องพาร์ติชันของผู้ให้บริการ และในทางกลับกัน

ในอดีต ผู้ให้บริการ SoC และ OEM ได้แก้ไขเฟรมเวิร์ก Android เวอร์ชันที่จัดส่งในอุปกรณ์สำหรับผู้บริโภคอย่างมาก (ดูรายละเอียดได้ที่วงจรการเปิดตัว Android) เนื่องจากส่วนขยายเฟรมเวิร์กเหล่านี้มักไม่ได้ออกแบบโดยคำนึงถึง การทำงานร่วมกันกับเวอร์ชันก่อนหน้า การแก้ไขเฉพาะอุปกรณ์จึงเพิ่มความซับซ้อนและต้นทุนทางการเงินของการอัปเกรดระบบปฏิบัติการในภายหลังอย่างมาก ใน Android 10 (API ระดับ 29) และต่ำกว่านั้น ระบบนิเวศยังไม่มีสถาปัตยกรรมที่ชัดเจนและเป็นมาตรฐาน ซึ่งช่วยให้พาร์ทเนอร์สร้างส่วนขยายแบบโมดูลาร์ไปยังเฟรมเวิร์ก Android ได้

หน้านี้อธิบายวิธีที่ผู้ให้บริการ SoC และ OEM สามารถสร้างอิมเมจระบบที่ใช้ร่วมกัน (SSI) SSI คืออิมเมจเฟรมเวิร์กแบบรวมที่สร้างจากแหล่งที่มาของ Android OS ซึ่ง สามารถนำไปใช้ซ้ำในอุปกรณ์หลายเครื่องได้ การรักษาความเข้ากันได้แบบย้อนหลังที่สะอาดกับ การติดตั้งใช้งานของผู้ให้บริการผ่านสถาปัตยกรรมที่แบ่งพาร์ติชันนี้ SSI จะช่วยลดต้นทุนและความซับซ้อนของการอัปเกรด Android OS ได้อย่างมาก

ดูรายละเอียดการนำไปใช้งานได้ที่ขั้นตอนที่แนะนำสำหรับ SSI ที่อิงตาม GSI ขั้นตอนต่างๆ เป็นแบบแยกส่วน คุณสามารถเลือกใช้ ขั้นตอนที่เฉพาะเจาะจง (เช่น ขั้นตอนที่ 1: รับช่วง generic_system.mk สำหรับอิมเมจระบบ OEM (OEM GSI)) แทนที่จะใช้ทุกขั้นตอน ทั้งนี้ขึ้นอยู่กับสถาปัตยกรรมของคุณ

ภาพรวม SSI

เมื่อใช้ SSI ระบบจะวางคอมโพเนนต์ซอฟต์แวร์เฉพาะผลิตภัณฑ์และส่วนขยาย OEM ไว้ในพาร์ติชัน /product ใหม่ คอมโพเนนต์ในพาร์ติชัน /product ใช้ อินเทอร์เฟซที่เสถียรและกำหนดไว้อย่างดีเพื่อโต้ตอบกับคอมโพเนนต์ในพาร์ติชัน /system OEM สามารถเลือกสร้าง SSI เพียงรายการเดียว หรือมี SSI จำนวนเล็กน้อยเพื่อใช้ใน SKU ของอุปกรณ์หลายรายการ เมื่อมีการเผยแพร่ระบบปฏิบัติการ Android เวอร์ชันใหม่ ผู้ผลิตอุปกรณ์จะลงทุนเพียงครั้งเดียวในการอัปเดต SSI เป็น Android เวอร์ชันล่าสุด โดยสามารถนำ SSI กลับมาใช้ใหม่เพื่ออัปเดตอุปกรณ์หลายเครื่องได้โดยไม่ต้องอัปเดตพาร์ติชัน /product

OEM และผู้ให้บริการ SoC สามารถสร้าง SSI ที่มีฟีเจอร์และการแก้ไขที่กำหนดเองได้ กลไกและแนวทางปฏิบัติแนะนำที่ระบุไว้ในหน้านี้มีไว้เพื่อให้ OEM ใช้เพื่อบรรลุเป้าหมายสำคัญต่อไปนี้

• นำ SSI กลับมาใช้ใหม่ใน SKU ของอุปกรณ์หลายรายการ
• อัปเดตระบบ Android ด้วยส่วนขยายแบบโมดูลเพื่อให้การอัปเกรดระบบปฏิบัติการ ง่ายขึ้น

แนวคิดหลักในการแยกคอมโพเนนต์เฉพาะผลิตภัณฑ์ออกเป็นพาร์ติชันผลิตภัณฑ์ คล้ายกับการแยกคอมโพเนนต์เฉพาะ SoC ออกเป็นพาร์ติชันของผู้ ให้บริการของ Mainline อินเทอร์เฟซผลิตภัณฑ์ (คล้ายกับ VINTF) ช่วยให้ การสื่อสารระหว่าง SSI กับพาร์ติชันผลิตภัณฑ์เป็นไปได้ ในส่วนของ SSI คำว่าคอมโพเนนต์อธิบายทรัพยากร ไบนารี ข้อความ และไลบรารีทั้งหมด ที่ติดตั้งลงในอิมเมจ ซึ่งจะกลายเป็นพาร์ติชัน

พาร์ติชันรอบ SSI

รูปที่ 1 แสดงพาร์ติชันรอบ SSI และอินเทอร์เฟซที่มีการควบคุมเวอร์ชันใน พาร์ติชันและนโยบายในอินเทอร์เฟซ ส่วนนี้จะอธิบายรายละเอียดของแต่ละ พาร์ติชันและอินเทอร์เฟซ

รูปที่ 1 พาร์ติชันและอินเทอร์เฟซรอบๆ SSI

รูปภาพและพาร์ติชัน

ข้อมูลในส่วนนี้จะแยกความแตกต่างระหว่างคำว่าอิมเมจและพาร์ติชัน

• อิมเมจคือซอฟต์แวร์เชิงแนวคิดที่อัปเดตแยกกันได้
• พาร์ติชันคือตำแหน่งที่ตั้งจริงของพื้นที่เก็บข้อมูลที่อัปเดต แยกกันได้

ส่วนต่างๆ ในรูปที่ 1 มีคำจำกัดความดังนี้

• SSI: รูปภาพที่ใช้ร่วมกันใน OEM และอาจมีอยู่ในอุปกรณ์หลายเครื่อง ไม่มีคอมโพเนนต์ที่เฉพาะเจาะจงกับฮาร์ดแวร์หรือผลิตภัณฑ์ ทุกอย่างใน SSI ที่กำหนดจะแชร์ในอุปกรณ์ทั้งหมดที่ใช้ SSI นั้นตามคำจำกัดความ SSI ประกอบด้วย/systemรูปภาพเดียวหรือ/systemและพาร์ติชัน/system_ext

• รูปภาพผลิตภัณฑ์: ชุดคอมโพเนนต์เฉพาะผลิตภัณฑ์หรืออุปกรณ์ ที่แสดงถึงการปรับแต่งและการขยาย OEM ในระบบปฏิบัติการ Android ใส่คอมโพเนนต์เฉพาะ SoC ในพาร์ติชัน /vendor ผู้ให้บริการ SoC ยังใช้/productพาร์ติชันสำหรับคอมโพเนนต์ที่เหมาะสมได้ด้วย เช่น คอมโพเนนต์ที่ไม่ขึ้นอยู่กับ SoC เช่น หากผู้จำหน่าย SoC จัดหาคอมโพเนนต์ที่ไม่ขึ้นอยู่กับ SoC ให้แก่ ลูกค้า OEM (ซึ่งเป็นตัวเลือกในการจัดส่งพร้อมผลิตภัณฑ์) ผู้จำหน่าย SoC จะวางคอมโพเนนต์ดังกล่าวในรูปภาพผลิตภัณฑ์ได้ ตำแหน่งของคอมโพเนนต์จะกำหนดตามวัตถุประสงค์ ไม่ใช่ความเป็นเจ้าของ

• รูปภาพของผู้ให้บริการ: ชุดคอมโพเนนต์เฉพาะ SoC

• รูปภาพ ODM: ชุดคอมโพเนนต์เฉพาะบอร์ดที่ SoC ไม่ได้ให้มา โดยปกติแล้วผู้จำหน่าย SoC จะเป็นเจ้าของรูปภาพของผู้จำหน่าย ในขณะที่ผู้ผลิตอุปกรณ์จะเป็นเจ้าของรูปภาพ ODM เมื่อไม่มี/odm พาร์ติชันแยกกัน ทั้งรูปภาพของผู้จำหน่าย SoC และรูปภาพ ODM จะรวมกันในพาร์ติชัน /vendor

พาร์ติชัน /system_ext

/system_ext พาร์ติชันเป็นพาร์ติชันที่ไม่บังคับ ใช้พาร์ติชันนี้สำหรับฟีเจอร์และส่วนขยายที่กำหนดเองซึ่งเชื่อมโยงอย่างใกล้ชิดกับคอมโพเนนต์ที่อิงตาม AOSP พาร์ติชันนี้ถือเป็นส่วนขยายเฉพาะ OEM ของพาร์ติชัน /system โดยไม่มีอินเทอร์เฟซที่กำหนดไว้ใน 2 พาร์ติชัน คอมโพเนนต์ในพาร์ติชัน /system_ext สามารถเรียกใช้ API ส่วนตัวในพาร์ติชัน /system และคอมโพเนนต์ในพาร์ติชัน /system สามารถเรียกใช้ API ส่วนตัวในพาร์ติชัน /system_ext

เนื่องจากพาร์ติชันทั้ง 2 เชื่อมโยงกันอย่างใกล้ชิด ระบบจึงจะอัปเกรดทั้ง 2 พาร์ติชัน พร้อมกันเมื่อมีการเปิดตัว Android เวอร์ชันใหม่ /system_extพาร์ติชัน ที่สร้างขึ้นสำหรับ Android เวอร์ชันก่อนหน้าไม่จำเป็นต้องใช้ร่วมกับ/systemพาร์ติชันใน Android เวอร์ชันถัดไปได้

หากต้องการติดตั้งโมดูลในพาร์ติชัน /system_ext ให้เพิ่ม system_ext_specific: true ลงในไฟล์ Android.bp ในอุปกรณ์ที่ไม่มี/system_ext พาร์ติชัน ให้ติดตั้งโมดูลดังกล่าวลงในไดเรกทอรีย่อย ./system_ext ในพาร์ติชัน /system

ประวัติ: เป้าหมายการออกแบบดั้งเดิมของพาร์ติชัน /system_ext คือการวางคอมโพเนนต์ทั้งหมดที่เฉพาะเจาะจงสำหรับ OEM ไม่ว่าจะเป็นคอมโพเนนต์ทั่วไปหรือไม่ก็ตาม ไว้ในพาร์ติชัน /product อย่างไรก็ตาม การย้ายคอมโพเนนต์ทั้งหมดพร้อมกันนั้นเป็นไปไม่ได้ โดยเฉพาะอย่างยิ่งเมื่อคอมโพเนนต์บางรายการมีการเชื่อมโยงอย่างแน่นแฟ้นกับพาร์ติชัน /system หากต้องการย้ายคอมโพเนนต์ที่มีการเชื่อมโยงอย่างแน่นแฟ้นไปยังพาร์ติชัน /product จะต้องขยายอินเทอร์เฟซผลิตภัณฑ์ ซึ่งมักจะต้องมีการปรับโครงสร้างคอมโพเนนต์อย่างกว้างขวาง ซึ่งต้องใช้เวลาและความพยายามเป็นอย่างมาก พาร์ติชัน /system_ext เริ่มต้นจากการเป็นที่สำหรับโฮสต์คอมโพเนนต์ชั่วคราวซึ่งยังไม่พร้อมที่จะย้ายไปยังพาร์ติชัน /product เป้าหมายของ SSI คือการกำจัดพาร์ติชัน /system_ext ในที่สุด

อย่างไรก็ตาม พาร์ติชัน /system_ext มีประโยชน์ในการทำให้พาร์ติชัน /system ใกล้เคียงกับ AOSP มากที่สุด เมื่อใช้ SSI ความพยายามส่วนใหญ่ในการอัปเกรดจะ มุ่งเน้นไปที่คอมโพเนนต์ในพาร์ติชัน /system และ /system_ext เมื่อสร้างอิมเมจระบบจากแหล่งที่มาที่คล้ายกับแหล่งที่มาใน AOSP มากที่สุด คุณจะมุ่งเน้นความพยายามในการอัปเกรดไปที่อิมเมจ system_ext ได้

อินเทอร์เฟซระหว่างรูปภาพ

SSI มีอินเทอร์เฟซหลัก 2 อย่างสำหรับรูปภาพของผู้ขายและผลิตภัณฑ์

• อินเทอร์เฟซของผู้ให้บริการ (VINTF): VINTF เป็นอินเทอร์เฟซสำหรับคอมโพเนนต์ที่อยู่ในอิมเมจของผู้ให้บริการและ ODM คอมโพเนนต์ในอิมเมจผลิตภัณฑ์และอิมเมจระบบจะโต้ตอบกับอิมเมจของผู้ให้บริการและ ODM ได้ผ่านอินเทอร์เฟซนี้เท่านั้น เช่น อิมเมจของผู้ให้บริการจะขึ้นอยู่กับส่วนส่วนตัวของอิมเมจระบบไม่ได้ และในทางกลับกันก็เช่นกัน ซึ่งกำหนดไว้ในสถาปัตยกรรม Treble (ปัจจุบันเป็นส่วนหนึ่งของสถาปัตยกรรม Mainline ที่กว้างขึ้น) ซึ่งแยกอิมเมจออกเป็นพาร์ติชันระบบและพาร์ติชันของผู้ให้บริการ อินเทอร์เฟซจะอธิบายโดยใช้กลไกต่อไปนี้

  • HIDL (Passthrough HAL ใช้ได้เฉพาะกับโมดูล system และ system_ext )
  • AIDL ที่เสถียร
  • การกำหนดค่า
    • API ของพร็อพเพอร์ตี้ของระบบ
    • API สคีมาไฟล์การกำหนดค่า
  • VNDK
  • API ของ Android SDK
  • ไลบรารี Java SDK

• อินเทอร์เฟซผลิตภัณฑ์: อินเทอร์เฟซผลิตภัณฑ์คืออินเทอร์เฟซระหว่าง SSI กับรูปภาพสินค้า การกำหนดอินเทอร์เฟซที่เสถียรจะแยกส่วนประกอบของผลิตภัณฑ์ ออกจากส่วนประกอบของระบบใน SSI

เปิดใช้ SSI

ส่วนนี้จะอธิบายวิธีรองรับ SSI ใน Android 11 ขึ้นไป

แยกคอมโพเนนต์

หากต้องการแยก/productพาร์ติชันออกจากคอมโพเนนต์ของระบบ /product พาร์ติชันต้องมีนโยบายการบังคับใช้เดียวกันกับ/vendorพาร์ติชันที่ แยกออกจาก Mainline แล้ว

• อินเทอร์เฟซในตัว: โมดูลในตัวในพาร์ติชัน /product ต้องแยกออกจากพาร์ติชันอื่นๆ Dependency ที่อนุญาตจากโมดูลผลิตภัณฑ์มีเพียงไลบรารี VNDK บางรายการ (รวมถึง LLNDK) จากพาร์ติชัน /system ไลบรารี JNI ที่แอปผลิตภัณฑ์ขึ้นต่อกันต้องเป็นไลบรารี NDK
• อินเทอร์เฟซ Java: โมดูล Java (แอป) ในพาร์ติชัน /product ใช้ API ที่ซ่อนอยู่ไม่ได้เนื่องจากไม่เสถียร โมดูลเหล่านี้ต้องใช้เฉพาะ API สาธารณะและ API ของระบบจากพาร์ติชัน /system รวมถึงไลบรารี Java SDK ในพาร์ติชัน /system หรือ /system_ext คุณสามารถกำหนดไลบรารี Java SDK สำหรับ API ที่กำหนดเองได้

บังคับใช้อินเทอร์เฟซผลิตภัณฑ์

เพื่อให้แน่ใจว่า/productพาร์ติชันไม่ได้รวมอยู่ด้วย OEM สามารถกำหนดให้อุปกรณ์บังคับใช้อินเทอร์เฟซผลิตภัณฑ์ได้โดยการตั้งค่า PRODUCT_PRODUCT_VNDK_VERSION:= currentสำหรับโมดูลในตัว และ PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= trueสำหรับโมดูล Java ระบบจะตั้งค่าตัวแปรเหล่านี้โดยอัตโนมัติหาก PRODUCT_SHIPPING_API_LEVEL ของ อุปกรณ์มากกว่าหรือเท่ากับ 30 ดูข้อมูลโดยละเอียดได้ที่ บังคับใช้อินเทอร์เฟซพาร์ติชันผลิตภัณฑ์

ขั้นตอนที่แนะนำสำหรับ SSI ที่อิงตาม GSI

รูปที่ 2 พาร์ติชันที่แนะนำสำหรับ SSI ที่อิงตาม GSI

อิมเมจระบบทั่วไป (GSI) คืออิมเมจระบบที่สร้างขึ้นจาก AOSP โดยตรง โดยใช้สำหรับการทดสอบการปฏิบัติตามข้อกำหนด (เช่น CTS-on-GSI) และเป็น แพลตฟอร์มการอ้างอิงที่นักพัฒนาแอปใช้เพื่อทดสอบความเข้ากันได้ของ แอปเมื่อไม่มีอุปกรณ์จริงที่ใช้ Android เวอร์ชันที่จำเป็น

นอกจากนี้ OEM ยังใช้ GSI เพื่อสร้าง SSI ได้ด้วย ดังที่อธิบายไว้ในรูปภาพและ พาร์ติชัน SSI ประกอบด้วยอิมเมจระบบสำหรับคอมโพเนนต์ที่กำหนดโดย AOSP และอิมเมจ system_ext สำหรับคอมโพเนนต์ที่กำหนดโดย OEM เมื่อใช้ GSI เป็นsystem รูปภาพ OEM จะมุ่งเน้นที่system_ext รูปภาพสำหรับการอัปเกรดได้

ส่วนนี้ให้คำแนะนำแก่ OEM ที่ต้องการแยกการปรับแต่งออกเป็นโมดูลในพาร์ติชัน /system_ext และ /product ขณะที่ใช้รูปภาพระบบ AOSP หรือรูปภาพระบบที่ใกล้เคียงกับ AOSP หาก OEM สร้างรูปภาพระบบจากแหล่งที่มาของ AOSP ก็จะแทนที่รูปภาพระบบที่สร้างด้วย GSI ที่ AOSP จัดหาให้ได้ อย่างไรก็ตาม OEM ไม่จำเป็นต้องทำตามขั้นตอนสุดท้าย (ใช้ GSI ตามที่เป็นอยู่) ทั้งหมดในคราวเดียว

ขั้นตอนที่ 1: รับค่า generic_system.mk สำหรับอิมเมจระบบ OEM (GSI ของ OEM)

การรับค่า generic_system.mk (ซึ่งมีชื่อว่า mainline_system.mk ใน Android 11 และเปลี่ยนชื่อเป็น generic_system.mk ใน AOSP) ทำให้อิมเมจระบบ (OEM GSI) มีไฟล์ทั้งหมดที่ AOSP GSI มี OEM สามารถแก้ไขไฟล์เหล่านี้ได้ เพื่อให้ GSI ของ OEM มีไฟล์ที่เป็นกรรมสิทธิ์ของ OEM นอกเหนือจากไฟล์ GSI ของ AOSP

รูปที่ 3 รับค่า generic_system.mk สำหรับอิมเมจระบบของ OEM

ขั้นตอนที่ 2: ทำให้ GSI ของ OEM มีรายการไฟล์เดียวกันกับ GSI ของ AOSP

GSI ของ OEM จะมีไฟล์เพิ่มเติมในขั้นตอนนี้ไม่ได้ ดังนั้นให้ย้ายไฟล์ที่เป็นกรรมสิทธิ์ของ OEM ไปยังพาร์ติชัน system_ext หรือ product

รูปที่ 4 ย้ายไฟล์ที่เพิ่มออกจาก GSI ของ OEM

ขั้นตอนที่ 3: กำหนดรายการที่อนุญาตเพื่อจำกัดไฟล์ที่แก้ไขใน GSI ของ OEM

หากต้องการตรวจสอบไฟล์ที่แก้ไข OEM สามารถใช้เครื่องมือ compare_images และ เปรียบเทียบ GSI ของ AOSP กับ GSI ของ OEM รับ GSI ของ AOSP จากเป้าหมาย lunch ของ AOSP generic_system_*

การเรียกใช้เครื่องมือ compare_images เป็นระยะๆ ด้วยพารามิเตอร์ allowlist จะช่วยให้คุณตรวจสอบความแตกต่างนอกรายการที่อนุญาตได้ ซึ่งจะช่วยป้องกันการแก้ไขเพิ่มเติมใน GSI ของ OEM

รูปที่ 5 กำหนดรายการที่อนุญาตเพื่อลดรายการไฟล์ที่แก้ไขใน GSI ของ OEM

ขั้นตอนที่ 4: ทำให้ GSI ของ OEM มีไบนารีเหมือนกับ GSI ของ AOSP

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

รูปที่ 6 ตรวจสอบว่า GSI ของ OEM มีไบนารีเหมือนกับ GSI ของ AOSP

กำหนด SSI

OEM สามารถใช้คำแนะนำต่อไปนี้เพื่อกำหนด SSI ของตนเอง

ปกป้องพาร์ติชัน /system ในเวลาบิลด์

หากต้องการหลีกเลี่ยงการเปลี่ยนแปลงเฉพาะผลิตภัณฑ์ในพาร์ติชัน /system และกำหนด GSI ของ OEM ผู้ผลิต OEM สามารถใช้มาโคร Makefile ที่ชื่อ require-artifacts-in-path เพื่อป้องกันการประกาศโมดูลระบบหลังจากเรียกใช้มาโครแล้ว ดูตัวอย่างได้ในขั้นตอนที่ 1: สร้าง Makefile และเปิดใช้การตรวจสอบเส้นทางอาร์ติแฟกต์

OEM สามารถกำหนดรายการเพื่ออนุญาตให้ติดตั้งโมดูลเฉพาะผลิตภัณฑ์ในพาร์ติชัน /system ชั่วคราวได้ อย่างไรก็ตาม รายการต้องว่างเปล่าเพื่อให้ OEM GSI เป็นเรื่องปกติสำหรับผลิตภัณฑ์ทั้งหมดของ OEM กระบวนการนี้ใช้เพื่อกำหนด OEM GSI และไม่ขึ้นอยู่กับขั้นตอนสำหรับ AOSP GSI

ทำให้พาร์ติชัน /system_ext เป็นแบบทั่วไป

พาร์ติชัน /system_ext อาจแตกต่างกันไปในแต่ละอุปกรณ์ เนื่องจากอาจมีโมดูลเฉพาะอุปกรณ์ที่รวมอยู่ในระบบ เนื่องจาก SSI ประกอบด้วยพาร์ติชัน /system และ /system_ext ความแตกต่างในพาร์ติชัน /system_ext จึงเป็นอุปสรรคต่อ OEM ในการกำหนด SSI OEM สามารถมี SSI ของตนเองและแชร์ SSI นั้นในอุปกรณ์หลายเครื่องได้โดยการนำความแตกต่างออกและทำให้พาร์ติชัน /system_ext เป็นแบบทั่วไป

ส่วนนี้จะให้คำแนะนำในการทำให้พาร์ติชัน /system_ext เป็นแบบ ทั่วไป

เปิดเผย API ที่ซ่อนอยู่ในพาร์ทิชันระบบ

แอปเฉพาะผลิตภัณฑ์หลายแอปติดตั้งในพาร์ติชันผลิตภัณฑ์ไม่ได้เนื่องจาก ใช้ API ที่ซ่อนอยู่ ซึ่งไม่อนุญาตในพาร์ติชันผลิตภัณฑ์ หากต้องการย้าย แอปเฉพาะอุปกรณ์ไปยังพาร์ติชันผลิตภัณฑ์ ให้นำการใช้ API ที่ซ่อนอยู่ออก

วิธีที่แนะนำในการนำ API ที่ซ่อนอยู่ออกจากแอปคือการค้นหา API สาธารณะหรือ API ของระบบอื่นเพื่อแทนที่ API ที่ซ่อนอยู่ หากไม่มี API ที่จะแทนที่ API ที่ซ่อนอยู่ OEM สามารถมีส่วนร่วมใน AOSP เพื่อกำหนด API ของระบบใหม่สำหรับอุปกรณ์ของตนได้

หรือ OEM สามารถกำหนด API ที่กำหนดเองได้โดยการสร้างไลบรารี Java SDK ของตนเองในพาร์ติชัน /system_ext ไลบรารีนี้ใช้ API ที่ซ่อนอยู่ ในพาร์ติชันระบบได้ และสามารถให้ API แก่แอปในพาร์ติชันผลิตภัณฑ์หรือ พาร์ติชันของผู้ให้บริการ OEM ต้องหยุดการใช้งาน API ที่หันหน้าเข้าหาผลิตภัณฑ์เพื่อความเข้ากันได้แบบย้อนหลัง

แทนที่การปิดใช้แอปที่เฉพาะเจาะจง SKU

Android 16 เลิกใช้งานและนำกลไกเดิมสำหรับการปิดใช้ APK บางรายการตาม SKU ของฮาร์ดแวร์โดยใช้การวางซ้อนทรัพยากรของเฟรมเวิร์กออก (config_disableApksUnlessMatchedSku_apk_list และ config_disableApkUnlessMatchedSku_skus_list) ดูรายละเอียดได้ที่ aosp/3444399

เราขอแนะนำให้ใช้install-in-user-typeการกำหนดค่าระบบ ภายในไดเรกทอรีเฉพาะ SKU แทน วิธีนี้จะป้องกันไม่ให้มีการติดตั้งแพ็กเกจสำหรับผู้ใช้ใน SKU ที่เฉพาะเจาะจง แทนที่จะเพียงปิดใช้หลังการติดตั้ง

1. รวม APK ทั้งหมด (ซูเปอร์เซ็ตของแอปที่มีศักยภาพทั้งหมดสำหรับ SKU ทั้งหมดในอิมเมจระบบ) ไว้ในอิมเมจ โดยปกติจะอยู่ในพาร์ติชัน /product

2. ตรวจสอบว่าตั้งค่า SKU ของอุปกรณ์อย่างถูกต้องในพร็อพเพอร์ตี้ ro.boot.hardware.sku ของระบบ (ระบบใช้เพื่อระบุ SKU ของอุปกรณ์ในเวลาบูต)

3. สร้างไดเรกทอรีย่อย sysconfig เฉพาะ SKU ภายใต้ /product/etc/sysconfig/ โดยใช้รูปแบบการตั้งชื่อ sku_<SKU_NAME> ระบบจะโหลดการกำหนดค่าจากไดเรกทอรีที่ตรงกับพร็อพเพอร์ตี้ ro.boot.hardware.sku โดยอัตโนมัติ ตัวอย่างเส้นทาง: /product/etc/sysconfig/sku_basic_model/

4. กำหนดค่าการป้องกันการติดตั้งแอป ภายในไดเรกทอรีเฉพาะ SKU ให้ สร้างไฟล์การกำหนดค่า XML (เช่น disabled_apps.xml) และใช้แท็ก <do-not-install-in> เพื่อยกเว้นแพ็กเกจที่เฉพาะเจาะจง

ตัวอย่าง XML (/product/etc/sysconfig/sku_basic_model/disabled_apps.xml):

<?xml version="1.0" encoding="utf-8"?>
<config>
    <!-- Prevents this package from being installed for ANY user on this SKU -->
    <install-in-user-type package="com.example.premium.feature.app" >
        <do-not-install-in user-type="FULL" />
        <do-not-install-in user-type="SYSTEM" />
    </install-in-user-type>
</config>

การเปรียบเทียบ 2 วิธีมีดังนี้

ในกรณีที่ต้องการการควบคุมที่ละเอียดยิ่งขึ้น (เช่น การปิดใช้แอปที่โดยปกติจะติดตั้งโดยค่าเริ่มต้นใน SKU ทั้งหมด) Android ยังรองรับแท็ก disabled-in-sku และ enabled-in-sku-override ใน sysconfig ด้วย

• <disabled-in-sku package="com.example.app" /> จะปิดใช้แอปทั่วโลก

• <enabled-in-sku-override package="com.example.app" /> จะเปิดใช้แอปอีกครั้ง สำหรับ SKU ที่เฉพาะเจาะจงเมื่อวางไว้ในไดเรกทอรี sku_<name> ที่เกี่ยวข้อง

กำหนด RRO แทนการใช้การวางซ้อนทรัพยากรแบบคงที่

การวางซ้อนทรัพยากรแบบคงที่จะจัดการแพ็กเกจที่วางซ้อน อย่างไรก็ตาม การดำเนินการนี้อาจ ขัดขวางการกำหนด SSI ดังนั้นโปรดตรวจสอบว่าได้เปิดและตั้งค่าพร็อพเพอร์ตี้สำหรับ RRO อย่างถูกต้อง การตั้งค่าพร็อพเพอร์ตี้ดังต่อไปนี้จะช่วยให้ OEM มีภาพซ้อนทับที่สร้างขึ้นโดยอัตโนมัติทั้งหมดเป็น RRO

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

หากต้องมีการกำหนดค่าแบบละเอียด ให้กำหนด RRO ด้วยตนเองแทนที่จะใช้ RRO ที่สร้างขึ้นโดยอัตโนมัติ ดูข้อมูลแบบละเอียดได้ที่เปลี่ยนค่าของทรัพยากรของแอปขณะรันไทม์ นอกจากนี้ OEM ยังกำหนด RRO แบบมีเงื่อนไขที่ขึ้นอยู่กับพร็อพเพอร์ตี้ของระบบได้โดยใช้แอตทริบิวต์ android:requiredSystemPropertyName และ android:requiredSystemPropertyValue

คำถามที่พบบ่อย (FAQ)

คำถามที่พบบ่อยเกี่ยวกับ SSI มีดังนี้

ฉันกำหนด SSI หลายรายการได้ไหม

ซึ่งขึ้นอยู่กับความเหมือนและลักษณะของอุปกรณ์ (หรือกลุ่มอุปกรณ์) OEM สามารถลองทำให้พาร์ติชัน system_ext เป็นแบบทั่วไปได้ตามที่อธิบายไว้ใน ทำให้พาร์ติชัน system_ext เป็นแบบทั่วไป หากกลุ่มอุปกรณ์มีความแตกต่างกันมาก ควรกำหนด SSI หลายรายการ

ฉันจะนำโมดูลออกจาก generic_system.mk ที่ขัดแย้งกับการติดตั้งใช้งานของฉันได้ไหม

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