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_ライブラリ {
名前: "libThatIsCore",
...
}
Vendor、vendor_available、vndk、および vndk-sp 属性は含まれません
2.2 ベンダー専用（独自）ライブラリ：
ベンダー使用のみ。バイナリの場所はベンダー ミラー内にあります。
その bp の形式は次のとおりです。
cc_ライブラリ {
名前: "libThatIsVendorOnly",
独自の: true、
# または: ベンダー: true、# (AOSP の場合)
...
}
vndk プロパティは含まれません
2.3 Vendor_available ライブラリ:
ベンダー イメージで使用されるライブラリには、ベンダー バリアントとコア バリアントの両方があり、ベンダー イメージとシステム イメージにパッケージ化されています。その bp の形式は次のとおりです。
cc_ライブラリ {
名前: "libThatIsVendorAvailable",
ベンダー利用可能: true、
...
}
vndk プロパティは含まれません
2.4 vndk ライブラリ：
ベンダーモジュールによって使用されますが、バイナリはシステムにミラーリングされます
その bp の形式は次のとおりです。
cc_ライブラリ {
名前: "libThatIsVndk",
ベンダー利用可能: true、
vndk: {
有効: true、
}
...
}
Vendor_available プロパティと vnd.enable プロパティの両方が存在します
2.5 vndk-sp ライブラリ:
ベンダーによって直接使用され、システム イメージによって間接的に使用されるライブラリには、システム イメージ内にそのバイナリが含まれています
その bp の形式は次のとおりです。
cc_ライブラリ {
名前: "libThatIsVndkSp",
ベンダー利用可能: true、
vndk: {
有効: 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 + ベンダー スナップショット + リカバリ スナップショット + ホスト スナップショットが含まれます。
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 で、その内容は次のとおりです。
アンドロイド-vndk-arm64.zip
§── アーチアーム64-armv8-a
│ └── 共有
│ §── vndk-core -> *.so ファイル、*.json ファイル
│ └── vndk-sp -> *.so ファイル、*.json ファイル
§── Arch-arm-armv8-a -> (arch-arm64-armv8-a と同じ)
§── configs -> *.libraries.txt、module_paths.txt、module_names.txt
§── インクルード -> エクスポートされたヘッダー ファイル (*.h、*.hh など)
└── NOTICE_FILES -> ライセンス txt ファイル
フレーズを生成:
vndk Snapshot の生成ロジックは、soong/cc/vndk.go ファイルに VndkSnapshotSingleton を定義することで実現されます。
関数 init() {
android.RegisterSingletonType("vndk-スナップショット", VndkSnapshotSingleton)
}
func VndkSnapshotSingleton() android.Singleton {
&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 {
名前: "android.hardware.wifi.hostapd-V1-ndk",
バージョン: "33"、
target_arch: "arm64",
ベンダー利用可能: true、
vndk: {
有効: true、
}、
アーチ： {
腕： {
エクスポート_インクルード_ディレクトリ: [
"include/frameworks/native/libs/binder/ndk/include_cpp",
...
]、
srcs: ["arch-arm-armv8-a/shared/vndk-core/android.hardware.wifi.hostapd-V1-ndk.so"],
}、
アーム64: {
エクスポート_インクルード_ディレクトリ: [
"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 パッケージの内容は次のとおりです。
ベンダー$(TARGET_DEVICE).zip
§── アーチアーム64-armv8-a
│ §── バイナリ -> バイナリ ファイル、*.json ファイル
│ §── ヘッダー -> *.json ファイル
│ §── オブジェクト -> *.o ファイル、*.json ファイル
│ §── 共有 -> *.so ファイル、*.json ファイル
│ └─ 静的 -> *.a ファイル、*.json ファイル
§── アーチアーム-armv8-a -> (アーチアーム64-armv8-a)
§── 設定 -> *.rc ファイル、*.xml ファイル
§── インクルード -> エクスポートされたヘッダー ファイル (*.h、*.hh など)
└── NOTICE_FILES -> ライセンス txt ファイル
フレーズの生成：
vsdkSnapshot の生成ロジックは、vendor_snapshot.go の GenerateBuildActions にあります。
インストールフレーズ：
vsdkSnapshot のインストールでは、/development/vendor_snapshot/update.py ファイルを使用します。
使用フレーズ：
device.mk 内の BOARD_VNDK_VERSION 変数を特定のバージョン値に設定し、ベンダー側をコンパイルします。
5. まとめ
VNDK/VSDK スナップショットは、システム/ベンダー コンポーネント間のソース コードの依存関係とコンパイルの依存関係をさらに削減し、トレブル ベースラインの形成を容易にします。
メリットは次の3点に集約されます。
ベンダーコンポーネントのコンパイル効率の向上
コード認識管理の改善。ウェアハウスを分離した後、ベンダー コンポーネント内のカップリング ウェアハウスを削除し、システム コンポーネント内のソース コードのみを保持できるようになりました。
システム/ベンダーコンポーネントの独立した開発のサポートにさらに役立ちます
参考文献
[1]https://source.android.com/devices/architecture/vndk/snapshot-vendor
[2]https://source.android.com/devices/architecture/vndk/snapshot-generate
[3] ブートキャンプ 2021 VSDK.pdf
[4]https://source.android.com/devices/architecture/vndk/enabling
[5]https://source.android.com/docs/core/architecture/vndk/build-system
[6]https://source.android.com/docs/core/architecture/vndk/snapshot-design
[7] VNDK/VSDK スナップショット コンパイル フレームワークの詳細な分析
過去
予想
押す
お勧め
2023 年の Arm の最新プロセッサ アーキテクチャの分析 - X4、A720、A520
Chromium マルチプロセス アーキテクチャ、どれくらい知っていますか?
良い名前の重要性について: Linux カーネル ページから Folio への変更
長押ししてカーネル職人WeChatをフォローしてください
Linux カーネル ブラック テクノロジー | 技術記事 | 注目のチュートリアル