ผู้ผลิตอุปกรณ์ Android เปลี่ยนแปลงซอร์สโค้ดของไลบรารี AOSP ด้วยเหตุผลหลายประการ ผู้ให้บริการบางรายนำฟังก์ชันในไลบรารี AOSP มาใช้อีกครั้งเพื่อเพิ่มประสิทธิภาพ ขณะที่ผู้ให้บริการรายอื่นๆ เพิ่มฮุก API ใหม่ หรือฟังก์ชันการทำงานใหม่ลงในไลบรารี AOSP ส่วนนี้จะให้หลักเกณฑ์ในการขยายไลบรารี AOSP ในลักษณะที่ไม่ละเมิด CTS/VTS
การเปลี่ยนทดแทนแบบเสียบแทน
ไลบรารีที่ใช้ร่วมกันที่แก้ไขทั้งหมดต้องเข้ากันได้กับไบนารี แทนที่แบบติดตั้งใช้งานทันทีของไลบรารีที่ใช้ร่วมกันใน AOSP ผู้ใช้ AOSP ทุกคนที่มีอยู่ต้องใช้คลังที่ใช้ร่วมกันซึ่งแก้ไขแล้วได้โดยไม่ต้องคอมไพล์ใหม่ ข้อกำหนดนี้มีความนัยดังต่อไปนี้
- ต้องไม่นำฟังก์ชัน AOSP ออก
- โครงสร้างต้องไม่เปลี่ยนแปลงหากโครงสร้างดังกล่าวแสดงต่อผู้ใช้
- เงื่อนไขเริ่มต้นของฟังก์ชันต้องไม่เข้มงวดขึ้น
- ฟังก์ชันต้องให้ฟังก์ชันการทำงานที่เทียบเท่า
- เงื่อนไขหลังของฟังก์ชันต้องไม่อ่อนแอลง
การจัดประเภทโมดูลแบบขยาย
จัดหมวดหมู่โมดูลตามฟังก์ชันการทำงานที่กําหนดและใช้
หมายเหตุ: ฟังก์ชันการทำงานที่ใช้ที่นี่แทน API/ABI เนื่องจากสามารถเพิ่มฟังก์ชันการทำงานได้โดยไม่ต้องเปลี่ยนแปลง API/ABI
โมดูลสามารถแบ่งออกเป็น DA-Module และ DX-Module โดยขึ้นอยู่กับฟังก์ชันการทำงานที่กำหนดไว้ในโมดูล
-
การกำหนดเฉพาะโมดูล AOSP (DA-Module) ไม่ได้กำหนดฟังก์ชันการทำงานใหม่ซึ่งไม่มีใน AOSP
- ตัวอย่างที่ 1 ไลบรารี AOSP ที่ไม่ได้แก้ไขและสมบูรณ์คือ DA-Module
- ตัวอย่างที่ 2 หากผู้ให้บริการเขียนฟังก์ชันใน
libcrypto.so
ใหม่โดยใช้คำสั่ง SIMD (โดยไม่เพิ่มฟังก์ชันใหม่)libcrypto.so
ที่แก้ไขแล้วจะกลายเป็น DA-Module
-
Defining-Extension Modules (DX-Module) จะกำหนดฟังก์ชันการทำงานใหม่หรือไม่มีคู่ AOSP
- ตัวอย่างที่ 1 หากผู้ให้บริการเพิ่มฟังก์ชันตัวช่วยลงใน
libjpeg.so
เพื่อเข้าถึงข้อมูลภายในบางอย่างlibjpeg.so
ที่แก้ไขแล้วจะเป็น DX-Lib และฟังก์ชันที่เพิ่มใหม่จะเป็นส่วนที่ขยายของไลบรารี - ตัวอย่างที่ 2 หากผู้ให้บริการกำหนดไลบรารีที่ไม่ใช่ AOSP ที่มีชื่อว่า
libfoo.so
libfoo.so
จะเป็น DX-Lib
- ตัวอย่างที่ 1 หากผู้ให้บริการเพิ่มฟังก์ชันตัวช่วยลงใน
โมดูลสามารถแบ่งออกเป็นโมดูล UA และโมดูล UX ทั้งนี้ขึ้นอยู่กับฟังก์ชันการทำงานของโมดูล
-
การใช้เฉพาะโมดูล AOSP (UA-Module) ใช้ฟังก์ชันการทำงานของ AOSP เท่านั้นในการนำไปใช้งาน โดยไม่ได้อาศัยส่วนขยายที่ไม่ใช่ AOSP
- ตัวอย่างที่ 1 ไลบรารี AOSP ที่ไม่ได้แก้ไขและสมบูรณ์คือ UA-Module
- ตัวอย่างที่ 2 หากไลบรารีที่ใช้ร่วมกันซึ่งแก้ไขแล้ว
libjpeg.so
ใช้เฉพาะ AOSP API อื่นๆ จะเป็น UA-Module
-
การใช้ข้อบังคับของส่วนขยาย (UX-Module) อาศัยฟังก์ชันการทำงานบางอย่างที่ไม่ใช่ AOSP ในการใช้งาน
- ตัวอย่างที่ 1 หาก
libjpeg.so
ที่แก้ไขแล้วใช้ไลบรารีอื่นที่ไม่ใช่ AOSP ชื่อlibjpeg_turbo2.so
libjpeg.so
ที่แก้ไขแล้วจะเป็น UX-Module - ตัวอย่างที่ 2 หากผู้ให้บริการเพิ่มฟังก์ชันใหม่ลงใน
libexif.so
ที่แก้ไข และlibjpeg.so
ที่แก้ไขใช้ฟังก์ชันที่เพิ่มใหม่จากlibexif.so
libjpeg.so
ที่แก้ไขก็จะเป็น UX-Module
- ตัวอย่างที่ 1 หาก
คําจํากัดความและการใช้งานจะแยกจากกันดังนี้
ฟังก์ชันการทำงานที่ใช้ | |||
---|---|---|---|
AOSP (UA) เท่านั้น | ขยาย (UX) | ||
ฟังก์ชันการทำงานที่กําหนด | AOSP (DA) เท่านั้น | DAUA | DAUX |
ขยาย (DX) | DXUA | DXUX |
กลไกส่วนขยาย VNDK
โมดูลของผู้ให้บริการที่อาศัยฟังก์ชันการทำงานแบบขยายจะไม่ทำงานเนื่องจากไลบรารี AOSP ที่มีชื่อเดียวกันไม่มีฟังก์ชันการทำงานแบบขยาย หากโมดูลของผู้ให้บริการใช้ฟังก์ชันการทำงานเพิ่มเติมโดยตรงหรือโดยอ้อม ผู้ให้บริการควรคัดลอกไลบรารีที่แชร์ของ DAUX, DXUA และ DXUX ไปยังพาร์ติชันของผู้ให้บริการ (กระบวนการของผู้ให้บริการจะค้นหาไลบรารีที่แชร์ในพาร์ติชันของผู้ให้บริการก่อนเสมอ) อย่างไรก็ตาม คุณต้องไม่คัดลอกไลบรารี LL-NDK ดังนั้นโมดูลของผู้ให้บริการต้องไม่ใช้ฟังก์ชันการทำงานเพิ่มเติมที่ระบุโดยไลบรารี LL-NDK ที่แก้ไข
ไลบรารีที่แชร์ของ DAUA จะยังคงอยู่ในพาร์ติชันระบบได้หากไลบรารี AOSP ที่เกี่ยวข้องสามารถให้ฟังก์ชันการทำงานเดียวกันและโมดูลของผู้ให้บริการยังคงทํางานต่อไปได้เมื่อมีการเขียนทับพาร์ติชันระบบด้วย Generic System Image (GSI)
การเปลี่ยนทดแทนแบบวางซ้อนเป็นสิ่งสําคัญเนื่องจากไลบรารี VNDK ที่ไม่ได้แก้ไขใน GSI จะลิงก์กับไลบรารีที่แชร์ซึ่งแก้ไขแล้วในกรณีที่ชื่อทับซ้อนกัน หากมีการแก้ไขไลบรารี AOSP ในลักษณะที่ไม่เข้ากันได้กับ API/ABI ไลบรารี AOSP ใน GSI อาจลิงก์ไม่สำเร็จหรือทําให้ระบบทำงานในลักษณะที่ไม่รู้จัก