This is unused and doesn't work with our current API review process
anyway (un-drafting an API won't be flagged for API council review).
Test: treehugger
Bug: None
Change-Id: I6d8fcc9885b82dac5ada7772d9e3fb9101524ece
This patch adds a variable to indicate to check if the target has the
flag PRODUCT_SET_DEBUGFS_RESTRICTIONS enabled.
Bug: 184381659
Test: make with/without PRODUCT_SET_DEBUGFS_RESTRICTIONS set
Change-Id: Ic14a3759b155ed4e16048d62fcd990f4ba7c906a
cc_object crtbrand sets product_variable.platform_sdk_version.asflag
and will not compile correctly within mixed builds without it.
Only handles product_variables that expand product variables.
Bug: 181794963
Test: ~/aosp/build/bazel/scripts/milestone-2/demo.sh full
Change-Id: I293fcb18032aa51f63bb7b3de94abd6d1ec38180
Add header_libs to product_variables.arc struct, which is needed for
cc_library_headers.
Bug: 151048523
Test: Image builds.
Change-Id: I1e1af35fb2c3a55454c9b70acfa10abb5d65ef61
Use_lmkd_stats_log used to control LMKD_LOG_STATS when compiling lmkd.
However, for newer Android releases, we mandate that lmkd informs statsd of process kills (change id I8cb123b9488fbc6e88863c2f0e75f1422bcd282e)
After aosp/1555318 we compile lmkd with statsd by default, so this setting is a noop.
Change-Id: Ibcf661e205b3ed2a4a520a42952aaece503e9350
Test: build
Bug: 177985094
Calling reflect.ValueOf for every variable for every module was
using ~3 seconds of CPU time on my AOSP builds.
Test: m checkbuild
Change-Id: Idf459ad8ddf5e07f6c0df0e58e2442aaa6ab3342
By enabling these hiddenapi CSV files to be prebuilt, it
becomes possible to create a split build that supports
the hiddenapi encode dex step, but doesn't contain all
of the java sources needed to generate the CSV files.
Bug: 175048716
Test: m nothing
Test: new TestHiddenAPISingletonWithPrebuiltCsvFile
Test: local build without prebuilt hiddenapi
Test: local build with prebuilt hiddenapi
Change-Id: I805ea3ec05860d2df211a3985ec025bf36f0d775
Vendors can now generate only needed modules by setting the following
Makefile variables:
- DIRECTED_VENDOR_SNAPSHOT: set to true
- VENDOR_SNAPSHOT_MODULES: list of snapshot candidates
e.g.
DIRECTED_VENDOR_SNAPSHOT := true
VENDOR_SNAPSHOT_MODULES := toybox_vendor sh_vendor libbase libcutils ...
Bug: 157967325
Test: m dist vendor-snapshot after setting those in BoardConfig.mk
Change-Id: I6515a43d9358d94483d7c7fa2b066f9dd457f6aa
Now that the feature guarded by this flag has landed in Linux 5.10
we no longer need the flag, so we can remove it.
Bug: 135772972
Change-Id: I02fa50848cbd0486c23c8a229bb8f1ab5dd5a56f
Now newer system policy and older vendor policy can be built together by
setting following variables:
- BOARD_SEPOLICY_VERS
- BOARD_REQD_MASK_POLICY (copy of older system/sepolicy/reqd_mask)
- BOARD_PLAT_VENDOR_POLICY (copy of older system/sepolicy/vendor)
- BOARD_(SYSTEM_EXT|PRODUCT)_(PUBLIC|PRIVATE)_PREBUILT_DIRS (copy of
older system_ext and product policies)
Bug: 168159977
Test: try normal build and mixed build
Test: boot and check selinux denials
Change-Id: I20e1986cc1c877f5e3a7965e03bd8ade84fd7230
The APEX symlink optimization is a build-time trick to save the
storage/RAM usage of APEX by replacing some files in APEX with symlinks
to the files in the system partition. The optimization however is
automatically turned off for 'updatable: true' APEXes because doing the
optimization for them will hide the sys-health implication until when
the APEXes are built unbundled (i.e. prebuilt) and thus the
optimization is impossible.
TARGET_FORCE_APEX_SYMLINK_OPTIMIZATION forcibly disables the safety net.
When it is set to true, the symlink optimization is done regardless of
the 'updatable' property. This is useful for some of the devices like Go
where most APEXes (even the 'updatable: true' ones) should be
effectively non-updatable.
Bug: 175630508
Test: TARGET_FORCE_APEX_SYMLINK_OPTIMIZATION=true m and check that
updatable APEXes have symlinks to system libs
Change-Id: I26f72e5d5ebccc2d1e09c2a2f743db14937eb39a
- Add whole_static_libs
- Add `android:"arch_variant"` so arc struct can be used inside
target.android.product_variables
Test: m
Bug: 171847983
Change-Id: Iaa99b007302462ef66d0d943bc16d37a6e8ecdc7
1. Soong can now detect PRODUCT_COMPRESSED_APEX flag
We don't want APEX to be compressed on all devices. Only those that
have explicitely set PRODUCT_COMPRESSED_APEX flag.
2. Handle "compressible" field in soong build rule
On devices that supports APEX compression, all APEX will be
compressed by default. If any apex does not want to be compressed,
they will need to state that by setting "compressible" field to
false
3. Can use apex_compression_tool to compress APEX
Note we compress the APEX after it has been signed. That way, when
we decompress we will get a signed APEX.
4. Place the compressed APEX in system with .capex extension
This makes it easy to identify. We still preserve the original
extension so that when we decompress, we can just rename by cuttif
off the .capex extension.
Note: with this change, we can create a system image with compressed
APEX, but we cannot boot with it since platform doesn't know how to
handle .capex files. Platform support will be added on follow up CLs.
Bug: 172911362
Test: OVERRIDE_PRODUCT_COMPRESSED_APEX=true m (apex_test.go)
Test: observed $OUT/system/apex has .capex files
Change-Id: I20ac4c4ceb521924c751a6017f979b2d808fdded
Adds a singleton that traverses the module variants finding the ones
that are in the list (updatable and non-updatable) of boot jars and
add a ninja rule to ensure that they only contain packages from an
allowed list.
Replaces a hack that ignored any prebuilt boot jars supplied as dex
file with an equivalent one to ensure that they are still ignored.
A follow up change that switches to checking dex jars will allow the
hack to be removed.
The boot jars check can be strict or lax. If strict then all the boot
jars listed in the configuration must be found, otherwise it will only
check the ones it finds. It is strict by default unless
TARGET_BUILD_UNBUNDLED=true or ALLOW_MISSING_DEPENDENCIES=true.
Moves the script and data file from build/make.
Test: m check-boot-jars - for failing and passing cases
SKIP_BOOT_JARS_CHECK=true - no check-boot-jars target created
ALLOW_MISSING_DEPENDENCIES=true - not strict
TARGET_BUILD_UNBUNDLED=true - not strict
verified manually that apart from path differences the same
files (same check sum) were checked in both old make checks and
the new Soong ones
EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m check-boot-jars
Bug: 171479578
Change-Id: I9d81d6650ba64fc0d48d2dab4ba5a3ba8dd03dec
This change:
* Switches BootJars/UpdatableBootJars fields of config.productVariables
from []string to ConfiguredJarList.
* Updates BootJars() method to simply concatenate the jars list from
the BootJars/UpdatableBootJars fields.
* Adds an UnmarshalJSON(..) method to ConfiguredJarList to support
unmarshalling from a single string array to avoid having to change the
format of the JSON file from which the configuration is loaded.
* Adds some additional calls to ConfiguredJarList(..) in tests to
convert from []string to ConfiguredJarList. They pass nil as the
ctx argument as there is no suitable PathContext which will cause any
errors to be thrown using panic. That is reasonable for hard coded
values in tests. A follow up change will clean up the calls to
ConfiguredJarList(..).
Bug: 171479578
Test: m nothing
Change-Id: I59b94dafb479ccd8f0471ed802be175af57be271
Install to recovery/root/first_stage_ramdisk if
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT,
otherwise vendor-ramdisk. In addition, append /system
if not InstallInRoot().
On devices with dedicated recovery partition,
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT is not set,
and this installs to the correct place (under $OUT/vendor-ramdisk).
On devices without a dedicated recovery partition:
- To install a module available before switching root
to /first_stage_ramdisk, e.g. a binary under /system/bin,
use recovery{_available} and install the recovery variant
of the module.
- To install a module available after switching root
to /first_stage_ramdisk, e.g. a binary under
/first_stage_ramdisk/system/bin,
use vendor_ramdisk{_available} and install the vendor_ramdisk
variant of the module.
Test: pass
Bug: 156098440
Change-Id: I1af3f8889891a3e58263cda36f0680ce2b480499
Let the flakes, and the crashes, and the deadlocks, and the leaks, and
the undefined behavior which steals away so many nights find their
numbers decimated in the homogeneous conditions we now rest our data.
To give some intuition why this is not so underperformant, zeroing
memory is one way of priming caches.
This change is actually a no-op, because build/make/core/soong_config.mk
always overrides this setting, but it reflects the spirit and future
direction of this change.
Bug: 131355925
Test: basic simple perf comparisons
Change-Id: I8254c36373de52091839561973c9741e8f85aa09
Treehugger Robot