Android 裝置製造商出於各種原因更改 AOSP 庫的源代碼。一些供應商重新實現 AOSP 庫中的功能以提高效能，而其他供應商則為 AOSP 庫添加新的鉤子、新的 API 或新的功能。本節提供了以不破壞 CTS/VTS 的方式擴展 AOSP 庫的指南。
直接更換
所有修改的共享庫必須是二進位相容的，並且可以直接替換其 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 模組）要么定義新功能，要么沒有 AOSP 對應項。
- 範例 1.如果供應商向
libjpeg.so添加輔助函數來存取某些內部數據，則修改後的libjpeg.so將是 DX-Lib，新添加的函數將是庫的擴展部分。 - 範例 2.如果供應商定義了名為
libfoo.so的非 AOSP 函式庫，則libfoo.so將是 DX-Lib。
- 範例 1.如果供應商向
根據模組使用的功能，模組可以分為UA-Module和UX-Module 。
- 僅使用 AOSP 模組（UA 模組）在其實作中僅使用 AOSP 功能。它們不依賴任何非 AOSP 擴充。
- 範例 1.一個完整的、未修改的 AOSP 函式庫是一個 UA 模組。
- 範例 2.如果修改後的共用程式庫
libjpeg.so僅依賴其他 AOSP API，那麼它將是一個 UA 模組。
- 使用擴充模組（UX 模組）在其實作中依賴一些非 AOSP 功能。
- 範例 1.如果修改後的
libjpeg.so依賴另一個名為libjpeg_turbo2.so的非 AOSP 函式庫，則修改後的libjpeg.so將會是一個 UX 模組。 - 範例 2.如果供應商向其修改後的
libexif.so添加了新函數，並且其修改後的libjpeg.so使用libexif.so中新添加的函數，則其修改後的libjpeg.so將是一個UX 模組。
- 範例 1.如果修改後的
定義和用法是相互獨立的：
| 使用的功能 | |||
|---|---|---|---|
| 僅 AOSP (UA) | 擴展（使用者體驗） | ||
| 定義的功能 | 僅 AOSP (DA) | DAUA | 多用戶 |
| 擴展 (DX) | DXUA | DXUX | |
VNDK擴展機制
依賴擴充功能的供應商模組將無法運作，因為同名的 AOSP 庫沒有擴充功能。如果供應商模組直接或間接依賴擴充功能，則供應商應將 DAUX、DXUA 和 DXUX 共用程式庫複製到供應商分區（供應商進程始終首先在供應商分區中尋找共用程式庫）。但是，不得複製 LL-NDK 函式庫，因此供應商模組不得依賴修改後的 LL-NDK 函式庫定義的擴充功能。
如果相應的 AOSP 庫可以提供相同的功能，並且當系統分區被通用系統映像 (GSI) 覆蓋時供應商模組繼續工作，則 DAUA 共享庫可以保留在系統分區上。
直接替換很重要，因為 GSI 中未修改的 VNDK 庫將在名稱衝突時與修改後的共享庫連結。如果以 API/ABI 不相容的方式修改 AOSP 函式庫，GSI 中的 AOSP 函式庫可能無法連結或導致未定義的行為。