อิมเมจระบบที่ใช้ร่วมกันของ Android

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

Partitions and interfaces around SSI block diagram

รูปที่ 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

  • อินเทอร์เฟซผลิตภัณฑ์ : อินเทอร์เฟซผลิตภัณฑ์คืออินเทอร์เฟซระหว่าง 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

Suggested partitions for GSI-based SSI

รูปที่ 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 เอง

Inheriting `generic_system.mk` for OEM system image

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

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

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

Moving added files out of the OEM GSI

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

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

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

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

Define an allowlist to reduce the list of modified files in OEM GSI

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

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

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

Make OEM GSI have the same binaries as 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