2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
VNDK 拡張機能
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android デバイスのメーカーは、さまざまな理由で AOSP ライブラリのソースコードを変更します。たとえばパフォーマンスを向上させるために AOSP ライブラリの関数を再実装する場合や、AOSP ライブラリに新しいフックや API、機能を追加する場合などです。このセクションでは、CTS や VTS を破壊せずに AOSP ライブラリを拡張するためのガイドラインを示します。
ドロップイン代替
変更する共有ライブラリはすべて、バイナリと互換性があり、対応する AOSP のドロップイン代替である必要があります。すべての既存 AOSP ユーザーが、再コンパイルすることなく変更した共有ライブラリを使用できる必要があります。この要件は、以下を意味します。
- AOSP 関数を削除しないでください。
- 構造がユーザーに公開されている場合は、その構造を変更しないでください。
- 関数の事前条件を強化しないでください。
- 関数は同等の機能を提供する必要があります。
- 関数の事後条件を弱くしないでください。
拡張モジュールの分類
定義および使用する機能別にモジュールを分類します。
注: API や ABI を変更することなく機能を追加できるため、ここでは API や ABI の代わりに機能を使用します。
モジュール内で定義される機能により、モジュールは DA-Module と DX-Module に分類されます。
- Defining-only-AOSP モジュール(DA-Module)は、対応する AOSP にない新しい機能を定義しません。
- 例 1。そのままの変更されていない AOSP ライブラリは、DA-Module です。
- 例 2。ベンダーが(新しい関数を追加せずに)
libcrypto.so
内の関数を SIMD 命令に書き換えると、変更された libcrypto.so
は DA-Module になります。
- Defining-Extension モジュール(DX-Module)は、新しい機能を定義するか、または対応する AOSP が存在しないモジュールです。
- 例 1。ベンダーがヘルパー関数を
libjpeg.so
に追加して一部の内部データにアクセスする場合、変更した libjpeg.so
は DX-Lib になり、新しく追加された関数がライブラリの拡張部分になります。
- 例 2。ベンダーが
libfoo.so
という名前の非 AOSP ライブラリを定義した場合、libfoo.so
は DX-Lib になります。
モジュールが使用する機能に応じて、モジュールは UA-Module と UX Module に分類されます。
-
Using-only-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-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 ライブラリをコピーしないでください。
対応する AOSP ライブラリが同じ機能を提供でき、システム パーティションが Generic System Image(GSI)によって上書きされたときにベンダー モジュールが動作を続行する場合、DAUA 共有ライブラリはシステム パーティションで引き続き利用できます。
GSI の変更されていない VNDK ライブラリは、名前衝突で変更した共有ライブラリとリンクするため、ドロップイン代替は重要な手順です。AOSP ライブラリが API / ABI と互換性のない方法で変更された場合、GSI の AOSP ライブラリでリンクが失敗したり、未定義の動作が発生したりすることがあります。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。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."]]