ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
ส่วนขยาย VNDK
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
ผู้ผลิตอุปกรณ์ 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
โมดูลสามารถแบ่งออกเป็นโมดูล 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
คําจํากัดความและการใช้งานจะแยกจากกันดังนี้
|
ฟังก์ชันการทำงานที่ใช้ |
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 อาจลิงก์ไม่สำเร็จหรือทําให้ระบบทำงานในลักษณะที่ไม่รู้จัก
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[[["เข้าใจง่าย","easyToUnderstand","thumb-up"],["แก้ปัญหาของฉันได้","solvedMyProblem","thumb-up"],["อื่นๆ","otherUp","thumb-up"]],[["ไม่มีข้อมูลที่ฉันต้องการ","missingTheInformationINeed","thumb-down"],["ซับซ้อนเกินไป/มีหลายขั้นตอนมากเกินไป","tooComplicatedTooManySteps","thumb-down"],["ล้าสมัย","outOfDate","thumb-down"],["ปัญหาเกี่ยวกับการแปล","translationIssue","thumb-down"],["ตัวอย่าง/ปัญหาเกี่ยวกับโค้ด","samplesCodeIssue","thumb-down"],["อื่นๆ","otherDown","thumb-down"]],["อัปเดตล่าสุด 2025-07-27 UTC"],[],[],null,["# VNDK extensions\n\nAndroid device manufacturers change the source code of AOSP libraries for\nvarious reasons. Some vendors reimplement functions in AOSP libraries to\nboost the performance while other vendors add new hooks, new APIs, or new\nfunctionalities to AOSP libraries. This section provides guidelines for\nextending AOSP libraries in a way that does not break CTS/VTS.\n\nDrop-in replacement\n-------------------\n\nAll modified shared libraries must be **binary-compatible** ,\n**drop-in replacements** of their AOSP counterpart. All existing\nAOSP users must be able to use the modified shared library without\nrecompilations. This requirement implies the following:\n\n- AOSP functions must not be removed.\n- Structures must not be altered if such structures are exposed to their users.\n- Pre-condition of functions must not be strengthened.\n- Functions must provide equivalent functionalities.\n- Post-condition of functions must not be weakened.\n\nExtended module classifications\n-------------------------------\n\nClassify modules by the functionalities they **define** and\n**use**.\n\n**Note** : *Functionalities* is used here\ninstead of API/ABI because it is possible to add functionality without changing\nany API/ABI.\n\nDepending on the functionalities defined in a module, modules can be\nclassified into **DA-Module** and **DX-Module**:\n\n- *Defining-only-AOSP Modules (DA-Module)* do not define new functionalities which were not in the AOSP counterpart.\n - *Example 1.* An intact unmodified AOSP library is a DA-Module.\n - *Example 2.* If a vendor rewrites the functions in `libcrypto.so` with SIMD instructions (without adding new functions), then the modified `libcrypto.so` will be a DA-Module.\n- *Defining-Extension Modules (DX-Module)* either define new functionalities or do not have an AOSP counterpart.\n - *Example 1.* If a vendor adds a helper function to `libjpeg.so` to access some internal data, then the modified `libjpeg.so` will be a DX-Lib and the newly added function will be the extended portion of the library.\n - *Example 2.* If a vendor defines a non-AOSP library named `libfoo.so`, then `libfoo.so` will be a DX-Lib.\n\nDepending on the functionalities used by a module, modules can be classified\ninto **UA-Module** and **UX-Module**.\n\n- *Using-only-AOSP Modules (UA-Module)* only use AOSP functionalities in their implementations. They do not rely on any non-AOSP extensions.\n - *Example 1.* An intact unmodified AOSP library is an UA-Module.\n - *Example 2.* If a modified shared library `libjpeg.so` only relies on other AOSP APIs, then it will be an UA-Module.\n- *Using-Extension Modules (UX-Module)* rely on some non-AOSP functionalities in their implementations.\n - *Example 1.* If a modified `libjpeg.so` relies on another non-AOSP library named `libjpeg_turbo2.so`, then the modified `libjpeg.so` will be an UX-Module.\n - *Example 2.* If a vendor adds a new function to their modified `libexif.so` and their modified `libjpeg.so` uses the newly added function from `libexif.so`, then their modified `libjpeg.so` will be an UX-Module.\n\nDefinitions and usages are independent from each other:\n\n|---------------|------|----------------|---------------|\n| || Used Functionalities ||\n| || Only AOSP (UA) | Extended (UX) |\n| Extended (DX) | DXUA | DXUX |\n\nVNDK extension mechanism\n------------------------\n\nVendor modules that rely on extended functionalities won't work because the\nAOSP library with the same name does not have the extended functionality. If\nvendor modules directly or indirectly depend on extended functionalities,\nvendors should copy DAUX, DXUA, and DXUX shared libraries to the vendor\npartition (vendor processes always look for shared libraries in the vendor\npartition first). However, LL-NDK libraries must not be copied, so vendor\nmodules must not rely on the extended functionalities defined by the modified\nLL-NDK libraries.\n\nDAUA shared libraries can remain on the system partition if the\ncorresponding AOSP library can provide the same functionality and vendor\nmodules continue to work when the system partition is overwritten by a Generic\nSystem Image (GSI).\n\nDrop-in replacement is important because the unmodified VNDK libraries in\nthe GSI will link with the modified shared libraries on name collision. If the\nAOSP libraries are modified in an API/ABI incompatible manner, the AOSP\nlibraries in the GSI might fail to link or result in undefined behaviors."]]