So that we have a more restricted enviornment for this new configuration
axis that can also be imported into other tools more easily.
Test: Manually (this time also tested setting OUT_DIR outside of the tree)
Change-Id: I01d90e06e45cba756156af16f63e04f575877263
This reverts commit c113a70221.
Doesn't work with OUT_DIR hard coded outside the tree.
Test: OUT_DIR=/source/whatever m
Bug: 283278495
Change-Id: I8cc74a9ec936b9c7502b97b9b7a4fd731988c407
So that we have a more restricted enviornment for this new configuration
axis that can also be imported into other tools more easily.
Test: Manually
Change-Id: Iabce1919f6d6f57a256ae144784af7c47622b54d
Adds a new `$(call run-starlark,my/starlark/file.bzl)` function that
will run the starlark file and set all the variables in the
variables_to_export_to_make dictionary as make variables.
Fixes: 280685526
Test: m nothing repeatedly causes no ninja regeneration, but touching all_versions.bzl does. go test, ./out/rbcrun -mode=rbc ./build/make/tests/run.rbc
Change-Id: Ic72e18dd28dba8233ba2dfb658b5d03ccece1bfd
For some reason, some internal products were failing the
quick rbc ci check purely because of indentation differences
in the variable dump file. That file has a lot of wonky
leading indentation due to the foreaches and line breaks
in the function implementation that I couldn't figure
out how to remove. Instead, use a sed command to remove
leading spaces after writing the file.
Bug: 239453560
Test: build/bazel/ci/rbc_dashboard.py --quick on a new internal-only product
Change-Id: I4b34d8e0b5dbbfcbb9ed35345d216ca11a5a1198
These were marked as deprecated in late 2020 [1]. Shortly later, there
was an attempt to obsolete them [2] for products shipping with API level
31 or greater, but that was reverted [3] because of internal users.
1: I58c64839cc513ae082cd3ee3c1e108843ea7439e
2: Ic4d1164be611836f6aa697fbf1cb1f1c73a3cd39
3: I7d3556aa0f06684b43f80f09e4c8194c6c44336c
Since these are causing warnings on every build, and there are no more
internal users, just obsolete them entirely. We don't need to rely on
the product shipping api level, since that does not guarantee
source-level compatibility -- and this is an easy fix even if people
have been ignoring the real warnings.
Bug: 235414673
Test: treehugger
Change-Id: If803a33efc38a970247919bf224c12b8c717f955
config.mk represents essentially the entire product/board
configuration. In order to develop a "quick" rbc regression
test, dump all the make variables at the end of config.mk.
We can then compare these variable dumps instead of ninja
files, because the ninja files take much longer to generate.
Bug: 229132189
Test: Manually
Change-Id: I4e8371be446b7e511aba22dff58530a6d9ff072f
The shell command was too long when it listed all the make variables.
Dump them to a file instead.
Fixes: 228347189
Test: RBC_BOARD_CONFIG=1 m nothing on aosp_arm64
Change-Id: I325c78810f5efbe87df2c3ffc269ed78db8c3732
Add vendor_kernel_boot image for vendors whose bootloader support
extra first stage booting kernel modules ramdisks. This benefit
kernel repo to build kernel-artifacts only image without Andorid
artifacts dependency.
Bug: 214409109
Signed-off-by: Lucas Wei <lucaswei@google.com>
Change-Id: If07218b86a7751b3d452a172610af960f5f9ec74
Kati regenerates its ninja file if an environment variable
that was referenced by the makefiles was changed since the
last run. TRACE_BEGIN_SOONG is a constantly changing variable
that was referenced by dump-variables-rbc, which references
all all-caps variables, with a few exceptions.
Add TRACE_BEGIN_SOONG to that exception list so kati doesn't
rerun every time.
Fixes: 216531048
Test: Manually
Change-Id: I2df65b6f6aa968f132380e3410763d907d9e3e0f
There are 2 choices to build system_dlkm.img for
the system_dlkm partition for Android T launch
devices and must choose one.
1. Use kernel prebuilt system_dlkm.img
- BOARD_PREBUILT_SYSTEM_DLKM_IMAGE to point image
2. Build from kernel prebuilt system_dlkm_staging
- PRODUCT_BUILD_SYSTEM_DLKM_IMAGE
Both requires: BOARD_SYSTEM_DLKM_PARTITION_SIZE and
must be 64MB or higher in size (enforced via vts).
Bug: 200082547
Test: TH
Test: atest vts_system_dlkm_partition_test
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
Change-Id: I83435123bd8aa3d04ab8a8b650a95fbab0bc49f2
There are some products whose board configurations
use soong_config_get to read the values of soong config
variables that were set in the product configuration.
These variables were being lost, as dump-variables-rbc
was skipping the soong config variables because mk2rbc
couldn't handle converting the raw SOONG_CONFIG_* variables.
To fix that issue, dump-variables-rbc now dumps them as
calls to soong_config_set instead.
Bug: 201700692
Test: m RBC_BOARD_CONFIG=1 nothing on certain products
Change-Id: I91ca8418635a94cf80362cad1729f48854f6bc98
Soong will use this to turn on universal binary support (X86_64 + Arm64
in the same binary).
Bug: 203607969
Test: m sdk-repo-platform-tools sdk-repo-build-tools on Mac
Change-Id: I04612136a42e85f4add95202ce20e741d9aaa302
Passing variables via a makefile instead of
rblf_cli / rblf_env allows us to give them correct
types while converting the makefile to starlark,
as opposed to the variables always being strings
when given via rblf_cli / rblf_env.
This also allows us to remove some hand-converted
starlark code.
Bug: 201700692
Test: ./out/soong/rbcrun ./build/make/tests/run.rbc
Change-Id: I58c4f20b29171c14e5ae759beb26a849426f6961
Certain board configurations reference $(PRODUCT_OUT)
through deferred expansion, which will no longer work
after conversion to starlark.
Bug: 201700692
Test: build/bazel/ci/rbc_regression_test.sh -b yukawa-userdebug
Change-Id: I02055f5c4a05e540c1752d5964d4db4306292c3b
Soong now installs to the same directory as Make, point SOONG_HOST_OUT
at HOST_OUT.
Bug: 204136549
Test: m checkbuild
Change-Id: I49bfc0466056d270c8023288a6fe778c3445a900
Rename to get consistent ramdisk directory naming in
out/target/product/<name>:
debug_ramdisk
ramdisk
vendor_debug_ramdisk
vendor_ramdisk
Test: build and inspect out/target/product/<name>
Change-Id: I81d8f2cafe5e1b9024196cd74772b78d4a4aec58
This to allow operating on the complete ART_APEX_JARS list from make in
a follow-up CL.
Test: m nothing
Test: m nothing EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true
Bug: 180325915
Change-Id: Ic08148edf25738f6f4769e5359a573237a38b0e9
Modules partition is a dynamic read-write partition.
- AVB is not enabled on the partition
- OTA is file-based; see follow up CL for details
- No build prop files; in particular, no build fingerprint
- No fs_config
- No notice files; notice files are included in individual APEXes
Test: build on CF
Bug: 163543381
Change-Id: Ie397b9ec61dfd1c158450d050196024604854d4d
Previously, HOST_CROSS_OS/ARCH were fixed to windows/x86. This change
makes the setting configuration and adds the support for new OS/ARCH
combo: linux_bionic/arm64.
linux_bionic is the Linux-based host target that uses Bionic (instead of
glibc) as libc. Previously, it supported only x86_64 and the x86_64
target was NOT configured via Make, but directly via editing
soong.variables file. Now, the support for arm64 is being added in the
Soong side and this change makes it possible to configure the target via
Make.
The new HOST_CROSS_OS/ARCH combo will be used for building the host-side
tools (adb, crosvm, etc.) for running Cuttlefish natively on Linux/ARM
hosts.
Bug: 159685774
Test: HOST_CROSS_OS=linux_bionic HOST_CROSS_ARCH=arm64 m nothing
Change-Id: I6b8ed8f7e26908749bbe778fbdcc34cfbde68179
Previously, HOST_CROSS_OUT was defined with the assumption that
windows_x86 is the only supported OS/Arch. In preparatio for Linux/ARM
support, HOST_CROSS_OUT is now defined using HOST_CROSS_OS and
HOST_CROSS_ARCH.
Bug: 159685774
Test: m
Change-Id: I0831c2885db37c44af4fd47bab8481bc885b4b7e
- TARGET_BUILD_UNBUNDLED_IMAGE is similar to TARGET_BUILD_APPS, but
its targets are the unbundled partitions instead of apps.
- Rename TARGET_BUILD_APPS_USE_PREBUILT_SDK to TARGET_BUILD_USE_PREBUILT_SDKS
because it is used even without TARGET_BUILD_APPS.
-Instead of TARGET_BUILD_APPS, use TARGET_BUILD_USE_PREBUILT_SDKS
to build java modules with prebuilt sdks, and propagate to Soong.
Bug: 160390776
Test: TARGET_BUILD_UNBUNDLED_IMAGE=true m vendorimage
Change-Id: Ie096212ccbcca0018baae55e106af693b002c9e5
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
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
Revert "Move libpac into i18n APEX"
Revert "Add shared library into i18n APEX and add the required s..."
Revert "Make com_android_i18n namespace visible"
Revert submission 1299494-i18nApex
Reason for revert: Breaking aosp_x86-eng on aosp-master
Reverted Changes:
I30fc3735b:Move ICU from ART APEX to i18n APEX
Icb7e98b5c:Calling @IntraCoreApi from core-icu4j should not c...
Ic7de63fe3:Move core-icu4j into I18n APEX
I65b97bdba:Make com_android_i18n namespace visible
Ia4c83bc15:Move v8 and libpac into i18n APEX
I10e6d4948:Move core-icu4j into i18n APEX
I8d989cad7:Move ICU from ART APEX into i18n APEX
I72216ca12:Move ICU into i18n APEX
Ief9dace85:Add shared library into i18n APEX and add the requ...
I7d97a10ba:Move libpac into i18n APEX
I90fff9c55:Move ICU from ART APEX into i18n APEX
Change-Id: I12a7d609d43620edaf2c5f12711eb3ca3a570d79
The first component is the apex name, or a special name "platform"
if the boot jar is a platform jar rather than a part of some apex.
This is a prerequisite change for moving core-icu4j to a separate
com.android.i18n apex.
Old one-column format is still supported, but all unqualified
components of PRODUCT_BOOT_JARS get "platform:" prepended to them
after reading the product makefiles.
Test: aosp_walleye-userdebug boots
Bug: 138994281
Change-Id: I0f79c7d10477880ca65354251a5d1ca0b7ce79ab
These were deprecated in R, which has now branched, and there aren't any
users on master.
Test: build-aosp_crosshatch.ninja is identical
Test: treehugger
Change-Id: I6286880e45c0facbae56f9a16e8cfcbde12f121c
This was deprecated in R, which has now branched, and there aren't any
users on master.
Test: build-aosp_crosshatch.ninja is the same (except for the removal of the empty auxiliary target)
Test: treehugger
Change-Id: I306156ab7f91cd4a2258554b4215766c99cd12d1
Commit I30137c3caef91805d9143d404e5e4d06c0fccc30 adds boot-debug.img
to allow adb root with an user build GSI image.
https://source.android.com/compatibility/vts/vts-on-gsi
Another commit I5b005097b73f59857c3a2f92d693b3e67ee8424e adds
vendor_boot.img to pair with a generic kernel image, the GKI boot.img.
To allow adb root for devices using a GKI, vendor_boot-debug.img is
introduced. The image combination used in VTS will be:
Old devices without GKI:
GSI system.img + boot-debug.img + vendor.img, etc.
New devices with GKI:
GSI system.img + GKI boot.img + vendor_boot-debug.img + vendor.img, etc.
Note that boot-debug.img still can be used on new devices for
non-compliance scenario.
Bug: 147849477
Test: lunch aosp_cf_x86_64_phone-userdebug; make vendorbootimage_debug
Test: `make dist`, checks that both vendor_boot-debug.img and
vendor-ramdisk-debug.cpio.gz are in $OUT/ and out/dist.
Test: `make dist`, checks that installed-files-vendor-ramdisk-debug.{json,txt} are
in $OUT/ and out/dist.
Change-Id: I66b662d8b1e5c619ed7bb81e40233fe9df363b27
Before this change, `jacocoagent` was conditionally added to
`TARGET_CORE_JARS`. However, this module is not really part of the
Android Core Libraries (also, we plan to remove `TARGET_CORE_JARS`
from `PRODUCT_PACKAGES`). Remove it from `TARGET_CORE_JARS` while
keeping it in `PRODUCT_PACKAGES` and `PRODUCT_BOOT_JARS`, to keep
having it installed and being part of the boot class path on
devices (under the same conditions).
Test: Check that:
export EMMA_INSTRUMENT=true
&& unset EMMA_INSTRUMENT_STATIC
&& m installclean
&& m systemimage
generates a system image that contains these files:
/system/framework/apex-jacocoagent.vdex
/system/framework/boot-jacocoagent.vdex
/system/framework/jacocoagent.jar
/system/framework/<arch>/apex-jacocoagent.art
/system/framework/<arch>/apex-jacocoagent.oat
/system/framework/<arch>/apex-jacocoagent.vdex
/system/framework/<arch>/boot-jacocoagent.art
/system/framework/<arch>/boot-jacocoagent.oat
/system/framework/<arch>/boot-jacocoagent.vdex
Test: Run test ATP test avd/avd_boot_health_check on build target
cf_x86_phone-userdebug_coverage
Bug: 143304991
Bug: 142944799
Change-Id: Ib047a394342aeffbfec26ebc756159f145d6523e
In commit I30137c3caef91805d9143d404e5e4d06c0fccc30, we added
a boot-debug.img to allow adb root when using an user build GSI image.
However, to run automated tests, it requires additional properties,
which are not needed for GSI compliance:
ro.audio.silent=1
ro.test_harness=1
This CL adds an additional boot-test-harness.img for automated tests,
and keeps the original boot-debug.img for GSI compliance.
Note: boot-test-harness.img won't be built by default, it needs
explicit `make bootimage_test_harness`.
Bug: 140036184
Test: `m bootimage_test_harness`, flashes boot-test-harness.img and checks
adb root works and test harness props are set.
Test: `m bootimage_test_harness dist -j32`, checks both
boot-test-harness.img and ramdisk-test-harness.img are under ./out/dist/.
Test: `system/tools/mkbootimg/unpack_bootimg.py --boot_img $OUT/boot-test-harness.img --out ramdisk-test-harness`,
checks the extracted out/ramdisk is as expected
Test: Run `gunzip -c ramdisk | cpio -idm` for the ramdisk extracted from
$OUT/boot-test-harness.img and $OUT/boot-debug.img, respectively.
Then compare the root dirs of both, e.g.,
`diff -rq --no-dereference ./ramdisk-test-harness ./ramdisk-debug`
Test: `m ramdisk_test_harness-nodeps` and `m bootimage_test_harness-nodeps`
Change-Id: Iadea0b5c933c3b7fa10dcf3d9e85596916b3333d
