Also, add function `install-path-to-on-device-path` that converts
its one argument from on-host install path to on-device path by
stripping PRODUCT_OUT prefix.
Test: lunch aosp_cf_x86_phone-userdebug && m
Test: Cherry-pick in internal master and check that on-device path to
com.google.android.dialer.support.jar now is on /product partition
(as it should be) and not on /system:
$ oatdump \
--instruction-set=x86 \
--oat-file=out/target/product/vsoc_x86/product/priv-app/GoogleDialer/oat/x86/GoogleDialer.odex \
| grep '^classpath' \
| grep -o '[^[]*com.google.android.dialer.support.jar'
/product/framework/com.google.android.dialer.support.jar
Bug: 132357300
Change-Id: I9bbe45ffbbed09186ac46e067da7ada599ef9678
This moves the condition from Soong to make, so that
config.UnbundledBuild() in Soong no longer implies disabling
dexpreopting.
Test: TH, in particular builds green on ub-launcher3-master
Bug: 157549171
Change-Id: I7273be8591c9d627d89e033b641139dacc275806
Setting this flag enables unbundled building, i.e. without support for
building the system image and other platform targets. This
functionality was previously enabled by TARGET_BUILD_APPS, and setting
that still implies TARGET_BUILD_UNBUNDLED.
This helps unbundled builds that aren't apps, e.g. ART runtest builds.
Specifically, with the topic of the child CL
https://r.android.com/1324517 TARGET_BUILD_UNBUNDLED does not imply
disabling dexpreopting, unlike TARGET_BUILD_APPS.
TODO: There may still be app-specific conditions that are incorrectly
controlled by TARGET_BUILD_UNBUNDLED, in particular on the Soong side
through config.UnbundledBuild().
Test: Flash & boot
Test: TH, in particular builds green on ub-launcher3-master
Bug: 157549171
Change-Id: Ic09fc879117ee06cab5444edfc280ed2b52d2870
The core android build platform has changed to add support for LZ4
compression for ramdisks, but the release tools were not. Fix this.
Bug: 156129966
Change-Id: I39680b91930d2d3cbd0cd565beb78e1ee699397e
A few more misc improvements that I found while analyzing the
performance of base_rules.mk.
This brings an aosp-master/aosp_crosshatch-userdebug kati run from 33.3s
to 28.6s
Bug: 158488548
Test: build-aosp_crosshatch.ninja is the same before/after
Change-Id: If99c31cc7b5d7133d70eb644c6095f19060b71e5
These are no longer used by anyone:
* get-32-bit-modules
* get-32-bit-modules-if-we-can
* get-host-32-bit-modules
* get-host-32-bit-modules-if-we-can
Bug: 155869107
Test: TH
Change-Id: I441de7f94061efd40186b80d1a2ead11669a5753
Instead of using `x := $(x) foo`, make sure `x` is initialized first,
then use `x += foo`.
For a aosp-master/aosp_crosshatch-userdebug build, this takes the build
from 49s to 33s (no significant difference in peak memory)
Bug: 158488548
Test: build-aosp_crosshatch.ninja is the same before/after
Change-Id: I41fb7611030dd3ba824f896a9c9eadbdd218f464
It turns out we have a few tests with thousands of test data files,
which this logic does not handle very well. Just switching from `x :=
$(x) ...` to `x += ...` accomplishes the majority of these gains, but I
rewrote the logic to be less function-call+eval based to hopefully make
it easier to understand.
For an aosp-master/aosp_coral-eng build, this brings the time spent in
this logic from 7.6s to 0.3s (total kati runtime of 54s to 46s). Kati's
peak memory use (maxrss) also shrunk from 6.1GB to 3.8GB.
Bug: 158488548
Test: build-aosp_coral.ninja is the same before/after
Change-Id: Ia2ec8b29b5c1dd12fa7ea10b4f80fe802c692725
post_process_prop.py doesn't simply drop a line when deleting a prop.
Instead, it makes the line as comment and leave a comment to clearly
mark that the prop was force removed. This is to aid the debugging.
Bug: 117892318
Test: m
Change-Id: I53c05800ff71d431a56dc370bcfe8bfc95c03bfc
Like other <partition>/build.prop files, the build rule for
system/build.prop is also created using the build-properties macro.
system/build.prop has a few number of auto-generate properties that the
macro doesn't create. Those properties are emitted to intermediate files
using manually crafted rules, the paths to the files are fed to the
macro, where their contents are copied to system/build.prop.
This change also refactors the code fragment that defines BUILD_*
variables that identifes the given build.
Bug: 117892318
Test: m
Change-Id: Ic218283b40fedeaddacb3fda93167edbec86094c
When kernel modules are being put directly into lib/modules/ (as opposed
to lib/modules/<subdir>/), the empty part of the destination path causes
a target containing a redundant /. If the target is also added elsewhere
in the build without the redundant /, then rule merging will miss it,
and a build error will occur.
Bug: 158158635
Change-Id: I797addce760f4886166efa283302a53783581625
