VNDK の有効化

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。システム イメージ上でベンダー イメージが使用します(vendor_available のサブセット)。
        cc_library {
            name: "libThatIsVndk",
            vendor_available: true,
            vndk: {
                enabled: true,
            }
            ...
        }
        
  • vndk-sp。システム イメージ上でシステム イメージが間接的に使用します(core のサブセット)。
        cc_library {
            name: "libThatIsVndkSp",
            vendor_available: true,
            vndk: {
                enabled: true,
                support_system_process: true,
            }
            ...
        }
        
  • llndk。システム イメージとベンダー イメージの両方が使用します。
        llndk_library {
            name: "libThasIsLlndk",
        }
        

lib が vendor_available:true としてマークされている場合は、次のように 2 回ビルドされます。

  • プラットフォーム用に 1 回(その後 /system/lib にインストールされます)。
  • ベンダー用に 1 回(その後 /vendor/lib/system/lib/vndk または /system/lib/vndk-sp にインストールされます)。

lib のベンダーのバージョンは、-D__ANDROID_VNDK__ とともにビルドされます。 Android の今後のバージョンで大幅に変更される可能性のある非公開システム コンポーネントは、このフラグで無効になります。さらに、各ライブラリがそれぞれ異なるセットのヘッダー(liblog など)をエクスポートします。ターゲットのベンダー バリアントに固有のオプションは、以下にある Android.bp ファイルで指定できます。

target: { vendor: { … } }

コードベースの VNDK の有効化

コードベースの VNDK を有効化するには:

  1. vendor.img パーティションと system.img パーティションの必須サイズを計算して対象となるかどうかを判断します。
  2. BOARD_VNDK_VERSION=current を有効にします。BoardConfig.mk に追加することも、ともにコンポーネントを直接ビルドすることもできます(例: m -j BOARD_VNDK_VERSION=current MY-LIB)。

BOARD_VNDK_VERSION=current を有効にしたら、ビルドシステムは、次の依存関係とヘッダーの要件を適用します。

依存関係の管理

vndk に存在しない、または vendor オブジェクトとして存在しない core コンポーネントに依存する vendor オブジェクトは、次のいずれかのオプションを使用して解決する必要があります。

  • 依存関係は削除できます。
  • vendorcore コンポーネントを所有する場合は、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_WIFIgetpwnam("wifi")->pw_uid に変更します。
    • (gid_t)AID_SDCARD_Rgetgrnam("sdcard_r")->gr_gid に変更します。
    詳しくは、private/android_filesystem_config.h を参照してください。
  • ハードコードされた AIS の場合は、cutils/android_filesystem_config.h を含めます。