This reverts commit efe6a4d748.
As a result of b/191269918, APEX variants are now consistently
identified by their "runtime names", i.e. their mount names under
/apex. Those names are now also used to identify the APEXes in
PRODUCT_BOOT_JARS and similar variables. That avoids implementing a
global lookup mechanism in Soong, and since they don't vary between
products also makes this override variable unnecessary.
Test: `m nothing` in internal
Bug: 191269918
Bug: 180325915
Change-Id: I6fd3d29d1c032c9f8bda0191781f9d2dc6f199a4
If the jar file passed to add-jar-resources-to-package is passed a
non-zipfile, then we should produce an error.
Bug: 153900481
Test: manual
Change-Id: Idc4dd9afd89eaee08a9e792dfa2a759e64b783fc
Correct the build-image-kernel-modules arguments then
the board can use BOARD_{CUSTOM_IMAGE}_KERNEL_MODULES
to install kernel modules.
Bug: 195888474
Change-Id: I65124acc470e7f6f701bf3c9f5481bb2d688d555
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
If RBC_PRODUCT_CONFIG variable is set, obtain product configuration
variables by converting product configuration makefiles to Starlark
files and then executing them.
Also, introduce RBC_NO_PRODUCT_GRAPH variable to suppress product graph
generation. We cannot generate product graph with Starlark, so this
option allows to verify that the rest of the contents of the generated
Ninja files remains the same when Starlark-based converter is used.
This allows to perform the regression testing, i.e. running
`RBC_NO_PRODUCT_GRAPH=t DISABLE_ARTIFACT_PATH_REQUIREMENTS=t m nothing`
and
`RBC_PRODUCT_CONFIG=t m nothing`
should generate identical *.ninja files.
Bug: 181797530
Test: Manual
Change-Id: Ic6173a9640f32766b71c02a2b1833ce7a278e4cc
Prebuilt modules do not provide sanitizer binaries to using them in this
context is unsafe.
Bug: 194067130
Test: TH
Merged-In: I3682ae9ad963a8cd13bb395fe84dae515dc6d30f
Change-Id: I3682ae9ad963a8cd13bb395fe84dae515dc6d30f
_prop_files is missing a trailing _
Bug: 195034733
Test: manual - check that expected prop files are in the image
Change-Id: Ie042acc74fa56d5515cacd5f41ddc0f82d74f20c
boot-test-harness.img is used to allow adb root on user build
images. It also sets properties: ro.audio.silent=1 & ro.test_harness=1.
GKI 2.0 devices will use BOARD_PREBUILT_BOOTIMAGE so
boot-test-harness.img will not be generated.
Therefore, we have to introduce the vendor_boot-test-harness.img
as an alternative for boot-test-harness.img.
In the future, we'll simplify the flow as:
+ If a device has a /vendor_boot partition, builds
vendor_boot-(test-harness|debug).img.
+ Otherwise, builds boot-(test-harness|debug).img.
boot-(test-harness|debug).img needs to be kept for some clients
to gracefully transit to using vendor_boot-(test-harness|debug).img.
Bug: 194654549
Test: make then `unpack_bootimg --boot_img $OUT/vendor_boot-test-harness.img`
Test: Check the ramdisk content in ./out/vendor_ramdisk
Change-Id: If3a1393b4ff3e69bb9b62f3b843b7858437d47bf
When rule action contains something like
cp $(FOO) ...
and FOO is set with
FOO := a \
b \
the generated Ninja file constains extra spaces, making it
difficult to compare it to the same file generated by the
Starlark-based product configuration.
Bug: 181797530
Test: manual
Change-Id: I278bd8edf0f017a31c5b5115b2a38f4f663c55fc
Regardless of an "updatable" property, list all apex jars in the same
variable. This is less confusing for devs and matches the pattern with
PRODUCT_APEX_BOOT_JARS.
Bug: 191127295
Test: atest CtsClasspathsTestCases
Change-Id: I3b12f26237636f4271cb000480928b3ce1c2e62f
Merged-In: I3b12f26237636f4271cb000480928b3ce1c2e62f
Using prebuilts of the ART Module seems to make
`COMPATIBILITY.art-host-tests.HOST_SHARED_LIBRARY.FILES` empty on
x86 targets, thus breaking the `art-host-tests` build target. As
a workaround, relax the corresponding build rule to allow for an
empty `COMPATIBILITY.art-host-tests.HOST_SHARED_LIBRARY.FILES`
list.
Test: lunch cf_x86_phone-userdebug
&& SOONG_CONFIG_art_module_source_build=false m art-host-tests
Bug: 194627489
Change-Id: I9e885be3c7161f6f09a93b3d32339a5a6e57d2a1
PLATFORM_VERSION_CODENAME is being updated from T to Tiramisu.
Bug: 186121492
Bug: 194055070
Test: m checkbuild
Merged-In: I39a82c8ac3fd0b43bad06ec47b85aaeda6ef5cb4
Change-Id: I39a82c8ac3fd0b43bad06ec47b85aaeda6ef5cb4
(cherry picked from commit a45d0c890e)
When using the VSDK, dexopt is not applied during the vendor build.
To avoid a first-boot time regression, dexopt is applied during the
merge stage, by running dexopt on the vendor apps and rebuilding
the vendor image.
Bug: 188179859
Test: Tested in keystone with VSDK target
Change-Id: Ie8e2d0a82850a2901fa6f250433bcbb43f0a97f2
Note that ART apex boot jars and core-icu4j are exceptions here as they
are not part of ApexBootJars. ART apex boot jars are defined in their
own variable, while core-icu4j is treated as a regular non-updatable
boot jar.
Bug: 191127295
Test: atest CtsClasspathsTestCases
Change-Id: I5f5feb7344941d0154f384e3c06279d49b490768
Regardless of an "updatable" property of individual, list all apex boot
jars in the same variable. This is less confusing for devs, especially
since they shouldn't care about things like boot images.
Bug: 191127295
Test: atest CtsClasspathsTestCases
Change-Id: I0a559db462d1e1f67003ac54d1e27a89110d802a
Merged-In: I0a559db462d1e1f67003ac54d1e27a89110d802a
Change Id397ad097539 alone would break hikey build, which
is a non-A/B device with a boot image, but without recovery.
Do not build OTA in this case.
Test: lunch hikey && m dist
Fixes: 194018054
Bug: 193588301
Change-Id: I8d09ad5c62d44699eb910ff62d32044bd97e8e44
This reverts commit bf77787cc9.
Reason for revert: relanding change
Test: see next CL
Bug: 193925883
Bug: 193588301
Change-Id: Id397ad0975390617bd277573f2cdba9a2677842d
... but not really: move it back to PRODUCT_BOOT_JARS before the list is
passed to soong. This ensures that core-icu4j remains on the boot image
for system health reasons and maintains the status quo.
core-icu4j is the only APEX jar (aside from ART jars) that is ever meant
to be part of the boot image. This is an implementation detail that most
devs don't and shouldn't care about. Instead, most devs assume that
PRODUCT_UPDATABLE_BOOT_JARS is where all apex jars are meant to go. In
the follow ups, PRODUCT_UPDATABLE_BOOT_JARS would be renamed to
PRODUCT_APEX_BOOT_JARS, regardless of the updatable property.
This also solves the problem where vendors add /system and /system_ext
boot jars to PRODUCT_BOOT_JARS outside of default_art_config.mk and
essentially violate the ordering requirement: all /apex jars come after
/system and /system_ext.
Bug: 191127295
Test: atest CtsClasspathsTestCases derive_classpath_test
Change-Id: Ifdfdd02519a0f5baea45619523f0c1eb8be186bc
On devices with a prebuilt boot image, TARGET_NO_KERNEL
may be set to enable signing, etc. In this case we still
want to build the OTA package.
Test: m otapackage on a device with generic boot image
(where TARGET_NO_KERNEL is set)
Bug: 193588301
Change-Id: I4e5adc3f42a516ac0e2f66c313dbe34a469ebe05
