If the env variables are loaded after the config object is created, they aren't set in the Environment object inside the config object which causes RBE to not work
Bug: b/198045383
Test: Tested by running a build against rvc-dev branch and ensuring it works.
Change-Id: I509289467df81e5535b4cbbfe4e5eb336c0e4e59
Lint reports were only being collected from jars in apexes, not
apps.
Bug: 188772607
Test: mainline_modules_arm64 build
Change-Id: Ie84819343f8b8ab3f43496bbc9b7876d0d0d8e70
Merged-In: Ie84819343f8b8ab3f43496bbc9b7876d0d0d8e70
(cherry picked from commit 8355c1524fbb1d6b7b7a25a13f66feffb1aa7214)
Previously, the java_import and java_sdk_library_import modules did not
make their permitted_packages available to the rule that generates the
updatable-bcp-packages.txt file. This change corrects that.
Bug: 193095050
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Merged-In: If0706e4551a331b48d383123088e63924dded48b
Change-Id: If0706e4551a331b48d383123088e63924dded48b
(cherry picked from commit 630b11e9d4d63e5fabaa20adf5d1b1c81ede6681)
Previously, permitted_packages were not copied to the sdk snapshot.
This change corrects that.
Bug: 193763688
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Merged-In: I4560987f746f78c0ae706058195b6db4bea438aa
Change-Id: I4560987f746f78c0ae706058195b6db4bea438aa
(cherry picked from commit 869de147abdb2c86a91cced4fda7d27746c52af4)
This is needed when some source libraries get replaced with prebuilt
variants: CLC should contain one entry for a library (the prebuilt one
or the source one, whichever of them is preferred). Because the prebuilt
module name starts with "prebuilt_" prefix, previously Soong considered
such libraries as two different ones libraries and added both to CLC.
Bug: 193425964
Test: mark "prebuilt_android.net.ipsec.ike" as preferred and `m nothing`
(before this CL it would fail the build, now it builds fine).
Test: $ lunch aosp_cf_x86_64_phone-userdebug && m && launch_cvd
$ adb wait-for-device && \
adb root && \
adb logcat | \
grep -E 'ClassLoaderContext [a-z ]+ mismatch' -C 1
# empty output, no errors
Change-Id: Icc42533d9915060d7fffda12aa93b9d18dc4f83d
Merged-In: Icc42533d9915060d7fffda12aa93b9d18dc4f83d
(cherry picked from commit 69c1aa94ac88bcb07f32c2ae4217776e82903068)
Previously, when building from prebuilts boot no rules were created to
produce the boot image files for the host, i.e. the OS on which the
build was running. That caused problems with checkbuilds. No rules were
produced as there was no host variant of a prebuilt apex to provide
them.
This change restructures the code to allow the prebuilt bootclasspath
fragment to build the host variants of the files from the dex files
provided by the prebuilt APEX. The generated files will not be the same
as they would be if built from source as there is no boot image profile
to use but it should be sufficient to satisfy the checkbuild target and
allow for host side testing.
Bug: 192575099
Test: m SOONG_CONFIG_art_module_source_build=false droid dist checkbuild
Merged-In: I6af00f19bb71aa18dd462f5eac6aa38e3e721023
Change-Id: I6af00f19bb71aa18dd462f5eac6aa38e3e721023
(cherry picked from commit a56be7d7815ad164cdd854f8fc6b1cbc3bbf1918)
Previously, boot image generation used GetCachedGlobalSoongConfig(ctx)
in order to get access to the GlobalSoongConfig. That required that
some other part of the code had called GetGlobalSoongConfig(ctx) to
initialize the cached value. That was left over from when the boot
image generation was done in a singleton which could not call
GetGlobalSoongConfig(ctx) directly. That is no longer true.
This change switches the uses of GetCachedGlobalSoongConfig(ctx) to
GetGlobalSoongConfig(ctx) and removes the now unnecessary call to
GetGlobalSoongConfig(ctx) from outside the functions.
Bug: 192575099
Test: m nothing
Merged-In: I34b7b1526d072d8b09fda7caa96e381695888e16
Change-Id: I34b7b1526d072d8b09fda7caa96e381695888e16
(cherry picked from commit 8fc51a8eb6ca20dbb4b65822123201568bb297f1)
Previously, the boot zip file, containing all the boot image files for
all the supported architectures, was only created from source. It was
not created when building from a prebuilt_bootclasspath_fragment. That
lead to build failures when building from ART prebuilts.
This change pulls the boot zip file creation out so that it can be done
for both source and prebuilt bootclasspath_fragment modules as well as
for the platform_bootclasspath module.
Bug: 192575099
Test: m out/target/product/generic_arm64/boot.zip
m SOONG_CONFIG_art_module_source_build=false out/target/product/generic_arm64/boot.zip
- Compare the output of the first command from before the change
with the output from them both after and confirm that when the
ART prebuilts are up to date with the source that there are no
differences.
Merged-In: Ie7dd5e2ca4a865d06fd9ebf87320cf68c4d05bc3
Change-Id: Ie7dd5e2ca4a865d06fd9ebf87320cf68c4d05bc3
(cherry picked from commit 56afb27fb099cb79c1537c661628db1776f1fcc3)
Sometimes the stem property is set to change both the installed file
name and the name use to filter the configured module list, e.g. when
adding a test library to replace the standard library, e.g. test_foo
instead of foo.
Sometimes it is used just to change the installed file name.
This change uses both to filter the updatable boot jars and not just
the stem.
Bug: 180105615
Test: m nothing
Merged-In: I6c459fc3597b1e4f062bc9a4e52843305b538c5f
Change-Id: I6c459fc3597b1e4f062bc9a4e52843305b538c5f
(cherry picked from commit 56c93e899a355311463d41e988c9ba511af14278)
Without these errors, the last encountered deapexer would silently be
used, and we wouldn't know if it was taken from the prebuilt APEX that
actually get installed in the system image.
With this error check there may be only one enabled prebuilt_apex or
apex_set for each apex_name (which defaults to the module name). E.g.
if there are both prebuilt com.android.foo and com.google.android.foo,
it is necessary to disable one of them in the .bp file.
Merged-In is set from https://r.android.com/1745454, a change that has
gone into AOSP and internal master, as well as sc-dev-plus-aosp, but
specifically not sc-dev. This change cannot merge into sc-dev-plus-aosp
and others, because they may or may not have the com.google.android.art
prebuilt APEX present depending on manifest, and with this check
exactly one of com.android.art and com.google.android.art prebuilts has
to be present and enabled. It'll be cherry-picked to AOSP along with a
full fix for b/192006406, when it can be safely enabled everywhere.
Test: m nothing SOONG_CONFIG_art_module_source_build=false
Test: m nothing SOONG_CONFIG_art_module_source_build=true
Test: m nothing
with enabled:true for the com.android.art prebuilt APEX - check that
it fails with an "ambiguous duplicate deapexer" error
Bug: 192006406
Bug: 192542393
Change-Id: I44566fd26b12f82a8a67fe4a69e56303460756d0
Merged-In: Id2410b4e38a78ec2146a42298840954381a7c472
Previously, bootclasspath_fragment modules would only perform hidden
API processing if they provided some stub libraries and fragments. That
was needed because the bootclasspath_fragment modules were added before
Soong supported hidden API processing on all the different modules and
before they all provided the necessary information that hidden API
processing required.
This change stops hidden API being conditional as it is no longer
required as it has been enabled on all existing bootclasspath_fragment
modules.
Bug: 179354495
Test: m nothing
Change-Id: Ibf81a7de63b888a3ebf445528326fa6101fdb1ba
Unless the prebuilt dex jar files are explicitly required to build
system images or dex preopting defer reporting of any missing dex boot
jars from Soong to Ninja.
This will prevent builds that contain prebuilt sdks, containing prebuilt
bootclasspath_fragment modules but without a corresponding apex_set or
prebuilt_apex module from failing even when it is not building against
the prebuilt sdk.
Bug: 179354495
Test: m nothing
Merged-In: Ibde3bf840a7413785cd32bd6cea1c322f90c59af
Change-Id: Ibde3bf840a7413785cd32bd6cea1c322f90c59af
(cherry picked from commit ef083c9556c53738e5d7a3ab791c49ef00501f73)
Previously, if a bootclasspath_fragment had both a java_sdk_library
module and one of its components in stub_libs properties they would be
treated as separate modules instead of simply different APIs from the
same module. That would result in them both providing stub dex jars to
"hiddenapi list" which would fail because it found duplicate
definitions of the same class.
e.g. Specifying something like this:
api: {
stub_libs: [
"art.module.public.api",
],
},
core_platform_api: {
stub_libs: [
"art.module.public.api.stubs.module_lib",
],
},
would cause "hiddenapi list" to fail because it would have been passed
paths to two dex jars (actually the same dex jar but that does not
matter) each of which defined the same class, e.g. java.lang.Object.
This change treats the "art.module.public.api.stubs.module_lib" and
"art.module.public.api" modules as being the same for the purposes of
hidden API processing.
(cherry picked from commit 3f0290ef7940c70a491dcbd4b57cabd8b2e753ef)
Bug: 192446466
Test: m nothing
Merged-In: I9de96337f64f26e24cff040d4bbed9eecc67b1ed
Change-Id: I9e1cb82bea96022faaec98edc0c9ea7eac6204b0
Previously, bootclasspath_fragment modules would only perform hidden
API processing if they provided some stub libraries and fragments. That
was needed because the bootclasspath_fragment modules were added before
Soong supported hidden API processing on all the different modules and
before they all provided the necessary information that hidden API
processing required.
This change stops hidden API being conditional as it is no longer
required as it has been enabled on all existing bootclasspath_fragment
modules.
Bug: 179354495
Test: m nothing
Change-Id: I0cbf11986adff1f2f967b96f86e6bfe0e9b8b1ef
Kousik Kumar