Android VNDK/VSDK スナップショットコンパイルフレームワークの分析

1. 背景

背景 1:

Android バージョンの断片化の問題を解決するために、安定した新しい SoC サプライヤーインターフェイスと、ベンダーを指定する HAL インターフェイス定義言語 (HIDL/Stable AIDL、テクノロジースタックは引き続き Binder) を提供する Treble アーキテクチャが導入されました。 HAL とシステムフレームワークインターフェイス、システムフレームワークとベンダー HAL の分離、システム/ベンダーコンポーネントの機能は相互に独立しているため、ベンダーフリーズが可能になります。

背景 2:

調査の結果、AOSP ソースコードのベンダーコンポーネントの 30% ～ 40% がシステムコンポーネントと結合されており、結合ウェアハウスの種類には主に、AOSP フレームワークフレームワークウェアハウス、プレビルド、外部、プラットフォームウェアハウス、ODM 自社開発ウェアハウス、そして倉庫を建てます。

背景 3:

その直後、Google は Treble アーキテクチャをさらに進化させ、システム/ベンダーコンポーネント間のインターフェイス機能を強化し、AndroidR から始まる VNDK および VSDK のスナップショットソリューションを設計しました。

システムコンポーネントは、ベンダースナップショットを形成するためにプリコンパイルされており、さまざまな Android バージョンのベンダーコンポーネントで使用できます。この部分は、Treble ソリューションの実装に対する重要なリンクおよび基本サポートでもあります。

2. VNDKの基本概念

Android の Treble アーキテクチャでは、システム/ベンダーコンポーネント間の結合関係を標準化および制約するために、ネイティブライブラリをいくつかのカテゴリに分割し、制御システム/ベンダーコンポーネントは、さまざまな種類の相互結合度および使用制約を定義することによって実現されます。モジュールカップリング。

2.1コアライブラリ：

システムイメージ内でのみ、システムモジュールによってのみ使用され、ベンダー、vendor_available、vndk、および vndk-sp のライブラリに依存することは許可されません

その bp の形式は次のとおりです。

cc_library {

    name: "libThatIsCore",

    ...

}

Vendor、vendor_available、vndk、および vndk-sp 属性は含まれません

2.2 ベンダー専用（独自）ライブラリ：

ベンダー使用のみ。バイナリの場所はベンダーミラー内にあります。

その bp の形式は次のとおりです。

cc_library {

    name: "libThatIsVendorOnly",

    proprietary: true,

    # or: vendor: true, # (for things in AOSP)

    ...

}

vndk プロパティは含まれません

2.3 Vendor_available ライブラリ:

ベンダーイメージで使用されるライブラリには、ベンダーバリアントとコアバリアントの両方があり、ベンダーイメージとシステムイメージにパッケージ化されています。その bp の形式は次のとおりです。

cc_library {

    name: "libThatIsVendorAvailable",

    vendor_available: true,

    ...

}

vndk プロパティは含まれません

2.4 vndk ライブラリ：

ベンダーモジュールによって使用されますが、バイナリはシステムにミラーリングされます

その bp の形式は次のとおりです。

cc_library {
    name: "libThatIsVndk",
    vendor_available: true,
    vndk: {
        enabled: true,
    }
    ...
}

Vendor_available プロパティと vnd.enable プロパティの両方が存在します

2.5 vndk-sp ライブラリ:

ベンダーによって直接使用され、システムイメージによって間接的に使用されるライブラリには、システムイメージ内にそのバイナリが含まれています

その bp の形式は次のとおりです。

cc_library {
    name: "libThatIsVndkSp",
    vendor_available: true,
    vndk: {
        enabled: true,
        support_system_process: true,
    }
    ...
}

support_system_process 属性を構成する必要があります

2.6 llndkライブラリ：

Google によって管理され、システムイメージとベンダーイメージの両方で使用されるライブラリは二重ロードされる可能性があります。そのバイナリはシステムにミラーリングされます

その bp の形式は次のとおりです。

llndk_ライブラリ {

名前: "libThatIsLlndk",

}

単純なライブラリ分割と依存関係

VNDK を有効にした後のコンパイルの依存関係

3. VSDKの基本概念

VSDK には実際には VNDK 部分が含まれており、ベンダースナップショットも含まれています。

ベンダースナップショットの範囲は、システムソースコードによって維持されるベンダーのコンパイルまたは統合に使用されるネイティブモジュールの集合であり、主に次の種類の製品で構成されます

ベンダー: true またはvendor_available: true 動的/静的ライブラリまたはヘッダーファイルライブラリ
vendor_available: 真の静的 VNDK ライブラリ
ベンダー: true またはvendor_available: true 実行可能ファイルまたはオブジェクトファイル

Vendor_snapshot と vndk にどのモジュールがパッケージ化されているかについては、まず、モジュールベンダーバリアントの区分に関する以下の表を参照してください。

vndk: true モジュールはすべて VNDK にインストールされます。vendor_available: true を持つ vndk モジュールのみがベンダーモジュールで直接使用できます。private のない vndk は VNDK 独自のモジュールでのみ使用でき、間接的にベンダーモジュールで使用できます。

一般に: VSDK には、VNDK + ベンダースナップショット + リカバリスナップショット + ホストスナップショットが含まれます。

電車による情報: Linux カーネルソースコード技術学習ルート + ビデオチュートリアルカーネルソースコード

電車で学ぶ: Linux カーネルソースコードメモリチューニングファイルシステムプロセス管理デバイスドライバー/ネットワークプロトコルスタック

4. スナップショットの設計

上記 2 章では、それぞれ VNDK/VSDK の基本概念、コンテンツ分割、構築支援について説明します。元の質問に戻りますが、異なるバージョンのシステムやベンダーで異なるタイミングでコンパイルする問題に対処する場合、VNDK/VSDK のエンジニアリングプロセスはどのようなものですか? スナップショットソリューションは、ベンダーが必要とするコンテンツをシステム側から事前にビルドし、その部分をベンダービルドのソースコードの代わりに使用します。具体的な内容や実装については、順次紹介していきます。

4.1 スナップショットの概要

VNDK/VSDK のスナップショット (スナップショット) とは、現在のシステム側から一定のルールに従って生成された、事前に構築されたライブラリのセットを指し、これらのライブラリは、ベンダー側での後のコンパイルに使用されます。

上図は、最初のプロジェクトとベンダー凍結プロジェクトの 2 つのケースにおけるシステムとベンダーの組み合わせを示しています Android のメジャーバージョンアップグレードではベンダーが修正されるため、ベンダーの対応する依存関係もバージョンが一致している必要があります。プロジェクトには 2 つの実装方法があります。

1. ベンダー側のマニフェストファイルには、framework/av、framework/base、framework/native などのシステムウェアハウスが含まれています。これらのリポジトリは、以前の Android バージョンのコードを使用します。

2. Google のスナップショット設計を使用すると、ベンダーイメージ v27 が依存する v27 バージョンの vndk/vsdk ライブラリが、システムイメージ v27 バージョンによって事前に構築および生成されます。これらのライブラリは、ベンダー側のコンパイルに独立して使用されます。ベンダー側は、システム側のソースコードの依存関係を取り除くことができます。

2 つの方法にはそれぞれ長所と短所があります: 1. この方法は単純かつ直接的ですが、ベンダーコードの量が多く、ベンダーのコンパイル時間が長くなります。 2. ベンダー側のコードが合理化され、コンパイル時間が短くなります。ただし、サポートのためにプロジェクトに実装するには、追加の事前構築システムのセットが必要です。

4.2 スナップショット生成プロセス

スナップショットの生成は、実際には VSDK バイナリとそのコンパイルおよび構成ロジックを生成し、最後にスナップショット製品を参照するプロセスであり、次の 3 つの段階に分けることができます。

1. フレーズの生成: 一定のルールに従って、ベンダーイメージのコンパイルが依存するプレビルドコンパイルモジュール製品 (プレビルドスナップショットと呼ばれる) を生成するプロセスが、システム側のソースコードから生成されます。

2. インストールフレーズ: 生成フェーズで生成されたビルド済みモジュールを、py スクリプトを通じて指定されたソースコードディレクトリにインストールし、対応する Android.bp ファイルを生成するプロセス。

3. フレーズの使用: BOARD_VNDK_VERSION を特定のバージョン番号 (31 など) に設定すると、コンパイルシステムがトリガーされ、事前に生成されたスナップショットを使用してコンパイルプロセスに参加します (これに応じて、関連モジュールのソースコードコンパイルロジックもブロックされました）。

4.3 VNDK スナップショットの生成プロセス

AOSP デバイスを例にとると、対応する VNDK スナップショットパッケージは android-vndk-arm64.zip で、その内容は次のとおりです。

android-vndk-arm64.zip
├── arch-arm64-armv8-a
│   └── shared
│       ├── vndk-core  -> *.so files, *.json files
│       └── vndk-sp    -> *.so files, *.json files
├── arch-arm-armv8-a   -> (same as arch-arm64-armv8-a)
├── configs            -> *.libraries.txt, module_paths.txt, module_names.txt
├── include            -> exported header files (*.h, *.hh, etc.)
└── NOTICE_FILES       -> license txt files

フレーズを生成:

vndk Snapshot の生成ロジックは、soong/cc/vndk.go ファイルに VndkSnapshotSingleton を定義することで実現されます。

func init() {
android.RegisterSingletonType("vndk-snapshot", VndkSnapshotSingleton)
}

func VndkSnapshotSingleton() android.Singleton {
return &vndkSnapshotSingleton{}
}

type vndkSnapshotSingleton struct {
vndkLibrariesFile   android.OutputPath
vndkSnapshotZipFile android.OptionalPath
}

ここで、vndkSnapshotZipFile は vndk-snapshot.zip ファイルのパスを定義します。vndkSnapshotSingleton の GenerateBuildActions メソッドで vndkSnapshot を生成します。

インストールフレーズ：

VNDK パッケージのインストールは /development/vndk/snapshot/update.py を通じて行われ、そのプロセスは次のとおりです。

最終的に生成された bp ファイル内

vndk_prebuilt_shared {
    name: "android.hardware.wifi.hostapd-V1-ndk",
    version: "33",
    target_arch: "arm64",
    vendor_available: true,
    vndk: {
        enabled: true,
    },
    arch: {
        arm: {
            export_include_dirs: [
                "include/frameworks/native/libs/binder/ndk/include_cpp",
...
            ],
            srcs: ["arch-arm-armv8-a/shared/vndk-core/android.hardware.wifi.hostapd-V1-ndk.so"],
        },
        arm64: {
            export_include_dirs: [
                "include/frameworks/native/libs/binder/ndk/include_cpp",
...
            ],
            srcs: ["arch-arm64-armv8-a/shared/vndk-core/android.hardware.wifi.hostapd-V1-ndk.so"],
        },
    },
}

使用フレーズ：

device.mk 内の BOARD_VNDK_VERSION 変数を特定のバージョン値に設定し、ベンダー側をコンパイルします。

4.4 VSDK スナップショットの生成プロセス

AOSP デバイスを例にとると、vsdkSnapshot パッケージの内容は次のとおりです。

vendor-$(TARGET_DEVICE).zip
├── arch-arm64-armv8-a
│   ├── binary         -> binary files, *.json files
│   ├── header         -> *.json files
│   ├── object         -> *.o files, *.json files
│   ├── shared         -> *.so files, *.json files
│   └── static         -> *.a files, *.json files
├── arch-arm-armv8-a   -> (arch-arm64-armv8-a)
├── configs            -> *.rc files, *.xml files
├── include            -> exported header files (*.h, *.hh, etc.)
└── NOTICE_FILES       -> license txt files

フレーズの生成：

vsdkSnapshot の生成ロジックは、vendor_snapshot.go の GenerateBuildActions にあります。

インストールフレーズ：

vsdkSnapshot のインストールでは、/development/vendor_snapshot/update.py ファイルを使用します。

使用フレーズ：

device.mk 内の BOARD_VNDK_VERSION 変数を特定のバージョン値に設定し、ベンダー側をコンパイルします。

5. まとめ

VNDK/VSDK スナップショットは、システム/ベンダーコンポーネント間のソースコードの依存関係とコンパイルの依存関係をさらに削減し、トレブルベースラインの形成を容易にします。

メリットは次の3点に集約されます。

ベンダーコンポーネントのコンパイル効率の向上
コード認識管理の改善。ウェアハウスを分離した後、ベンダーコンポーネント内のカップリングウェアハウスを削除し、システムコンポーネント内のソースコードのみを保持できるようになりました。
システム/ベンダーコンポーネントの独立した開発のサポートにさらに役立ちます