自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
VNDK 擴充功能
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Android 裝置製造商會基於各種原因變更 AOSP 程式庫的原始碼。部分供應商會重新實作 AOSP 程式庫中的函式,以提升效能,而其他供應商則會在 AOSP 程式庫中新增鉤子、API 或功能。本節提供延伸 AOSP 程式庫的規範,以免破壞 CTS/VTS。
直接取代
所有經過修改的共用程式庫都必須與二進位檔相容,並且可直接取代對應的 AOSP 程式庫。所有現有的 AOSP 使用者都必須能夠使用經過修改的共用程式庫,而無須重新編譯。這項規定暗示以下事項:
- 不得移除 AOSP 函式。
- 如果結構體會公開給使用者,則不得變更這些結構體。
- 函式的前置條件不得強化。
- 函式必須提供等同的功能。
- 函式的後置條件不得減弱。
擴充模組分類
依據模組定義和使用的功能進行分類。
注意:此處使用「功能」而非「API/ABI」,是因為可以新增功能,而無須變更任何 API/ABI。
視模組中定義的功能而定,模組可分為 DA-Module 和 DX-Module:
-
僅定義 AOSP 模組 (DA 模組) 不會定義 AOSP 對應項目中沒有的新功能。
- 範例 1:完整且未經修改的 AOSP 程式庫就是 DA 模組。
- 範例 2:如果供應商使用 SIMD 指令重寫
libcrypto.so
中的函式 (不新增新函式),則經過修改的 libcrypto.so
會是 DA 模組。
-
定義擴充功能模組 (DX-Module) 會定義新功能,或沒有 AOSP 對應項目。
- 範例 1:如果供應商在
libjpeg.so
中加入輔助函式,以便存取某些內部資料,則經過修改的 libjpeg.so
會是 DX-Lib,而新加入的函式則是程式庫的擴充部分。
- 範例 2:如果供應商定義名為
libfoo.so
的非 AOSP 程式庫,libfoo.so
就會是 DX-Lib。
根據模組使用的功能,模組可分為 UA 模組和 UX 模組。
-
僅使用 AOSP 模組 (UA-Module) 只會在實作中使用 AOSP 功能。且不依賴任何非 AOSP 擴充功能。
- 範例 1:完整且未經修改的 AOSP 程式庫是 UA 模組。
- 範例 2:如果經過修改的共用程式庫
libjpeg.so
只依附其他 AOSP API,則會是 UA 模組。
-
使用擴充功能模組 (UX-Module) 會在實作中使用部分非 AOSP 功能。
- 範例 1:如果經過修改的
libjpeg.so
依賴另一個名為 libjpeg_turbo2.so
的非 AOSP 程式庫,則經過修改的 libjpeg.so
會是 UX 模組。
- 範例 2:如果供應商在修改過的
libexif.so
中新增函式,且修改過的 libjpeg.so
使用 libexif.so
中新增的函式,則修改過的 libjpeg.so
就是 UX 模組。
定義和用法彼此獨立:
|
使用的功能 |
僅限 Android 開放原始碼計畫 (通用 Analytics) |
延伸 (使用者體驗) |
定義的功能 |
僅限 Android 開放原始碼計畫 (DA) |
DAUA |
DAUX |
延伸 (DX) |
DXUA |
DXUX |
VNDK 擴充功能機制
供應商模組依賴的擴充功能無法運作,因為同名 AOSP 程式庫沒有擴充功能。如果供應商模組直接或間接依附於擴充功能,供應商應將 DAUX、DXUA 和 DXUX 共用程式庫複製到供應商分區 (供應商程序一律會先在供應商分區中尋找共用程式庫)。不過,請勿複製 LL-NDK 程式庫,供應商模組也不應仰賴經過修改的 LL-NDK 程式庫所定義的擴充功能。
如果對應的 AOSP 程式庫可提供相同功能,且供應商模組在系統分區遭到一般系統映像檔 (GSI) 覆寫時仍能繼續運作,DAUA 共用程式庫便可保留在系統分區。
由於 GSI 中未經修改的 VNDK 程式庫會在名稱衝突時連結至經過修改的共用程式庫,因此使用即時替換功能十分重要。如果 AOSP 程式庫以 API/ABI 不相容的方式修改,GSI 中的 AOSP 程式庫可能會連結失敗,或導致未定義的行為。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","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 (世界標準時間)。"],[],[],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."]]