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