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