Vendor Native Development Kit(VNDK)では、ベンダーとシステムを切り離して扱うために、コードベースにいくつかの変更が必要です。ベンダーまたは OEM のコードベースで VNDK を有効にするには、以下のガイドをご覧ください。
ビルドシステム ライブラリ
ビルドシステムには、ライブラリ(共有、静的、ヘッダー)やバイナリなど、数種類のオブジェクトが含まれています。
図 1. ビルドシステム ライブラリ。
core
ライブラリは、システム イメージ上でシステム イメージによって使用されます。このライブラリがvendor
ライブラリ、vendor_available
ライブラリ、vndk
ライブラリ、vndk-sp
ライブラリによって使用されることはありません。cc_library { name: "libThatIsCore", ... }
vendor-only
(またはproprietary
)ライブラリは、ベンダー イメージ上でベンダー イメージによって使用されます。cc_library { name: "libThatIsVendorOnly", proprietary: true, # or: vendor: true, # (for things in AOSP) ... }
vendor_available
ライブラリは、ベンダー イメージ上でベンダー イメージによって使用されます(core
の重複が含まれている場合があります)。cc_library { name: "libThatIsVendorAvailable", vendor_available: true, ... }
vndk
ライブラリは、システム イメージ上でベンダー イメージによって使用されます。cc_library { name: "libThatIsVndk", vendor_available: true, vndk: { enabled: true, } ... }
vndk-sp
ライブラリは、ベンダー イメージだけでなく、システム イメージによっても間接的に使用されます。cc_library { name: "libThatIsVndkSp", vendor_available: true, vndk: { enabled: true, support_system_process: true, } ... }
llndk
ライブラリは、システム イメージとベンダー イメージの両方によって使用されます。cc_library { name: "libThatIsLlndk", llndk: { symbol_file: "libthatisllndk.map.txt" } ... }
lib が vendor_available:true
としてマークされている場合は、次のように 2 回ビルドされます。
- プラットフォーム用に 1 回(その後
/system/lib
にインストールされます) - ベンダー用に 1 回(その後
/vendor/lib
または VNDK APEX にインストールされます)
lib のベンダー バージョンは、-D__ANDROID_VNDK__
とともにビルドされます。Android の今後のバージョンで大幅に変更される可能性のある非公開システム コンポーネントは、このフラグで無効になります。さらに、各ライブラリがそれぞれ異なるセットのヘッダー(liblog
など)をエクスポートします。ターゲットのベンダー バリアントに固有のオプションは、以下にある Android.bp
ファイルで指定できます。
target: { vendor: { … } }
コードベースの VNDK の有効化
コードベースの VNDK を有効化するには:
vendor.img
パーティションとsystem.img
パーティションの必須サイズを計算して対象となるかどうかを判断します。BOARD_VNDK_VERSION=current
を有効にします。BoardConfig.mk
に追加することも、コンポーネントとともに直接ビルドすることもできます(例:m -j BOARD_VNDK_VERSION=current MY-LIB
)。
ビルドシステムは、BOARD_VNDK_VERSION=current
を有効にした後、以下の依存関係とヘッダーの要件を適用します。
依存関係を管理する
vndk
に存在しない、または vendor
オブジェクトとして存在しない core
コンポーネントに依存する vendor
オブジェクトは、次のいずれかのオプションを使用して解決する必要があります。
- 依存関係は削除できます。
vendor
がcore
コンポーネントを所有する場合は、vendor_available
またはvendor
としてマークすることが可能です。vndk
のコア オブジェクト部分の変更は、Google に送信される可能性があります。
さらに、core
コンポーネントが vendor
コンポーネントに依存している場合、vendor
コンポーネントを core
コンポーネントにするか、または依存関係を別の方法で解消する必要があります(たとえば、依存関係を削除する、または依存関係を vendor
コンポーネントに移動する)。
ヘッダーを管理する
ヘッダーのビルドに -D__ANDROID_VNDK__
を使用するかしないかをビルドシステムが把握できるようにするには、グローバル ヘッダーの依存関係を解消する必要があります。たとえば、utils/StrongPointer.h
のような libutils ヘッダーは、ヘッダー ライブラリ libutils_headers
を使用して引き続きアクセスできます。
一部のヘッダー(unistd.h
など)は、推移的に含めることはできなくなりましたが、ローカルに含めることができます。
最後に、private/android_filesystem_config.h
の公開部分は cutils/android_filesystem_config.h
に移動しました。これらのヘッダーを管理するには、次のいずれかの操作を行います。
- 可能な場合、すべての
AID_*
マクロをgetgrnam
またはgetpwnam
の呼び出しに置き換えて、private/android_filesystem_config.h
への依存関係を解消します。次に例を示します。(uid_t)AID_WIFI
をgetpwnam("wifi")->pw_uid
に変更します。(gid_t)AID_SDCARD_R
をgetgrnam("sdcard_r")->gr_gid
に変更します。
private/android_filesystem_config.h
をご覧ください。 - ハードコードされた AIS の場合は、
cutils/android_filesystem_config.h
を含めます。