หน้านี้นำเสนอกลไกหลายประการที่ OEM ของอุปกรณ์ Android สามารถใช้เพื่อให้มีอิมเมจระบบที่ใช้ร่วมกัน (SSI) ของตนเองข้ามสายผลิตภัณฑ์ นอกจากนี้ยังเสนอขั้นตอนสำหรับการสร้าง SSI ที่เป็นของ OEM บนอิมเมจระบบทั่วไป (GSI) ที่สร้างโดย AOSP
พื้นหลัง
ด้วย Project Treble Android แบบเสาหินถูกแบ่งออกเป็นสองส่วน: ส่วนเฉพาะของฮาร์ดแวร์ (การใช้งานของผู้จำหน่าย) และส่วนระบบปฏิบัติการทั่วไป (เฟรมเวิร์กระบบปฏิบัติการ Android) ซอฟต์แวร์สำหรับแต่ละรายการได้รับการติดตั้งในพาร์ติชันแยกต่างหาก: พาร์ติชันผู้จำหน่ายสำหรับซอฟต์แวร์เฉพาะฮาร์ดแวร์ และพาร์ติชันระบบสำหรับซอฟต์แวร์ระบบปฏิบัติการทั่วไป อินเทอร์เฟซที่กำหนดเวอร์ชัน เรียกว่าอินเทอร์เฟซผู้ขาย ( VINTF ) ถูกกำหนดและบังคับใช้ระหว่างทั้งสองพาร์ติชัน โดยใช้ระบบการแบ่งพาร์ติชันนี้ คุณสามารถแก้ไขพาร์ติชันระบบได้โดยไม่ต้องแก้ไขพาร์ติชันของผู้จำหน่าย และในทางกลับกัน
แรงจูงใจ
รหัสเฟรมเวิร์กที่เผยแพร่ใน AOSP นั้นสอดคล้องกับสถาปัตยกรรม Treble และรักษาความเข้ากันได้แบบย้อนหลังกับการใช้งานของผู้จำหน่ายรุ่นเก่า ตัวอย่างเช่น อิมเมจระบบทั่วไปที่สร้างจากแหล่งที่มาของ Android 10 AOSP สามารถทำงานบนอุปกรณ์ที่รองรับ Treble ใดๆ ที่ทำงานบน Android 8 หรือสูงกว่า เวอร์ชันของ Android ที่จัดส่งบนอุปกรณ์ผู้บริโภคได้รับการแก้ไขโดยผู้จำหน่าย SoC และ OEM (ดู อายุการใช้งานของ Android Release ) การเปลี่ยนแปลงและส่วนขยายเหล่านี้ที่ทำกับเฟรมเวิร์กไม่ได้เขียนขึ้นเพื่อรักษาความเข้ากันได้แบบย้อนหลัง ซึ่งแปลเป็นความซับซ้อนที่เพิ่มขึ้นและต้นทุนที่สูงขึ้นในการอัปเกรดระบบปฏิบัติการ การเปลี่ยนแปลงและแก้ไขเฉพาะอุปกรณ์เพิ่มต้นทุนและความซับซ้อนในการอัปเกรดเวอร์ชันระบบปฏิบัติการ Android
ก่อน Android 11 ไม่มีสถาปัตยกรรมที่ชัดเจนที่ช่วยให้พันธมิตรสามารถสร้างส่วนขยายแบบโมดูลาร์ให้กับเฟรมเวิร์กระบบปฏิบัติการ Android ได้ เอกสารนี้อธิบายขั้นตอนที่ผู้จำหน่าย SoC และ OEM สามารถทำได้เพื่อสร้าง SSI ซึ่งหมายความว่าอิมเมจเดียวที่สร้างขึ้นจากแหล่งที่มาของเฟรมเวิร์กระบบปฏิบัติการ Android เพื่อนำมาใช้ซ้ำในอุปกรณ์หลายเครื่อง เพื่อรักษาความเข้ากันได้แบบย้อนหลังกับการใช้งานของผู้จำหน่าย และเพื่อลดความซับซ้อนและต้นทุนของการอัปเกรดระบบปฏิบัติการ Android ลงอย่างมาก สำหรับขั้นตอนเฉพาะที่คุณต้องสร้าง SSI โปรดดูส่วน ขั้นตอนที่แนะนำสำหรับ SSI ที่ใช้ GSI และโปรดทราบว่าคุณไม่จำเป็นต้องใช้ทั้งสี่ขั้นตอน ขั้นตอนที่คุณเลือก (เช่น ขั้นตอนที่ 1 เท่านั้น) ขึ้นอยู่กับการใช้งานของคุณ
ภาพรวมของเอสเอสไอ
ด้วย 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 และอินเทอร์เฟซที่มีการกำหนดเวอร์ชันทั่วทั้งพาร์ติชันและนโยบายบนอินเทอร์เฟซ ส่วนนี้จะอธิบายแต่ละพาร์ติชันและอินเทอร์เฟซโดยละเอียด
รูปที่ 1. พาร์ติชันและอินเทอร์เฟซรอบๆ SSI
รูปภาพและพาร์ติชัน
ข้อมูลในส่วนนี้จะแยกแยะความแตกต่างระหว่างคำว่า image และ partition
- รูปภาพ เป็นซอฟต์แวร์เชิงแนวคิดที่สามารถอัปเดตได้อย่างอิสระ
- พาร์ติชัน คือตำแหน่งหน่วยเก็บข้อมูลจริงที่สามารถอัพเดตได้อย่างอิสระ
ส่วนในรูปที่ 1 มีการกำหนดดังนี้:
SSI: SSI เป็นรูปภาพที่ใช้ร่วมกับ OEM และสามารถมีอยู่ได้ในอุปกรณ์หลายเครื่อง ไม่มีส่วนประกอบเฉพาะของฮาร์ดแวร์หรือผลิตภัณฑ์เฉพาะใดๆ ตามคำจำกัดความ ทุกอย่างใน SSI ที่กำหนดจะถูกแชร์ระหว่างอุปกรณ์ทั้งหมดที่ใช้ SSI นั้น SSI ประกอบด้วยอิมเมจ
/system
เดียว หรือพาร์ติชัน/system
และ/system_ext
ดังแสดงในรูปที่ 1พาร์ติชัน
/system
ประกอบด้วยส่วนประกอบที่ใช้ AOSP ในขณะที่/system_ext
เมื่อนำไปใช้งาน จะมีส่วนขยายผู้จำหน่าย OEM และ SoC และส่วนประกอบที่ควบคู่กับส่วนประกอบ AOSP อย่างแน่นหนา ตัวอย่างเช่น ไลบรารีเฟรมเวิร์ก OEM Java ที่ให้ 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:
Vendor Interface (VINTF) : VINTF เป็นส่วนต่อประสานกับส่วนประกอบที่อยู่ในผู้จำหน่ายและอิมเมจ ODM ส่วนประกอบในอิมเมจผลิตภัณฑ์และระบบสามารถโต้ตอบกับผู้จำหน่ายและอิมเมจ ODM ผ่านอินเทอร์เฟซนี้เท่านั้น ตัวอย่างเช่น อิมเมจของผู้จำหน่ายไม่สามารถขึ้นอยู่กับส่วนส่วนตัวของอิมเมจระบบ และในทางกลับกัน เดิมทีกำหนดไว้ใน Project Treble ซึ่งแบ่งอิมเมจออกเป็นพาร์ติชันระบบและผู้จำหน่าย อินเทอร์เฟซอธิบายโดยใช้กลไกต่อไปนี้:
- HIDL (Passthrough HAL ใช้ได้เฉพาะกับโมดูล
system
และsystem_ext
เท่านั้น) - โรคเอดส์ที่มีเสถียรภาพ
- การกำหนดค่า
- API คุณสมบัติของระบบ
- กำหนดค่า API สคีมาของไฟล์
- ดองเวียดนาม
- API ของ Android SDK
- ไลบรารี Java SDK
- HIDL (Passthrough HAL ใช้ได้เฉพาะกับโมดูล
อินเทอร์เฟซผลิตภัณฑ์ : อินเทอร์เฟซผลิตภัณฑ์คืออินเทอร์เฟซระหว่าง 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
โดยไม่มีอินเทอร์เฟซที่กำหนดไว้ข้าม พาร์ติชั่นทั้งสอง ส่วนประกอบในพาร์ติ /system_ext
สามารถทำการเรียก API ส่วนตัวไปยังพาร์ติชัน /system
และส่วนประกอบในพาร์ติ /system
สามารถทำการเรียก API ส่วนตัวไปยัง /system_ext
เนื่องจากพาร์ติชันทั้งสองเชื่อมต่อกันอย่างแน่นหนา ทั้งสองพาร์ติชันจึงได้รับการอัปเกรดพร้อมกันเมื่อมีการเปิดตัว 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
จะต้องแยกออกจากพาร์ติชันอื่น การขึ้นต่อกันที่ได้รับอนุญาตเพียงอย่างเดียวจากโมดูลผลิตภัณฑ์คือไลบรารี VNDK บางไลบรารี (รวมถึง LLNDK) จากพาร์ติชัน/system
ไลบรารี JNI ที่แอปผลิตภัณฑ์ต้องพึ่งพาต้องเป็นไลบรารี NDK - อินเทอร์เฟซ Java : โมดูล Java (แอป) ในพาร์ติชัน
/product
ไม่สามารถใช้ API ที่ซ่อนอยู่ได้ เนื่องจากไม่เสถียร โมดูลเหล่านี้ต้องใช้เฉพาะ API สาธารณะและ API ระบบจากพาร์ติชัน/system
และไลบรารี Java SDK ในพาร์ติ/system
หรือ/system_ext
คุณสามารถกำหนด ไลบรารี Java SDK สำหรับ API แบบกำหนดเองได้
ขั้นตอนที่แนะนำสำหรับ 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 (OEM GSI)
ด้วยการสืบทอด generic_system.mk
(ซึ่งมีชื่อว่า mainline_system.mk
ใน Android 11 และเปลี่ยนชื่อเป็น generic_system.mk
ใน AOSP) อิมเมจระบบ (OEM GSI) จะรวมไฟล์ทั้งหมดที่ AOSP GSI มี ไฟล์เหล่านี้สามารถแก้ไขได้โดย OEM เพื่อให้ OEM GSI สามารถมีไฟล์ที่เป็นกรรมสิทธิ์ของ OEM นอกเหนือจากไฟล์ AOSP GSI อย่างไรก็ตาม OEM ไม่ได้รับอนุญาตให้แก้ไขไฟล์ generic_system.mk
เอง
รูปที่ 3 การสืบทอด generic_system.mk
สำหรับอิมเมจระบบของ OEM
ขั้นตอนที่ 2 การทำให้ OEM GSI มีรายการไฟล์เดียวกันกับ AOSP GSI
OEM GSI ไม่สามารถมีไฟล์เพิ่มเติมได้ในขั้นตอนนี้ ไฟล์ที่เป็นกรรมสิทธิ์ของ OEM จะต้องถูกย้ายออกไปที่ system_ext
หรือพาร์ติชัน product
รูปที่ 4 การย้ายไฟล์ที่เพิ่มออกจาก OEM GSI
ขั้นตอนที่ 3 การกำหนดรายการที่อนุญาตเพื่อจำกัดไฟล์ที่แก้ไขใน OEM GSI
หากต้องการตรวจสอบไฟล์ที่แก้ไข OEM สามารถใช้เครื่องมือ compare_images
และเปรียบเทียบ AOSP GSI กับ OEM GSI รับ AOSP GSI จากเป้าหมายอาหารกลางวัน AOSP generic_system_*
เมื่อเรียกใช้เครื่องมือ compare_images
เป็นระยะๆ ด้วยพารามิเตอร์ allowlist
คุณจะตรวจสอบความแตกต่างภายนอกรายการที่อนุญาตได้ ซึ่งจะทำให้ไม่จำเป็นต้องแก้ไขเพิ่มเติมกับ OEM GSI
รูปที่ 5 กำหนดรายการที่อนุญาตเพื่อลดรายการไฟล์ที่แก้ไขใน OEM GSI
ขั้นตอนที่ 4 การทำให้ OEM GSI มีไบนารีเหมือนกับ AOSP GSI
การล้างรายการที่อนุญาตจะทำให้ OEM สามารถใช้ AOSP GSI เป็นอิมเมจระบบสำหรับผลิตภัณฑ์ของตนเองได้ หากต้องการล้างรายการที่อนุญาต OEM สามารถละทิ้งการเปลี่ยนแปลงใน OEM GSI หรืออัปสตรีมการเปลี่ยนแปลงไปยัง AOSP เพื่อให้ AOSP GSI รวมการเปลี่ยนแปลงไว้ด้วย
รูปที่ 6 การทำให้ OEM GSI มีไบนารีเหมือนกับ AOSP GSI
การกำหนด SSI สำหรับ OEM
ป้องกันพาร์ติชัน /system ในขณะสร้าง
เพื่อหลีกเลี่ยงการเปลี่ยนแปลงเฉพาะผลิตภัณฑ์ใดๆ ในพาร์ติชัน /system
และกำหนด OEM GSI, OEM สามารถใช้แมโคร makefile ที่เรียกว่า require-artifacts-in-path
เพื่อป้องกันการประกาศใดๆ ของโมดูลระบบหลังจากเรียกใช้แมโคร ดู ตัวอย่างการสร้าง makefile และเปิดใช้งานการตรวจสอบพาธอาร์ติแฟกต์
OEM สามารถกำหนดรายการเพื่ออนุญาตให้ติดตั้งโมดูลเฉพาะผลิตภัณฑ์ในพาร์ติชัน /system
เป็นการชั่วคราว อย่างไรก็ตาม รายการจะต้องว่างเปล่าเพื่อให้ OEM GSI ใช้ร่วมกับผลิตภัณฑ์ทั้งหมดของ OEM กระบวนการนี้มีไว้เพื่อกำหนด OEM GSI และสามารถเป็นอิสระจาก ขั้นตอนสำหรับ AOSP GSI
บังคับใช้อินเทอร์เฟซผลิตภัณฑ์
เพื่อรับประกันว่าพาร์ติชัน /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 ที่ซ่อนอยู่ 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
เพื่อการตั้งค่าที่แม่นยำยิ่งขึ้น ให้ประกาศเครื่องรับออกอากาศที่ปิดใช้งานแพ็คเกจที่ไม่จำเป็น ตัวรับสัญญาณออกอากาศเรียก setApplicationEnabledSetting
เพื่อปิดการใช้งานแพ็คเกจเมื่อได้รับข้อความ ACTION_BOOT_COMPLETED
กำหนด RRO แทนที่จะใช้การซ้อนทับทรัพยากรแบบคงที่
การซ้อนทับทรัพยากรแบบคงที่จัดการแพ็คเกจที่ซ้อนทับ อย่างไรก็ตาม อาจขัดขวางการกำหนด SSI ได้ ดังนั้นโปรดตรวจสอบให้แน่ใจว่าคุณสมบัติสำหรับ RRO เปิดและตั้งค่าอย่างถูกต้อง ด้วยการตั้งค่าคุณสมบัติดังต่อไปนี้ OEM สามารถสร้างโอเวอร์เลย์ที่สร้างขึ้นอัตโนมัติทั้งหมดเป็น RRO ได้
PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty
หากจำเป็นต้องมีการกำหนดค่าโดยละเอียด ให้กำหนด RRO ด้วยตนเองแทนที่จะอาศัยการกำหนดค่าที่สร้างขึ้นอัตโนมัติ สำหรับข้อมูลโดยละเอียด โปรดดูที่ Runtime Resource Overlays (RRO) OEM ยังสามารถกำหนด RRO แบบมีเงื่อนไขที่ขึ้นอยู่กับคุณสมบัติของระบบโดยใช้ android:requiredSystemPropertyName
และ android:requiredSystemPropertyValue
คำถามที่พบบ่อย (FAQ)
ฉันสามารถกำหนด SSI หลายรายการได้หรือไม่
ขึ้นอยู่กับความธรรมดาและลักษณะของอุปกรณ์ (หรือกลุ่มอุปกรณ์) OEM สามารถลองทำให้พาร์ติ system_ext
เป็นแบบทั่วไป ดังที่อธิบายไว้ใน การทำให้พาร์ติชัน system_ext เป็นแบบทั่วไป หากกลุ่มอุปกรณ์มีความแตกต่างกันมาก ควรกำหนด SSI หลายรายการจะดีกว่า
ฉันสามารถแก้ไข generic_system.mk
( mainline_system.mk
) สำหรับ OEM GSI ได้หรือไม่
ไม่ แต่ OEM อาจกำหนด makefile ใหม่สำหรับ OEM GSI ที่สืบทอดไฟล์ generic_system.mk
และใช้ makefile ใหม่แทน ตัวอย่างเช่น โปรดดูที่ การบังคับใช้อินเทอร์เฟซพาร์ติชันผลิตภัณฑ์
ฉันสามารถลบโมดูลออกจาก generic_system.mk
ที่ขัดแย้งกับการใช้งานของฉันได้หรือไม่
ไม่ GSI มีชุดโมดูลที่สามารถบูตได้และทดสอบได้ขั้นต่ำ หากคุณคิดว่าโมดูลไม่จำเป็น โปรดแจ้งจุดบกพร่องเพื่ออัปเดตไฟล์ generic_system.mk
ใน AOSP