Android R (Qualcomm platform) compilation related records

Preface

This article is a debugging record, based on two major directions to summarize the content of this article:

1. The ninja compilation command improves debugging efficiency

2. Qualcomm's source code introduced QSSI (Qualcomm Single System Image) on R. Literally, it means to decouple the system independently and pave the way for manufacturers to upgrade to the latest android version.

 

detailed description

For compilation

No analysis of ninja compilation has been done, so that the friends involved in the module can have a way to improve debugging efficiency. Those who debug the android R version know the pain of compilation and debugging.

./prebuilts/build-tools/linux-x86/bin/ninja -f out/combined-bengal.ninja -j32 aboot

For example, the aboot module is debugged above. After the full compilation, you can use the above command to compile later, of course, it can also be bootimage vendorimage and so on.

Another thing to note is that after android Q, Google has enabled dynamic partitioning. The size of partitions such as system, vendor, and product is dynamically variable, and the partition in the partition table is super.

We do not focus on dynamic partitioning here, but the version with dynamic partitioning is enabled. If you need to debug and verify the problem, such as making changes in the vendor, you need to repackage the super image after compiling.

After reading the command to repackage super, add (Todo).

Supplement: Taking a look at the usage in the build.sh script, Qualcomm has done several iterations

vendor\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 variant

version0,version1 ------Basically supports full compilation

version2 ------Dynamic partition Image copy customization

version3 ------Support modular compilation, such as:

./build.sh --qssi_only only compile qssi

./build.sh --target_only only compile oem target product

./build.sh --merge_only merge the above two parts of the mirror content, the situation of merging the super image mentioned earlier, as well as the final merge ota and merge target-file including the packaging can be completed with this command.

version4 ------ Only lunch qssi can independently compile qssi only image

The commands have not been verified one by one at the moment, and the debugging phase is time-critical, mainly because of what I tried and the summary of hearsay

编译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's approach

According to my current rough understanding, the compilation of systemimage is independent of other modules.

So the execution of the compiled script is the same. The TARGET_PRODUCT in the first stage is qssi.

source build/envsetup.sh
lunch qssi-userdebug

Wait for the compilation to complete, execute the second stage of the compilation of other images, TARGET_PRODUCT is the oem project.

The overall compilation time is at least 4 hours, so any debugging that requires full compilation will have to toss around, but who told us to eat this bowl of rice, face it optimistically, after all, this is life The essence of.

Guess you like

Origin blog.csdn.net/jeephao/article/details/111823543