Android 裝置製造商會變更 Android 開放原始碼計畫程式庫的原始碼 。部分廠商會重新實作 AOSP 程式庫中的函式,以便 提高效能,同時其他供應商加入新掛鉤、新 API 或 相關功能本節提供 以不會破壞 CTS/VTS 的方式擴充 Android 開放原始碼計畫程式庫。
直接換貨
所有修改後的共用程式庫都必須與二進位檔相容, 立即替換 Android 開放原始碼計畫相關版本。所有現有 Android 開放原始碼計畫使用者必須能夠在沒有協議條件下,使用修改後的共用資料庫 則會出現 20% 的無法變更這項規定意味著:
- 請勿移除 Android 開放原始碼計畫函式。
- 如果這類結構暴露在其內部結構上,請勿變更其結構 使用者。
- 無法強化函式的先決條件。
- 函式必須提供對等的功能。
- 函數後條件不得再削弱
擴充模組分類
依據模組定義的功能,將模組分類 use。
注意:這裡使用的功能是 而不是 API/ABI,因為您無須變更 任何 API/ABI。
視模組中定義的功能而定,模組可 這可分為 DA-Module 和 DX-Module:
-
定義僅限 Android 開放原始碼計畫模組 (DA-Module) 不會定義新的
Android 開放原始碼計畫相關版本未提供的所有功能。
- 範例 1:未經修改的 Android 開放原始碼計畫程式庫 DA 模組。
- 範例 2:如果廠商改寫函式,
含 SIMD 指示的
libcrypto.so
(未新增新品) 函式),修改後的libcrypto.so
會是 DA 模組。
-
定義擴充功能模組 (DX-Module)
功能,或是沒有 Android 開放原始碼計畫對應的版本。
- 範例 1:如果廠商新增輔助函式
libjpeg.so
:存取部分內部資料,後來修改libjpeg.so
為 DX-Lib,新增的函式將 資料庫的延伸部分 - 範例 2:如果供應商定義了名稱為
libfoo.so
,則libfoo.so
會是 DX-Lib。
- 範例 1:如果廠商新增輔助函式
視模組使用的功能而定,系統可能會將模組分類 「UA-Module」和「UX-Module」。
-
僅使用 Android 開放原始碼計畫模組 (UA-模組) 只會使用 Android 開放原始碼計畫功能
實作相關的程式碼不必仰賴任何非 Android 開放原始碼計畫擴充功能。
- 範例 1:未經修改的 Android 開放原始碼計畫程式庫 UA-模組。
- 範例 2:如果共用資料庫經過修改,
libjpeg.so
只有其他 AOSP API 才能用, 則會是 UA 模組
-
使用擴充功能模組 (UX-Module) 仰賴部分非 Android 開放原始碼計畫
導入的功能
- 範例 1:如果修改後的
libjpeg.so
依賴 另一個名為libjpeg_turbo2.so
的非 Android 開放原始碼計畫程式庫,則 修改後的libjpeg.so
會是 UX-Module。 - 範例 2:如果供應商在修改過的函式中加入新函式
libexif.so
和修改後的libjpeg.so
使用 剛剛新增的libexif.so
函式,接著修改了libjpeg.so
會是 UX-Module。
- 範例 1:如果修改後的
定義和使用方式彼此獨立:
已使用的功能 | |||
---|---|---|---|
僅限 Android 開放原始碼計畫 (UA) | 延伸 (UX) | ||
定義功能 | 僅限 Android 開放原始碼計畫 (DA) | DAUA | DAUX |
延伸 (DX) | DXUA | DXUX |
VNDK 擴充功能機制
需要使用擴充功能的供應商模組將無法運作,因為 名稱相同的 Android 開放原始碼計畫程式庫不提供擴充功能。如果 供應商模組直接或間接依附於擴充功能 供應商應將 DAUX、DXUA 和 DXUX 共用程式庫複製到供應商 (廠商程序一律會尋找供應商中的共用程式庫) 分區)。但請勿複製 LL-NDK 程式庫,因此供應商 模組不得依賴由 LL-NDK 程式庫。
如果 DAUA 共用程式庫儲存在系統分區中, 相應的 Android 開放原始碼計畫程式庫可以提供相同的功能和供應商 由一般模組覆寫系統分區時,模組仍可持續運作 系統映像檔 (GSI)。
導入替換功能十分重要,因為 GSI 會連結名稱衝突的修改共用程式庫如果 Android 開放原始碼計畫程式庫會以不相容的方式修改,亦即 Android 開放原始碼計畫 GSI 中的程式庫可能會無法連結或產生未定義的行為。