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
Change-Id: Ib9ccae38430340de38e4758b4f55df2c65ea60d5
The build system default was changed to not support apex, but
we want the mainline device to enable it.
Test: make mainline_system
Merged-In: I9f29e8354acffb1856dfd8a173b80a3f9324630c
Change-Id: I9f29e8354acffb1856dfd8a173b80a3f9324630c
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This change includes the platform build system and release tools changes to
move the recovery resources from system to vendor (or /system/vendor). The
release tools need to know where to generate the recovery patch, and they
discover this from misc_info.txt variable board_uses_vendorimage, which the
platform build system generates.
We remove applypatch from PRODUCT_PACKAGES, but it is added back as a required
module in target/product/base_vendor.mk.
Several release tools rely on the misc_info.txt board_uses_vendorimage variable
to know how to generate and detect the recovery patch.
This change partially removes the --rebuild_recovery flag from the
merge_target_files.py script. The flag will be fully removed in a follow-on
change.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: Ia4045bd67ffb3d899efa8d20dab4c4299b87ee5f
Host builds using libc++ used -nodefaultlibs to turn off the default
C++ runtime, and then added back all the other necessary libraries.
Clang supports -nostdlib++ since https://reviews.llvm.org/D47115
that removes the C++ runtime without affecting the other default
libraries. Use -nostdlib++, and remove the lists of default
libraries.
Test: m checkbuild
Change-Id: Ib8b761534f64fd7f881e14598e514783678e0b35
zsh doesn't split variables (by default), but it will split command
output. bash will split both. Apparently a portable way to do this in
both is to just turn it into another command: "$(echo $var)".
Test: source build/envsetup.sh; lunch (see list; repeat in bash and zsh)
Change-Id: I9716a8d77aefdf05da8923deb9e37e0b6132b549
Arrays are zero indexed in bash and one indexed in zsh by default. This
leads to an off-by-one issue in the `godir` and `choosevariant` commands: when
prompted to chose an option, in order to pick option "n" you have to input
"n+1".
In those two specific instances, by using "substring expansion" instead of
array indexing, one can get consistent behaviour between bash and zsh
(equivalent to zero indexing).
Test: manual -
# godir
$ zsh
$ source build/envsetup.sh
$ godir SurfaceFlinger # There should be many options
# Pick 1, check that you end up in the right location
$ godir SurfaceFlinger.cpp # There should be only one possibility
# make sure you end up in the right location
# repeat with bash (to ensure compatibility is not broken)
# choosevariant
$ zsh
$ source build/envsetup.h
$ choosevariant # pick whatever variant you want
$ printconfig # make sure the variant matches your choice
# repeat with bash (to ensure compatibility is not broken)
Change-Id: I998d8fb48b708066b6db28a2129a2b09785fb0b1
Turn on RRO enforcement for /system modules for products
that use mainline_system.mk
Bug: b/137727426
Test: compare_images
Change-Id: Ia1824481c85fb031d5e156307bf7a848e4721d9e
They are designed to be used as a pair -- we should create separate
flags when there's a need.
Fixes: 130433003
Test: TreeHugger
Test: Define only one of them. `m dist` fails.
Change-Id: Ied57bd67fbed59b160c407dbb4c0d624581c58f7
- libstagefright_enc_common
- libstagefright_amrnb_common
Bug: 141885505
Test: build and boot.
Checked libstagefright_enc_common.so doesn't exist in /system/lib64.
libstagefright_amrnb_common.so is still there because other system
module, librtp_jni.so, is using it, but there is no reason to keep
this in base_system.mk.
Change-Id: I43692b50bd23e0b857606b42cb000c8566489dd6
Change RRO logic from
"Enforce RRO for all modules when PRODUCT_ENFORCE_RRO_TARGETS is '*'"
to
"Enforce RRO for all modules when PRODUCT_ENFORCE_RRO_TARGETS includes '*'"
Bug: b/137727426
Test: test build on local machine
Change-Id: I10b215c28919988ec58deb1fe3d5498ad4e73eb4
Ensure only /system partition modules defined in mainline_system.mk is
included.
Test: lunch mainline_system_arm64-userdebug; m
Change-Id: I0cf9e28dd95fdc0f8f1eb88aefa07e230223b996
Required in order to run test self test for the vendor copy of
libcrypto.so which may differ from the one in /system and so will use
differently name flag files in order to avoid running the BoringSSL
Known Answer Tests on every process startup, impacting system health.
Bug: 141150335
Test: TH
Change-Id: I1db922379a59fa66fc65b6d92d370f33a2c65799
Merged-In: I1db922379a59fa66fc65b6d92d370f33a2c65799
(cherry picked from commit e3ab8eab25)
Modifications made to make/core to handle new C Flags build variables which
store which module uses which flag.
C Flags build variables generated by Soong.
Bug: 140442588
Test: Executed m dist and presubmit
Change-Id: I4c730b9dba27672c6a9f75cf35beaf6311174af0
System Ext partition is not mounted in recovery mode. Install
system_ext_file_contexts and system_ext_property_contexts into
rootdir for recovery. This is similar to how we deal with system,
product, vendor, odm *_contexts files.
Bug: 137712473
Test: m bootimage for pixel 2, system_ext_file_contexts and
system-ext_property_contexts appear in $OUT/recovery/root/
Change-Id: I94b965d775e727fbbe26c8b715bbce3ca6179fa7
Allows us to use dist-for-goals and produce the fuzz target packages as
part of a normal dist.
Bug: 141026328
Test: m dist fuzz
Change-Id: Idffa879eb11266bfce18e0f9164e7ef80769cbc2
The vendor_boot partition is generated by mkbootimg and contains all the
device-specific information that used to reside in the boot partition.
Bug: 137297791
Change-Id: I5b005097b73f59857c3a2f92d693b3e67ee8424e
Some device requires VNDK_USING_CORE_VARIANT list, but it was not
implemented in previous. Adding this library list to the build target so
it can be added to system image.
Bug: 141695559
Test: m -j passed & Tested from Cuttlefish
Change-Id: Ic6847fd1966d4e1884cdce97015c8c1d1e0f3422
... so that it can be used during OTA package generation.
Bug: 141720569
Test: apply virtual A/B OTA
Change-Id: I3a1df1afb7676eed6d22be49270354119bfb5a75
* The following were high severity warnings but mistakenly
grouped into analyzer warnings in a recent change.
clang-analyzer-unix.Malloc
clang-analyzer-cplusplus.NewDeleteLeaks
clang-analyzer-cplusplus.NewDelete
* Add new Protoc and Kotlin warnings about unused imports and variables.
Bug: 141493530
Test: warn.py --url=http://cs/android --separator='?l=' build.log > warnings.html
Change-Id: Ied1f9ace97f29fba58a40dff2346a0391ab22f06
* Some comments are kept to reduce diff artifacts.
* Warning patterns will be separated by tools later,
to make it easier to share code with Chromium and
other build tools.
Bug: 141493530
Test: warn.py --url=http://cs/android --separator='?l=' build.log > warnings.html
Change-Id: I6b589478cf5ae73940b4712d9faabd0909546f02