| commit | 48a2feb6708767871fd1a44db638703e7c77b3c1 | [log] [tgz] |
|---|---|---|
| author | Tao Bao <tbao@google.com> | Fri Jun 28 11:00:05 2019 -0700 |
| committer | Tao Bao <tbao@google.com> | Fri Jun 28 14:23:53 2019 -0700 |
| tree | d90807507157b1df42e39dd9a342205a99cfba6d | |
| parent | 63cf1326dafb562ea36dafe91630e9882c2da18e [diff] |
Change the condition for building super_empty.img. This CL changes the condition for building super_empty.img from PRODUCT_BUILD_SUPER_PARTITION to PRODUCT_USE_DYNAMIC_PARTITIONS, as a follow-up to the change in [1]. With the CL in [1], it skips building super.img and super_empty.img both when turning off PRODUCT_BUILD_SUPER_PARTITION. However, the latter should be mandatory whenever dynamic partitions is enabled. Because fastboot relies on this file to properly flash dynamic partitions. Plus, the cost for building super_empty.img is much lower than the one for super.img. As part of the change, it'll write group info into target_files when building with PRODUCT_BUILD_SUPER_PARTITION == false. It's the work for target_files merging script to determine the values to be picked up. The current logic in merge_target_files.py always uses the one from vendor target_files. This CL adds a testcase to ensure the behavior. [1] https://android-review.googlesource.com/c/platform/build/+/928756 Bug: 135752763 Test: `m dist` with a target that sets PRODUCT_BUILD_SUPER_PARTITION to false. Check the built artifacts contain super_empty.img. Verify that the build can be flashed properly. Change-Id: I277f087eab45663a6c3b33333d16e9e576c1c25c
This is the Makefile-based portion of the Android Build System.
For documentation on how to run a build, see Usage.txt
For a list of behavioral changes useful for Android.mk writers see Changes.md
For an outdated reference on Android.mk files, see build-system.html. Our Android.mk files look similar, but are entirely different from the Android.mk files used by the NDK build system. When searching for documentation elsewhere, ensure that it is for the platform build system -- most are not.
This Makefile-based system is in the process of being replaced with Soong, a new build system written in Go. During the transition, all of these makefiles are read by Kati, and generate a ninja file instead of being executed directly. That's combined with a ninja file read by Soong so that the build graph of the two systems can be combined and run as one.