序文
この記事は、この記事の内容を要約する2つの主要な方向性に基づいたデバッグ記録です。
1.ninjaコンパイルコマンドはデバッグ効率を向上させます
2. QualcommのソースコードはRにQSSI（Qualcomm Single System Image）を導入しました。文字通り、システムを独立して分離し、メーカーが最新のAndroidバージョンにアップグレードするための道を開くことを意味します。
詳細な説明
コンパイル用
忍者のコンパイルの分析は行われていないため、モジュールに関係する友人はデバッグの効率を向上させることができます。AndroidRバージョンをデバッグする人は、コンパイルとデバッグの苦痛を知っています。
./prebuilts/build-tools/linux-x86/bin/ninja -f out / Combined-bengal.ninja -j32 aboot
たとえば、abootモジュールは上記でデバッグされています。完全にコンパイルした後、上記のコマンドを使用して後でコンパイルできます。もちろん、bootimagevendorimageなどにすることもできます。
もう1つの注意点は、android Qの後、Googleが動的パーティション分割を有効にしたことです。システム、ベンダー、製品などのパーティションのサイズは動的に可変であり、パーティションテーブルのパーティションは非常に優れています。
ここでは動的パーティション化に焦点を当てていませんが、動的パーティション化を備えたバージョンが有効になっています。ベンダーに変更を加えるなど、問題をデバッグおよび検証する必要がある場合は、コンパイル後にスーパーイメージを再パッケージ化する必要があります。
スーパーを再パッケージ化するコマンドを読んだ後、（Todo）を追加します。
補足：build.shスクリプトの使用法を見てみると、Qualcommはいくつかの反復を行っています
ベンダー\ qcom \ opensource \ core-utils \ build \ build.sh
# Version 0:
# Supports just the basic make commands (passes on all args like -j32 to the make command).
# Version 1:
# Supports dist command as well - needed for target-files/ota generation.
# Usage: ./build.sh dist -j32
# This triggers make dist for qssi and target lunch, generates target-files, merges them
# and triggers ota generation.
# Version 2:
# Supports custom copy paths for dynamic patition images when compiled with dist.
# option : --dp_images_path=<custom-copy-path>
# Version 3:
# Supports segmenting the build into qssi only, target only and merge only steps and
# enabling users to call specific steps or full build by giving no separate steps.
# options: --qssi_only, --target_only, --merge_only
# Usage: ./build.sh dist -j32 --qssi_only (for only qssi build) or ./build.sh dist -j32 (for full build)
# Note: qssi_only and target_only options can be given together but merge_only should not be combined with
# any other options.
# Version 4:
# Supports lunch qssi variant to build qssi only images.
# enables users to build standalone qssi images independent of any targets
# option(s): --qssi_only
# Usage: ./build.sh dist -j32 --qssi_only or ./build.sh dist -j32. Either way the outcome will be the same
# Note: --target_only and --merge_only options will throw an error with lunch qssi variantversion0、version1 -------基本的に完全なコンパイルをサポートします
version2 ------動的パーティションイメージコピーのカスタマイズ
version3 -------次のようなモジュラーコンパイルをサポートします。
./build.sh --qssi_onlyqssiのみをコンパイルします
./build.sh --target_onlyは、OEMターゲット製品のみをコンパイルします
./build.sh --merge_onlyミラーコンテンツの上記の2つの部分をマージします。前述のスーパーイメージをマージする状況、およびパッケージングを含む最終的なマージotaとマージターゲットファイルは、このコマンドで完了できます。
version4 -------ランチqssiのみがqssiのみのイメージを独立してコンパイルできます
コマンドは現時点では1つずつ検証されておらず、主に私が試したことと伝聞の要約のために、デバッグフェーズはタイムクリティカルです。
编译system
build.sh dist qssi_only -j8
build.sh dist merge_only -j8
编译vendor.img
build.sh vendorimage dist target_only -j8
build.sh dist merge_only -j8
build.sh dist merge_only -j8会生成super.img
QSSIのアプローチ
私の現在の大まかな理解によれば、systemimageのコンパイルは他のモジュールから独立しています。
したがって、コンパイルされたスクリプトの実行は同じです。最初のステージのTARGET_PRODUCTはqssiです。
source build/envsetup.sh
lunch qssi-userdebugコンパイルが完了するのを待ち、他のイメージのコンパイルの第2段階を実行します。TARGET_PRODUCTはOEMプロジェクトです。
全体のコンパイル時間は少なくとも4時間なので、完全なコンパイルが必要なデバッグはすべてやり直す必要がありますが、このご飯を食べるように言った人は、楽観的に直面します。結局のところ、これが人生の本質です。