Vendor Native Development Kit（VNDK）の概要

Vendor Native Development Kit（VNDK）は、dlopen の実行時に、ベンダーまたはプロダクト パーティション内で、他のライブラリやバイナリに使用されるライブラリのセットです。

サポートの終了

Vendor NDK は、フレームワークとベンダーコード間の API を提供する目的で Android 8.0 で導入されました。VNDK はこれまで、長年にわたり問題なく使用され続けてきましたが、以下のような欠点もあります。

• ストレージ
• デバイスから使用されているかどうかに関係なく、単一の VNDK APEX ですべての VNDK ライブラリがパッケージ化されます。
• 複数のバージョンのベンダー イメージをサポートする目的で、GSI には複数のバージョンの VNDK APEX が含まれています。
• 更新可能性
• プラットフォームのアップデートと分離して VNDK APEX をアップデートすることが困難です。
• ベンダー イメージは、無線（OTA）を介して頻繁に更新されます。そのため、VNDK をシステム イメージ内にパッケージ化する利点が薄まります。

このような問題をふまえて、Google は Android 15 以降で VNDK のサポートを終了することにしました。

VNDK のサポートの終了に関する詳細

すべての VNDK ライブラリは VNDK APEX にパッケージ化され、システム（-ext）イメージにインストールされます。VNDK のサポート終了に伴い、これまでの VNDK ライブラリは、他のベンダーが利用できるライブラリと同様に、ベンダー（またはプロダクト）イメージにインストールされます。以下の機能は、VNDK のサポート終了にあわせて廃止されます。

• Android 15 の VNDK APEX
• ターゲット VNDK のバージョンを示すシステム プロパティが廃止されます（ベンダーまたはプロダクト パーティションが Android 15 用にビルドされている場合）
  • ro.vndk.version
  • ro.product.vndk.version
• VNDK がなくなるため、VNDK 最適化は利用できなくなります。
  • Android Go デバイスの TARGET_VNDK_USING_CORE_VARIANT
  • Vendor APEX の use_vndk_as_stable
• ベンダー スナップショット。これは VNDK に大きく依存します。

このサポートの終了の影響を受けない例外

VNDK のサポートの終了に伴い、以下の機能が変更されることはありません。

• VNDK バージョン 14 以前を使用する VNDK APEX。既存のベンダー イメージをサポートするために必要になります。
• LL-NDK は、VNDK の一部ではありません。

VNDK を使用する理由

AOSP では、システム パーティションを最新のフレームワーク バージョンにアップグレードできるフレームワークのみの更新が可能です。それに対して、ベンダー パーティションは変更されず元の状態を維持します。各パーティションのバイナリは、異なる時間にビルドされていても相互に動作可能でなければなりません。

フレームワークのみの更新には、次のような問題があります。

• フレームワーク モジュールとベンダー モジュール間の依存関係。Android 8.0 以前では、ベンダー パーティションとシステム パーティションのモジュールは相互にリンクできました。しかし、ベンダー モジュールからの依存関係は、フレームワーク モジュールの開発に不要な制限を課していました。
• AOSP ライブラリへの拡張機能。Android では、システム パーティションが標準の Generic System Image（GSI）に置き換えられると、すべての Android デバイスが CTS に合格する必要があります。しかし、ベンダーが AOSP ライブラリを拡張して HIDL の実装にパフォーマンスや機能を追加すると、システム パーティションを標準の GSI でフラッシュするときにベンダーの HIDL 実装が破損する可能性があります。このような破損を防ぐためのガイドラインは、VNDK 拡張機能でご確認いただけます。

このような問題に対処するために、Android には VNDK（このセクションで説明します）、HIDL、hwbinder、デバイスツリー オーバーレイ、sepolicy オーバーレイなど、複数の機能があります。

VNDK 固有の用語

VNDK 関連のドキュメントでは以下の用語を使用します。

• モジュールは、共有ライブラリまたは実行可能ファイルを指します。モジュールはビルド時の依存関係を作成します。
• プロセスは、実行可能ファイルから生成されるオペレーティング システムのタスクです。プロセスは実行時の依存関係を作成します。
• フレームワークで修飾された用語は system パーティションに関連しています。
• フレームワーク実行可能ファイルは、/system/bin または /system/xbin にある実行可能ファイルを指します。
• フレームワーク共有ライブラリは、/system/lib[64] にある共有ライブラリを指します。
• フレームワーク モジュールは、フレームワーク共有ライブラリとフレームワーク実行可能ファイルの両方を指します。
• フレームワーク プロセスは、フレームワーク実行可能ファイルから生成されるプロセスです（例: /system/bin/app_process）。
• ベンダーで修飾された用語は vendor パーティションに関連しています。
• ベンダー実行可能ファイルは、/vendor/bin にある実行可能ファイルを指します。
• ベンダー共有ライブラリは、/vendor/lib[64] にある共有ライブラリを指します。
• ベンダー モジュールは、ベンダー実行可能ファイルとベンダー共有ライブラリの両方を指します。
• ベンダー プロセスは、ベンダー実行可能ファイルから生成されるプロセスです（例: /vendor/bin/android.hardware.camera.provider@2.4-service）。

注: Generic System Image（GSI）は標準の Android システム イメージを意味し、Google によって、対応するブランチ（リリース ブランチと似ていますが、いくつかのバグ修正や一般化を含みます）からビルドされてリリースされます。

VNDK のコンセプト

フレームワーク プロセスがベンダーの共有ライブラリを読み込まず、すべてのベンダー プロセスがベンダーの共有ライブラリ（およびフレームワークの共有ライブラリの一部）のみを読み込み、フレームワーク プロセスとベンダー プロセス間の通信が HIDL とハードウェア バインダーによって管理されているのが、Android 8.0 以降の理想的な状況です。

このような状況では、API は Android リリース間で変更が可能であるものの、フレームワーク共有ライブラリの安定した公開 API がベンダー モジュールのデベロッパーには不十分である可能性があるため、フレームワーク共有ライブラリの一部がベンダー プロセスからアクセスできる必要があります。さらに、パフォーマンス要件の妥協につながる可能性があるため、応答時間が重視される HAL の一部は扱い方も異なる必要があります。

以下のセクションでは、VNDK でベンダーと Same-Process HAL（SP-HAL）のフレームワーク共有ライブラリを処理する方法について説明します。

ベンダー用のフレームワーク共有ライブラリ

このセクションでは、ベンダーのプロセスからアクセス可能な共有ライブラリを分類するための条件について説明します。複数の Android リリースでベンダー モジュールをサポートするには、2 つの方法があります。

1. フレームワーク共有ライブラリの ABI や API を安定化させる。新しいフレームワーク モジュールと古いベンダー モジュールは、同じ共有ライブラリを使用してメモリのフットプリントと保存容量を削減できます。また、独自の共有ライブラリは、複数の二重読み込みの問題を避けることもできます。しかし、安定した ABI や API を維持するとなると開発コストが高くつき、すべてのフレームワーク共有ライブラリでエクスポートされるすべての ABI や API を安定させるのは現実的ではありません。
2. 古いフレームワークの共有ライブラリをコピーする。サイドチャネルに対する強力な制限があり、バインダーやソケット、パイプ、共有メモリ、共有ファイル、システム プロパティを含むフレームワーク モジュールとベンダー モジュール間で通信するためのすべてのメカニズムとして定義されます。通信プロトコルが固定され、安定してる場合を除き、通信はできません（例: hwbinder を通じた HIDL）。共有ライブラリを二重読み込みすると問題が発生する場合もあります。たとえば、新しいライブラリによって作成されたオブジェクトが古いライブラリの関数に渡された場合、これらのライブラリでオブジェクトの解釈が異なるため、エラーとなる可能性があります。

共有ライブラリの特性に応じて、異なる方法が使用されます。その結果、フレームワーク共有ライブラリは次の 3 つのサブカテゴリに分類されます。

• LL-NDK ライブラリは、安定性があるとされるフレームワーク共有ライブラリです。デベロッパーは、API や ABI の安定性が維持されるよう努めています。
  • LL-NDK には、libEGL.so、libGLESv1_CM.so、libGLESv2.so、libGLESv3.so、libandroid_net.so、libc.so、libdl.so、liblog.so、libm.so、libnativewindow.so、libneuralnetworks.so、libsync.so、libvndksupport.so、libvulkan.so のライブラリが含まれています。
• 有効な VNDK ライブラリ（VNDK）は、2 回コピーしても安全なフレームワーク共有ライブラリです。フレームワーク モジュールとベンダー モジュールは、それぞれ自身のコピーにリンクできます。フレームワーク共有ライブラリは、次の条件を満たす場合にのみ有効な VNDK ライブラリになります。
  • フレームワークとの間で IPC を送受信しない。
  • ART 仮想マシンとは関係がない。
  • 不安定なファイル形式でファイルやパーティションを読み書きしない。
  • 法的審査が必要な特別なソフトウェア ライセンスがない。
  • ベンダーの用途について、コード所有者からの異論がない。
• フレームワークのみのライブラリ（FWK-ONLY）は、上記のカテゴリには属さないフレームワーク共有ライブラリです。これらのライブラリの特徴は次のとおりです。
  • フレームワーク内部実装の詳細と見なされます。
  • ベンダー モジュールからはアクセスできません。
  • 不安定な ABI や API があり、API と ABI の互換性は保証されません。
  • コピーされません。

Same-Process HAL（SP-HAL）

Same-Process HAL（SP-HAL）は、ベンダー共有ライブラリとして実装され、フレームワーク プロセスに読み込まれた、事前決定済み HAL のセットです。リンカー名前空間（共有ライブラリに表示されるライブラリとシンボルを制御）によって分離されます。LL-NDK と VNDK-SP にのみ依存している必要があります。

VNDK-SP は、有効な VNDK ライブラリの事前定義済みサブセットです。VNDK-SP ライブラリを慎重に確認して、フレームワーク プロセスへの VNDK-SP ライブラリの二重読み込みが問題を引き起こさないようにします。SP-HAL と VNDK-SP は、どちらも Google が定義しています。

次のライブラリは、承認済みの SP-HAL です。

• libGLESv1_CM_${driver}.so
• libGLESv2_${driver}.so
• libGLESv3_${driver}.so
• libEGL_${driver}.so
• vulkan.${driver}.so
• [e-mail]
• [e-mail]

VNDK-SP ライブラリは Android.bp ファイルで vndk: { support_system_process: true } を指定します。vndk: {private:true} も指定されている場合、これらのライブラリは VNDK-SP-Private と呼ばれ、SP-HALS には表示されません。

以下は、RS 例外を含むフレームワークのみのライブラリ（FWK-ONLY-RS）です。

• libft2.so（Renderscript）
• libmediandk.so（Renderscript）

注意: Android 12 以降、RenderScript API は非推奨になっています。この API は引き続き機能しますが、デバイス メーカーとコンポーネント メーカーによるハードウェア アクセラレーションのサポートはいずれ終了すると予想されます。AOSP では、GPU アクセラレーションを最大限に活用できるように、RenderScript からの移行を推奨しています。

VNDK のバージョン管理

VNDK 共有ライブラリはバージョニングされます。

• ro.vndk.version システム プロパティは、自動的に /vendor/default.prop に追加されます。
• VNDK および VNDK-SP 共有ライブラリは、VNDK APEX com.android.vndk.v${ro.vndk.version} としてインストールされ、/apex/com.android.vndk.v${ro.vndk.version} にマウントされます。

ro.vndk.version の値は以下のアルゴリズムによって選択されます。

• BOARD_VNDK_VERSION が current と等しくない場合は、BOARD_VNDK_VERSION を使用します。
• BOARD_VNDK_VERSION が current と等しい場合は次のようになります。
• PLATFORM_VERSION_CODENAME が REL の場合は、PLATFORM_SDK_VERSION を使用します（例: 28）。
• それ以外の場合は、PLATFORM_VERSION_CODENAME を使用します（例: P）。

ベンダー テストスイート（VTS）

Android のベンダー テストスイート（VTS）は、空ではない ro.vndk.version プロパティを必須としています。新たにリリースされたデバイスとアップグレードするデバイスの両方で ro.vndk.version を定義する必要があります。一部の VNDK テストケース（例: VtsVndkFilesTest と VtsVndkDependencyTest）は、一致する有効な VNDK ライブラリ データセットを読み込むために ro.vndk.version プロパティに依存します。