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

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

ฉากหลัง

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

แรงจูงใจ

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

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

ภาพรวม SSI

เมื่อใช้ SSI ระบบจะวางคอมโพเนนต์ซอฟต์แวร์และส่วนขยาย OEM เฉพาะผลิตภัณฑ์ไว้ในพาร์ติชัน /product ใหม่ คอมโพเนนต์ในพาร์ติชัน /product ใช้อินเทอร์เฟซที่ระบุไว้อย่างชัดเจนและเสถียรเพื่อโต้ตอบกับคอมโพเนนต์ในพาร์ติชัน /system OEM จะเลือกสร้าง SSI รายการเดียวหรือมี SSI จํานวนไม่มากนักเพื่อใช้ใน SKU ของอุปกรณ์หลายรายการก็ได้ เมื่อมีการเผยแพร่ระบบปฏิบัติการ Android เวอร์ชันใหม่ OEM จะลงทุนเพียงครั้งเดียวในการอัปเดต 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 (หากมีการใช้งาน) จะมีส่วนขยายและคอมโพเนนต์ของ OEM และผู้จำหน่าย SoC ที่เชื่อมโยงกับคอมโพเนนต์ AOSP อย่างแน่นหนา ตัวอย่างเช่น ไลบรารีเฟรมเวิร์ก Java ของ OEM ที่มี API ที่กำหนดเองสำหรับแอปของ OEM จะเหมาะกับใน /system_ext มากกว่าในพาร์ติชัน /system เนื้อหาสำหรับทั้งพาร์ติชัน /system และ /system_ext สร้างขึ้นจากแหล่งที่มา Android ที่ปรับแต่งด้วย OEM

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

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

  • ผู้ให้บริการ: คอลเล็กชันคอมโพเนนต์สำหรับ SoC โดยเฉพาะ

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

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

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

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

    • HIDL (HAL แบบส่งผ่านใช้ได้กับโมดูล system และ system_ext เท่านั้น)
    • AIDL เวอร์ชันเสถียร
    • การกำหนดค่า
      • System Properties 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 จะใช้ทรัพยากรของระบบได้โดยไม่มีข้อจำกัด และในทางกลับกัน ระบบจะแยกคอมโพเนนต์ของผลิตภัณฑ์ออกเป็นพาร์ติชัน /system_ext และ /product เพื่อให้ SSI เป็นไปได้ใน Android 10 พาร์ติชัน /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) อิมเมจระบบ (GSI ของ OEM) จะมีไฟล์ทั้งหมดที่ GSI ของ AOSP มี 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ทำให้พาร์ติชัน /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 ที่ซ่อนอยู่ OEM สามารถมีส่วนร่วมใน AOSP เพื่อกำหนด API ระบบใหม่สำหรับอุปกรณ์ของตนได้

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

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

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

สำหรับการตั้งค่าที่แม่นยำยิ่งขึ้น ให้ประกาศ Broadcast Receiver ที่ปิดใช้แพ็กเกจที่ไม่จำเป็น ตัวรับการออกอากาศจะเรียกใช้ 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

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

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

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

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

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

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

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