ベンダー ネイティブ開発キット (VNDK) の概要

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Vendor Native Development Kit (VNDK)は、dlopen の実行時に、ベンダーまたは製品パーティション内の他のライブラリまたはバイナリによって使用されるライブラリのセットです。

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などのベンダー実行可能ファイルから生成されたプロセスです。

VNDK の概念

理想的な Android 8.0 以降の世界では、フレームワーク プロセスはベンダー共有ライブラリをロードせず、すべてのベンダー プロセスはベンダー共有ライブラリ (およびフレームワーク共有ライブラリの一部) のみをロードし、フレームワーク プロセスとベンダー プロセス間の通信は HIDL とハードウェアによって管理されます。バインダー。

このような世界には、フレームワーク共有ライブラリの安定したパブリック API がベンダー モジュール開発者にとって十分ではない可能性があり (API は Android リリース間で変更される可能性があります)、フレームワーク共有ライブラリの一部がベンダー プロセスにアクセスできる必要があります。さらに、パフォーマンス要件が妥協につながる可能性があるため、一部の応答時間が重要な 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.solibGLESv1_CM.solibGLESv2.solibGLESv3.solibandroid_net.solibc.solibdl.soliblog.solibm.solibnativewindow.solibneuralnetworks.solibsync.solibvndksupport.so 、およびlibvulkan.so
  • 適格な VNDK ライブラリ (VNDK)は、安全に 2 回コピーできるフレームワーク共有ライブラリです。フレームワーク モジュールベンダー モジュールは、独自のコピーとリンクできます。フレームワーク共有ライブラリは、次の基準を満たす場合にのみ、適格な VNDK ライブラリになることができます。
    • フレームワークとの間で IPC を送受信しません。
    • ART 仮想マシンとは関係ありません。
    • 不安定なファイル形式のファイル/パーティションを読み書きしません。
    • 法的審査を必要とする特別なソフトウェア ライセンスはありません。
    • そのコードの所有者は、ベンダーの使用法に異議を唱えていません。
  • フレームワーク専用ライブラリ (FWK-ONLY)は、上記のカテゴリに属さないフレームワーク共有ライブラリです。これらのライブラリ:
    • フレームワークの内部実装の詳細と見なされます。
    • ベンダー モジュールからアクセスしてはなりません。
    • 不安定な ABI/API があり、API/ABI の互換性が保証されていません。
    • コピーされません。

同一プロセス HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) は、 Vendor Shared Librariesとして実装され、 Framework Processesに読み込まれる一連の事前定義された HAL です。 SP-HAL はリンカー名前空間によって分離されます (共有ライブラリに表示されるライブラリとシンボルを制御します)。 SP-HAL はLL-NDKVNDK-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
  • android.hardware.renderscript@1.0-impl.so
  • android.hardware.graphics.mapper@2.0-impl.so

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

以下は、RS 例外 (FWK-ONLY-RS) のあるフレームワークのみのライブラリです。

  • libft2.so (レンダースクリプト)
  • libmediandk.so (レンダースクリプト)

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_VERSIONcurrent等しくない場合は、 BOARD_VNDK_VERSIONを使用します。
  • BOARD_VNDK_VERSIONcurrent等しい場合:
    • PLATFORM_VERSION_CODENAMERELの場合、 PLATFORM_SDK_VERSION (例: 28 ) を使用します。
    • それ以外の場合は、 PLATFORM_VERSION_CODENAME (例: P ) を使用します。

ベンダー テスト スイート (VTS)

Android Vendor Test Suite (VTS) は、空でないro.vndk.versionプロパティを義務付けています。新しく起動したデバイスとアップグレード中のデバイスの両方でro.vndk.versionを定義する必要があります。一部の VNDK テスト ケース ( VtsVndkFilesTestVtsVndkDependencyTestなど) は、 ro.vndk.versionプロパティに依存して、一致する適格な VNDK ライブラリ データ セットを読み込みます。