อิมเมจระบบที่แชร์ของ 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 1 รายการ หรือมี 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

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

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

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

    • 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

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

รูปที่ 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 กําหนดรายการที่อนุญาตเพื่อลดรายการไฟล์ที่แก้ไขใน GSI ของ OEM

ขั้นตอนที่ 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 เพื่อป้องกันการประกาศโมดูลของระบบหลังจากเรียกใช้มาโคร ดูตัวอย่างการสร้างไฟล์ Make และเปิดใช้การตรวจสอบเส้นทางอาร์ติแฟกต์

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 ที่แสดงต่อผู้ใช้เพื่อใช้งานย้อนหลังได้

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

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

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