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

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

ฉากหลัง

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

แรงจูงใจ

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

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

ภาพรวม SSI

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

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

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

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

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

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

พาร์ติชันและอินเทอร์เฟซรอบๆ บล็อกไดอะแกรม SSI

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

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

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

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

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

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

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

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

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

  • ผู้ให้บริการ: ชุดคอมโพเนนต์ที่เฉพาะเจาะจงสำหรับ SoC

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

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

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

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

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

  • อินเทอร์เฟซผลิตภัณฑ์: อินเทอร์เฟซผลิตภัณฑ์คืออินเทอร์เฟซระหว่าง SSI กับ รูปภาพผลิตภัณฑ์ การกำหนดอินเทอร์เฟซที่เสถียรจะแยกส่วนประกอบของผลิตภัณฑ์ ออกจากส่วนประกอบของระบบใน SSI อินเทอร์เฟซผลิตภัณฑ์ต้องมี อินเทอร์เฟซที่เสถียรเหมือนกับ VINTF อย่างไรก็ตาม ระบบจะบังคับใช้เฉพาะ VNDK และ Android SDK API สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 11 (และสูงกว่า)

เปิดใช้ SSI ใน Android 11

ส่วนนี้จะอธิบายวิธีใช้ฟีเจอร์ใหม่ที่มีอยู่เพื่อรองรับ SSI ใน Android 11

พาร์ติชัน /system_ext

/system_ext พาร์ติชันเปิดตัวใน Android 11 เป็นพาร์ติชันที่ไม่บังคับ (เป็นที่อยู่ของคอมโพเนนต์ที่ไม่ใช่ AOSP ซึ่งมีการเชื่อมโยงอย่างใกล้ชิดกับ คอมโพเนนต์ที่กำหนดโดย AOSP ในพาร์ติชัน /system) ระบบจะถือว่าพาร์ติชัน /system_ext เป็นส่วนขยายเฉพาะ 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 ได้

แยกคอมโพเนนต์ออกจากพาร์ติชัน /system และ /system_ext ไปยังพาร์ติชัน /product

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

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

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

ตั้งแต่ Android 11 เป็นต้นไป ระบบจะบังคับใช้อินเทอร์เฟซเนทีฟและ Java สำหรับพาร์ติชัน /product ตามที่อธิบายไว้ด้านล่าง ดูข้อมูลเพิ่มเติมได้ที่ การบังคับใช้อินเทอร์เฟซการแบ่งพาร์ติชันผลิตภัณฑ์

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

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

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

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

อิมเมจระบบทั่วไป (GSI) คืออิมเมจระบบที่สร้างขึ้นจาก AOSP โดยตรง ใช้สำหรับการทดสอบการปฏิบัติตามข้อกำหนดของ Treble (เช่น 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 อย่างไรก็ตาม OEM จะไม่ได้รับอนุญาตให้แก้ไขไฟล์ generic_system.mk เอง

การรับค่า `generic_system.mk` สำหรับอิมเมจระบบ OEM

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

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

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

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

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

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

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

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

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

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

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

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

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

รูปที่ 6 การทำให้ GSI ของ OEM มีไบนารีเหมือนกับ GSI ของ AOSP

กำหนด SSI สำหรับ OEM

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

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

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

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

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

ทำให้พาร์ติชัน /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 ที่หันหน้าไปทางผลิตภัณฑ์ เพื่อความเข้ากันได้แบบย้อนหลัง

รวมชุดย่อยของ APK ทั้งหมดและข้ามการติดตั้งแพ็กเกจบางรายการสำหรับอุปกรณ์แต่ละเครื่อง

แพ็กเกจบางอย่างที่มาพร้อมกับระบบจะไม่เหมือนกันในอุปกรณ์ต่างๆ การแยกโมดูล APK เหล่านี้เพื่อย้ายไปยังพาร์ติชันผลิตภัณฑ์หรือพาร์ติชันของผู้ให้บริการ อาจทำได้ยาก ในฐานะโซลูชันชั่วคราว OEM สามารถทำให้ SSI มีโมดูลทั้งหมด จากนั้นกรองโมดูลที่ไม่ต้องการออกโดยใช้พร็อพเพอร์ตี้ SKU (ro.boot.hardware.sku) หากต้องการใช้ตัวกรอง OEM จะซ้อนทับทรัพยากรเฟรมเวิร์ก config_disableApkUnlessMatchedSku_skus_list และ config_disableApksUnlessMatchedSku_apk_list

หากต้องการตั้งค่าที่แม่นยำยิ่งขึ้น ให้ประกาศ Broadcast Receiver ที่ปิดใช้แพ็กเกจที่ไม่จำเป็น BroadcastReceiver จะเรียกใช้ setApplicationEnabledSetting เพื่อปิดใช้แพ็กเกจเมื่อได้รับข้อความ ACTION_BOOT_COMPLETED

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

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

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

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

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

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

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

ฉันแก้ไข generic_system.mk (mainline_system.mk) สำหรับ GSI ของ OEM ได้ไหม

ไม่ได้ แต่ OEM สามารถกำหนด Makefile ใหม่สำหรับ GSI ของ OEM ที่รับค่าจากไฟล์ generic_system.mk และใช้ Makefile ใหม่แทนได้ ดูตัวอย่างได้ที่ การบังคับใช้พาร์ติชันผลิตภัณฑ์ อินเทอร์เฟซ

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

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