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
Read out/soong/late-${TARGET_PRODUCT}.mk after reading Android.mk files
to allow Soong's makevars singleton to use $(call dist-for-goals).
Test: m lint-check dist
Change-Id: I7754fd1b8dab508c96ad59beed67f0d6c4ff75f0
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
The shell script was responsible for appending some system properties
that are common to <partition>/build.prop files. The values of the
system properties were given via environment variables whose names were
slightly different from their corresponding make var names.
This change removes the script and instead write the system properties
directly in Make, thus eliminating the need to keep track of the mapping
across sysprop names, environment variable names, and make var names.
Bug: 117892318
Test: m
Change-Id: I4d88733c1afa30ea0c0c4fcfc2b349f07f7fc090
The macro `build-properties' is defined to generate build rules to
create <partition>/build.prop.
build.prop files in all partitions except for the system partition are
now build using the macro.
system partition will use the macro in the following changes.
Bug: 117892318
Test: m
Change-Id: Ibed9c96dac4366251ec59a0b1317aa92f501c9a3
Verification of compatibility with existing sh_test targets is in progress.
Bug: 148805488
Bug: 151761373
Test: make
Test: unit tests
Test: verified test config auto-gen for bc-tests and toybox-tests
Change-Id: Id8ce5dd0723e8c95921e2e20bff72fc828d47d87
This is a preliminary CL before fixing on-device paths to DEX jars.
It groups together the inormation about on-host build paths and
on-device install paths to library DEX jars.
This CL changes the structure of module dexpreopt.config files
generated by the build system. Aside of that, no functional changes.
Test: lunch aosp_cf_x86_phone-userdebug && m
Change-Id: I8e92829885f26522aa2b936e77e91ce91593b27c
allow to also skip the stripping of the modules present in vendor
ramdisk when the BOARD configuration is set to skip the strip step.
there is also a shortcoming of this functionality: it currently assumes
the modules to strip are all created equal against the same arch in
particular, however this does not work for kernel modules which are
for mixed mode platforms, as example {kernel,android} == {aarch64,armv7}
because it will select the "android" mode strip which is unaware of the
kernel mode architecture.
Bug: 156395749
Bug: 155193290
Change-Id: I35ef51845224e94e3e253acdeb6bb14b990a401b
When I removed the actions that ran the python link type checker, I
forgot that the Make version hadn't been enabled yet. Enable the Make
version.
Bug: 143748700
Test: treehugger (particularly, build_test on the downstream branches)
Change-Id: I293b3be5ca7828c9d7148e13d88b0f0bba54d964
Merged-In: I293b3be5ca7828c9d7148e13d88b0f0bba54d964
Merged-In: I08090db44d47f809fbaa0c4ad373e46e6a3fbe2e
If true, incorrect order of system server jars does not cause a build
error. The order is non-optimal if some jar X precedes its dependency Y.
In that case dexpreopt will be unable to resolve any rerefences from X
to Y.
Test: lunch cf_x86_phone-userdebug && m nothing
Test: lunch aosp_car_arm && m nothing
Bug: 140451054
Change-Id: I70efd365fa9fbd9e40792d646f8471d009164924
Merged-In: I70efd365fa9fbd9e40792d646f8471d009164924
(cherry picked from commit 17715b48f0)
Support specifying bitness of required modules with :32 and :64 suffix,
like in PRODUCT_PACKAGES.
Bug: 155869107
Bug: 129323707
Test: TH noop
Change-Id: I47d523e4e57cb8a99629fd241a16069c0be55903
* Streamline required module bitness resolution
If a module is for cross host OS, the required modules are also for that
OS.
Otherwise if the requirer module is native and the required module is
shared library or native test, then the required module resolves to the
same bitness.
Otherwise the required module resolves to both variants, if they exist.
* Factor out the common logic and merge
<target|host|host-cross>-select-bitness-of-required-modules
This lays the road for follow-up changes to add bitness suffix support.
This slightly reduces readibility. To make up for the loss, the
bitness-resolving logic is easier to maintain since we don't have
multiple copies of *-select-bitness-of-required-modules.
Bug: 155869107
Test: check the diff of product_target_FILES and product_host_FILES
Test: check the diff of ALL_MODULES.*.REQUIRED_FROM_(TARGET|HOST)
Change-Id: Ib2f4b548535e983d621dad71cb920101111140f2
Refactor the build support for kernel modules. This refactoring is
leveraged to add support for directories of kernel modules in each
partition. To add a directory of kernel modules, define
BOARD_KERNEL_MODULE_DIRS to include the directory name, for example:
BOARD_KERNEL_MODULE_DIRS := 5.4
The build will then check all the usual kernel module related macros
with an extension of _5.4, for example you can define
BOARD_VENDOR_KERNEL_MODULES_5.4 := <modules to copy>
BOARD_VENDOR_KERNEL_MODULES_ARCHIVE_5.4 = <path to archive file>
BOARD_VENDOR_KERNEL_MODULES_LOAD_5.4 := <modules for load list>
Bug: 157645635
Change-Id: I1687d0ec85c1dcf21350350623b4689aba3f6717
Moving this makes each of the partition's kernel module Makefile
generation more similar, enabling a forthcoming cleanup/refactoring.
If recovery-is-boot and there are kernel modules defined in
BOARD_GENERIC_RAMDISK_KERNEL_MODULES, those kernel modules will
now be included in the default assignment to
BOARD_RECOVERY_KERNEL_MODULES_LOAD. If this is not desired then
BOARD_RECOVERY_KERNEL_MODULES_LOAD may simply be set to
BOARD_RECOVERY_KERNEL_MODULES (or a custom list of recovery kernel
modules to load).
Bug: 157645635
Change-Id: Ia1392b7d20d07cee75420edd95dcee1dc825516e
Currently the two special-case calls to create just a module load list
(as opposed to copying a set of modules and creating a module load list)
are inside checks that the related board macro for the module set is not
empty.
While it would be incorrect to create a non-empty module load list with
an empty set of modules, this error would quickly surface at runtime.
More importantly, moving these out will permit refactoring this code to
clean it up.
Bug: 157645635
Change-Id: I199788d49072d4c59737b3ef2c75546852cf3e36
This check is meant to initialize BOARD_ODM_KERNEL_MODULES_LOAD to
BOARD_ODM_KERNEL_MODULES if BOARD_ODM_KERNEL_MODULES_LOAD is empty.
Bug: 157645635
Change-Id: I9c8ac0e64bb002e926d15b446a63801d7cfa9911
