Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
diff --git a/core/config.mk b/core/config.mk
index ab9f4c3..b4fb298 100644
--- a/core/config.mk
+++ b/core/config.mk
@@ -1063,11 +1063,11 @@
# AOSP target built without vendor image), don't build the retrofit full OTA package. Because we
# won't be able to build meaningful super_* images for retrofitting purpose.
ifneq (,$(filter vendor,$(BOARD_SUPER_PARTITION_PARTITION_LIST)))
-ifndef BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE
+ifndef BUILDING_VENDOR_IMAGE
ifndef BOARD_PREBUILT_VENDORIMAGE
BOARD_BUILD_RETROFIT_DYNAMIC_PARTITIONS_OTA_PACKAGE :=
endif # BOARD_PREBUILT_VENDORIMAGE
-endif # BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE
+endif # BUILDING_VENDOR_IMAGE
endif # BOARD_SUPER_PARTITION_PARTITION_LIST
else # PRODUCT_RETROFIT_DYNAMIC_PARTITIONS