When `OVERRIDE_TARGET_FLATTEN_APEX` is defined (e.g. set in the
environment), `TARGET_FLATTEN_APEX` is forcibly assigned its value.
This is useful to enable/disable APEX flattening from the command
line (thus ignoring the product's default configuration), for testing
purposes.
Note: Previously it was possible to set `TARGET_FLATTEN_APEX` directly
and have the same effect, but recent changes in the build
configuration now prevent that option.
Test: Check that:
export OVERRIDE_TARGET_FLATTEN_APEX=true \
&& . ./build/envsetup.sh \
&& lunch aosp_walleye-userdebug \
&& export OVERRIDE_TARGET_FLATTEN_APEX=true \
&& build/soong/soong_ui.bash --dumpvar-mode TARGET_FLATTEN_APEX
returns:
true
Bug: 121117762
Merged-In: Ib9ccae38430340de38e4758b4f55df2c65ea60d5
Change-Id: Ib9ccae38430340de38e4758b4f55df2c65ea60d5
(cherry picked from commit b3a503df7f)
product_services partition is designed for the test purpose only. It
must not be included in the target devices.
Bug: 134359158
Test: Build configuration for product_services partition must return
error message.
Change-Id: I6f8cdf73d18ad3174c7b31edb5d5ee10df75a776
The current solution expects BOARD_PREBUILT_DTBIMAGE_DIR to
contain prebuilt DTB files that are concatenated by the build system
to create $OUT/dtb.img. In order to accommodate devices that build
the dtb image locally, when BOARD_PREBUILT_DTBIMAGE_DIR is undefined,
make boot.img creation depend only on $OUT/dtb.img.
Bug: 133161451
Test: Build with BOARD_PREBUILT_DTBIMAGE_DIR undefined and verify
using unpack_bootimg.py that $OUT/dtb.img was included in boot.img.
Change-Id: Iae2c634ccdc1d83589b26d382882f75fb8565a31
Merged-In: Iae2c634ccdc1d83589b26d382882f75fb8565a31
TARGET_FLATTEN_APEX and ro.apex.updatable cannot be independently set.
For a device where updating APEXes is not supported, ro.apex.updatable
should not be set (or set to false) and TARGET_FLATTEN_APEX should be
set to true. For APEX-supporting devices, it is the opposite;
ro.apex.updatable == true and TARGET_FLATTEN_APEX is false (or not set).
To ensure this relationship, TARGET_FLATTEN_APEX is by default set to
true, and overridden to false when updatable_apex.mk is inherited.
Bug: 130623080
Test: choosecombo to Pixels 2 and later; get_build_var
TARGET_FLATTEN_APEX returns false.
choosecombo to the original Pixel and other non-Pixel targets;
get_build_var TARGET_FLATTEN_APEX returns true.
choosecombo to the cuttlefish; get_build_var TARGET_FLATTEN_APEX
returns false
Change-Id: Id73a594dd9838457e68e2793122592c11a84fc83
The two new debugging images adds additional files based on
boot.img and ramdisk.img/ramdisk-recovery.img, respectively.
File /force_debuggable is to trigger special logic in /init to load an
userdebug version of sepolicy and an additional property file from this
ramdisk to allow adb root, if the device is unlocked.
It's intentional to skip signing for boot-debug.img, as it can
only be used if the device is unlocked, where verification error
is allowed.
Those debugging images allows adb root on user build
system.img, vendor.img, product.img, etc. This can facilitate more
automated testings on user builds and is helpful to narrow down the
delta between what's being tested v.s. what's being shipped.
Bug: 126493225
Test: `make dist`, checks both boot-debug.img and ramdisk-debug.img
are in $OUT/ and out/dist.
Test: `make dist`, checks installed-files-ramdisk-debug.{json,txt} are
in out/dist.
Test: `system/core/mkbootimg/unpack_bootimg.py --boot_img $OUT/boot-debug.img`,
checks the extracted out/ramdisk is as expected
Test: Run `gunzip -c ramdisk | cpio -idm` for the ramdisk extracted from
$OUT/boot-debug.img and $OUT/boot.img, respectively.
Then compare the root dirs of both, e.g.,
`diff -rq --no-dereference ./ramdisk ./ramdisk-debug`
Test: `make ramdisk_debug-nodeps` and `make bootimage_debug-nodeps`
Change-Id: I30137c3caef91805d9143d404e5e4d06c0fccc30
Merged-In: I30137c3caef91805d9143d404e5e4d06c0fccc30
(cherry picked from commit 0013f55ef4)
Some people apparently still talk to the network during their build.
Allow this temporarily with a BUILD_BROKEN_USES_NETWORK check.
Bug: 129992021
Test: attempt to talk to the network during the build with and without
this flag
Change-Id: I45612ad6165f92f123847b4057338c0dfc3424ee
Merged-In: I45612ad6165f92f123847b4057338c0dfc3424ee
(cherry picked from commit 0586c65780)
This moves the BoardConfig READONLY marking being product.mk's
responsibility to board_config.mk.
Also unify it with the BUILD_BROKEN_* setting handling, and
READONLY a few additional variables.
Test: build_test
Change-Id: Ifcfef588aa459223d6d7f017413d1681f341297f
These files may be setting variables usually defined in the
BoardConfig. This moves that setting into board_config.mk so
that the relevant variables can be made readonly.
Test: build_test
Test: diff presubmit target_files vs base cl
Change-Id: I4dab09fa67c0f2e88a8ce1402a35b4ef5f8a0560
This allows setting the variable READONLY after reading the BoardConfig.
This is safe to do because this flag is only set in BoardConfig.mk
files. The same is not true for many of the other default preopt flags,
like DEX_PREOPT_DEFAULT or WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY
which are set in mixture of product / board config files.
Test: boot blueline
Change-Id: I961ba581f9790bcdc7cf6b36d8b53bcdb8861a92
The current modification of the variable within the build system
prohibits making the variable readonly.
Test: build_test
Test: boot blueline
Change-Id: Iec6058a163b5951db389d4adc0d9d0397431efb1
Move a few more variable stripping/sanity checking from
config.mk to board_config.mk
Test: build_test
Change-Id: I93fde7293de38398039dbb679b2399c8a68c190d
Similar to product_config.mk, this contains the logic for reading
BoardConfig.mk, and will be expanded to sanity-check variables
set in the BoardConfig etc.
Test: build_test
Change-Id: I4f8d7cfbf1506ae4268c82c9554680259958b313
