VNDK 擴展

Android 設備製造商出於各種原因更改了 AOSP 庫的源代碼。一些供應商在 AOSP 庫中重新實現功能以提高性能，而其他供應商則向 AOSP 庫添加新掛鉤、新 API 或新功能。本節提供了以不破壞 CTS/VTS 的方式擴展 AOSP 庫的指南。

直接更換

所有修改後的共享庫必須是二進制兼容的，它們的 AOSP 對應物的直接替代品。所有現有的 AOSP 用戶必須能夠使用修改後的共享庫而無需重新編譯。此要求意味著以下內容：

• 不得刪除 AOSP 功能。
• 如果結構暴露給用戶，則不得更改結構。
• 功能前置條件不得強化。
• 函數必須提供等效的功能。
• 不能削弱功能的後置條件。

擴展模塊分類

按模塊定義和使用的功能對模塊進行分類。

注意：這裡使用功能而不是 API/ABI，因為可以在不更改任何 API/ABI 的情況下添加功能。

根據模塊中定義的功能，模塊可以分為DA-Module和DX-Module ：

• 僅定義 AOSP 模塊（DA-Module）不定義 AOSP 對應模塊中沒有的新功能。
  • 示例 1.一個完整且未修改的 AOSP 庫是一個 DA-Module。
  • 示例 2.如果供應商使用 SIMD 指令重寫libcrypto.so中的函數（不添加新函數），則修改後的libcrypto.so將是一個 DA-Module。
• 定義擴展模塊 (DX-Module)要么定義新功能，要么沒有 AOSP 對應模塊。
  • 示例 1.如果供應商向libjpeg.so添加幫助函數以訪問一些內部數據，則修改後的libjpeg.so將是 DX-Lib，而新添加的函數將是庫的擴展部分。
  • 示例 2.如果供應商定義了一個名為libfoo.so的非 AOSP 庫，那麼libfoo.so將是一個 DX-Lib。

根據模塊使用的功能，模塊可以分為UA-Module和UX-Module 。

• 僅使用 AOSP 模塊 (UA-Module)僅在其實現中使用 AOSP 功能。它們不依賴任何非 AOSP 擴展。
  • 示例 1.一個完整且未修改的 AOSP 庫是一個 UA-Module。
  • 示例 2.如果修改後的共享庫libjpeg.so僅依賴於其他 AOSP API，那麼它將是一個 UA-Module。
• Using-Extension Modules (UX-Module)在其實現中依賴於一些非 AOSP 功能。
  • 示例 1.如果修改後的libjpeg.so依賴於另一個名為libjpeg_turbo2.so的非 AOSP 庫，那麼修改後的libjpeg.so將是一個 UX 模塊。
  • 示例 2.如果供應商在其修改後的libjpeg.so libexif.so了來自libexif.so的新添加的功能，那麼他們修改後的libjpeg.so將是一個 UX-Module。

定義和用法是相互獨立的：

VNDK 擴展機制

依賴擴展功能的供應商模塊將無法工作，因為同名的 AOSP 庫沒有擴展功能。如果供應商模塊直接或間接依賴於擴展功能，供應商應將 DAUX、DXUA 和 DXUX 共享庫複製到供應商分區（供應商進程總是首先在供應商分區中查找共享庫）。但是，不得複制 LL-NDK 庫，因此供應商模塊不得依賴於修改後的 LL-NDK 庫定義的擴展功能。

如果相應的 AOSP 庫可以提供相同的功能並且供應商模塊在系統分區被通用系統映像 (GSI) 覆蓋時繼續工作，則 DAUA 共享庫可以保留在系統分區上。

直接替換很重要，因為 GSI 中未修改的 VNDK 庫將在名稱衝突時與已修改的共享庫鏈接。如果以 API/ABI 不兼容的方式修改 AOSP 庫，則 GSI 中的 AOSP 庫可能無法鏈接或導致未定義的行為。