いくつかの例外を除き、HIDL インターフェース パッケージは hardware/interfaces
ディレクトリまたは vendor/
ディレクトリにあります。hardware/interfaces
トップレベルは、android.hardware
パッケージの名前空間に直接マッピングされます(バージョンは、パッケージ(インターフェースではなく)の名前空間の下のサブディレクトリです)。
hidl-gen
コンパイラは、.h
ファイルと .cpp
ファイルのセットとして .hal
ファイルをコンパイルします。自動生成されたこれらのファイルから、クライアント / サーバーの実装がリンクする共有ライブラリが作成されます。この共有ライブラリを作成する Android.bp
ファイルは、hardware/interfaces/update-makefiles.sh
スクリプトによって自動生成されます。hardware/interfaces
に新しいパッケージを追加するたび、あるいは既存のパッケージに .hal
ファイルを追加または削除するたびに、スクリプトを再実行し、生成された共有ライブラリが最新であることを確認する必要があります。
たとえば、IFoo.hal
のサンプル ファイルは hardware/interfaces/samples/1.0
に配置する必要があります。IFoo.hal
ファイルのサンプルは、次のようにsamples パッケージに IFoo インターフェースを作成します。
package android.hardware.samples@1.0; interface IFoo { struct Foo { int64_t someValue; handle myHandle; }; someMethod() generates (vec<uint32_t>); anotherMethod(Foo foo) generates (int32_t ret); };
生成されたファイル
HIDL パッケージ内に自動生成されるファイルは、パッケージと同一の名前(android.hardware.samples@1.0
など)で単一の共有ライブラリにリンクされます。また、共有ライブラリは、クライアントとサーバーに含めることができる単一のヘッダー IFoo.h
をエクスポートします。IFoo.hal
インターフェース ファイルを入力として hidl-gen
コンパイラを使用するバインドモードには、次のような自動生成ファイルがあります。
図 1. コンパイラによって生成されたファイル。
IFoo.h
。C++ クラスの純粋なIFoo
インターフェースを記述します(IFoo.hal
ファイルのIFoo
インターフェースで定義されたメソッドと型が含まれ、必要に応じて C++ 型に変換されます)。このインターフェースの実装に使用される RPC メカニズム(HwBinder
など)に関連する詳細は含まれません。クラスは、パッケージとバージョン(例:::android::hardware::samples::IFoo::V1_0
)が名前空間となります。クライアントとサーバーの両方にこのヘッダーが含まれます。クライアントはこのファイルのメソッドを呼び出し、サーバーはそのメソッドを実装します。IHwFoo.h
。インターフェースで使用されるデータ型をシリアル化する関数の宣言を含むヘッダー ファイル。 デベロッパーは、このヘッダー(クラスは含まれません)を直接含めないようにしてください。BpHwFoo.h
。IFoo
を継承し、インターフェースのHwBinder
プロキシ(クライアント側)の実装を記述するクラス。デベロッパーは、このクラスを直接参照しないようにしてください。BnHwFoo.h
。IFoo
の実装へのリファレンスを保持し、インターフェースのHwBinder
スタブ(サーバー側)実装を記述するクラス。デベロッパーは、このクラスを直接参照しないようにしてください。FooAll.cpp
。HwBinder
プロキシとHwBinder
スタブの両方の実装を含むクラス。クライアントがインターフェース メソッドを呼び出すと、プロキシは自動的にクライアントからの引数をマーシャリングし、トランザクションをバインダのカーネル ドライバに送信します。このカーネル ドライバはトランザクションを受信側のスタブに送信します(その後、実際のサーバーの実装を呼び出します)。
各ファイルは、aidl-cpp
によって生成されるファイルと同様に構成されます(詳細については、HIDL の概要の「パススルー モード」を参照してください)。HIDL で使用される RPC メカニズムに依存しない唯一の自動生成ファイルは IFoo.h
です(他のすべてのファイルは、HIDL で使用される HwBinder RPC メカニズムに関連付けられます)。そのため、クライアントとサーバーの実装では、IFoo
以外を直接参照しないようにしてください。これを実現するには、IFoo.h
のみを含め、生成された共有ライブラリにリンクさせます。
共有ライブラリへのリンク
パッケージ内の任意のインターフェースを使用するクライアントまたはサーバーは、次のいずれか(1 つの)の場所にパッケージの共有ライブラリを含める必要があります。
- Android.mk 内:
LOCAL_SHARED_LIBRARIES += android.hardware.samples@1.0
- Android.bp 内:
shared_libs: [ /* ... */ "android.hardware.samples@1.0", ],
追加する必要のある追加ライブラリ:
libhidlbase |
標準の HIDL データ型が含まれます。Android 10 以降では、以前 libhidltransport および libhwbinder にあったすべての記号も含まれます。
|
---|---|
libhidltransport |
さまざまな RPC/IPC メカニズムを介した HIDL 呼び出しの転送を処理します。 Android 10 はこのライブラリのサポートを終了します。 |
libhwbinder |
バインダ固有の記号。Android 10 はこのライブラリのサポートを終了します。 |
libfmq |
高速メッセージ キュー IPC。 |
名前空間
HIDL 関数および Return<T>
や Void()
などの型は、名前空間 ::android::hardware
で宣言されます。パッケージの C++ 名前空間は、パッケージの名前とバージョンによって決定されます。
たとえば、hardware/interfaces
のバージョン 1.2 のパッケージ mypackage の属性は次のとおりです。
- C++ 名前空間は
::android::hardware::mypackage::V1_2
です。 - そのパッケージの
IMyInterface
の完全修飾名は::android::hardware::mypackage::V1_2::IMyInterface
です(IMyInterface
は識別子であり、名前空間の一部ではありません)。 - パッケージの
types.hal
ファイルで定義される型は::android::hardware::mypackage::V1_2::MyPackageType
と識別されます。