This is needed in order to allow it to implement MakeVars so it can
create make variables just like the dexpreopt_bootjars and hiddenapi
singletons currently do.
Bug: 177892522
Bug: 179354495
Test: m nothing
Change-Id: Ida5bf8abeecde531e1f6430151650065445804ac
Bug: 177892522
Test: m oat-dump-boot
- test output to make sure that this change does not change the
generated files, at least no more than no changes do as the
output from this rule is not deterministic. See b/186459873.
Change-Id: Ib2b4203d9bb1fd0ee9443aee4e58b54b38b491cf
Changes generateUpdatableBcpPackagesRule to use ModuleContext instead
of SingletonContext and moves the call from dexpreoptBootJar's
GenerateSingletonBuildActions method to platform_bootclasspath's
GenerateAndroidBuildActions.
Bug: 177892522
Test: lunch art_module_arm64
m out/soong/module_arm64/dex_bootjars/updatable-bcp-packages.txt
- make sure it is not affected by this change
Change-Id: I9741ae1eb9573cafe12dd7a17dc1d8449b224dc8
Bug: 177892522
Test: lunch art_module_arm64
m out/soong/module_arm64/dex_bootjars/updatable-bcp-packages.txt
- make sure it is not affected by this change
Change-Id: I3d35f1664cbbaba5df3f5809859dd9815a26d05d
Trades having to traverse a module's direct dependencies multiple times
for reusable code. While at the minute the amount of duplicated code is
small (checking a tag and appending to a list) follow up changes will
modify the gatherApexModulePairDepsWithTag module to improve error
reporting greatly increasing the benefit of deduping.
The cost of traversing a module's direct dependencies is very small as
there will be only a very few dependencies.
Bug: 177892522
Test: m nothing
Change-Id: I16389102abd8038e1bfa52b63f4153bdf92ff553
Change https://r.android.com/1672245 added support to treat
system_ext:foo in the boot jars configuration the same as platform:foo,
at least for dexpreopt_bootjars.go's getBootJar.
This change replicates that mechanism in platform_bootclasspath and as
that now handles hidden API processing also made a similar change in
the isModuleInConfiguredList function.
Bug: 177892522
Bug: 154976937
Test: m nothing
Change-Id: I105f4fbaa3b0355b013b7c5618d218d888faefb6
The hidden API processing needs access to dex stub jars for the API
scopes provided by the bootclasspath_fragment so that it can mark the
corresponding dex members as being part of that API. This change adds
the ability to specify the modules that provide those jars, resolve the
modules to dex jar stubs and make them available for other modules and
tests to use.
While the stubs are only needed for hidden API at the moment these were
not added to the hidden_api properties section as there are other parts
of the build that may need to access the stubs in future, e.g. api
fingerprint and aidl generation.
The stubs properties can be affected by coverage as when coverage is
enabled the jacoco-stubs needs adding to the list, just like how
jacocoagent is added to the contents.
Bug: 177892522
Test: m nothing
Change-Id: I31097d1ca45c84adeba4cbb38f693698cb289e99
This simplifies the process of moving the updatableBcpPackagesRule to
the platform_bootclasspath by separating the gathering of the list of
updatable modules (which differs between the singleton and the
platform_bootclasspath module) from the gathering of the permitted
packages list and generation of the rule which are generally common.
Bug: 177892522
Test: lunch art_module_arm64
m out/soong/module_arm64/dex_bootjars/updatable-bcp-packages.txt
- make sure it is not affected by this change
Change-Id: I3cb64310f618059758a32cfe00d3745d52388e49
Previously, the method was run in repo manifests that did not include
the frameworks/base repository so it had to handle the file being
missing. However, now that this is being called from
platform_bootclasspath which is only defined in frameworks/base that
is no longer required.
Bug: 177892522
Test: m droid
Change-Id: I77fa5a204d1426a6be24a6f0b48e18f48f3dd908
Changes bootFrameworkProfileRule to use ModuleContext instead of
SingletonContext and moves the call from dexpreoptBootJar's
GenerateSingletonBuildActions method to platform_bootclasspath's
GenerateAndroidBuildActions.
Changing the context also allows the code to switch from
bootFrameworkProfileRule to GetGlobalSoongConfig.
Also extracts the shouldBuildBootImages function so it can be used by
platform_bootclasspath to preserve the existing behavior.
Bug: 177892522
Test: m droid
Change-Id: I30d3ca10be7f84348ad3aa9cc984dd15b8f6f4e9
This change makes the tag that is used to add dependencies onto stubs
from the bootclaspath_fragment module cause the dependency to be
automatically exported from the sdk. If the dependency is a
java_sdk_library then it will be as if it was added to the
java_sdk_libs property, otherwise it will be as if it was added to the
java_header_libs property instead.
Bug: 177892522
Test: m nothing
Change-Id: I97010c4342dd39415dba81a4395db7831410436e
This change allows an SdkMemberTypeDependencyTag to select the
SdkMemberType to use to add a dependency based on the module.
Bug: 177892522
Test: m nothing
Change-Id: I2d6e51b615636dc7cd41da65808ef851dd8ae6ac
Previously, buildBootImage had to be called for the default boot image
config before the art boot image config as it created some rules which
were specific to default boot image. The creation of these rules was
encapsulated in Config().Once(..) to ensure that they were only ever
created once.
This change extracts that functionality out of buildBootImage to the
calling method which means that they are only called once and so no
longer need protecting against being called again.
Bug: 177892522
Test: m droid
Change-Id: I464477de1a08df15e577873a9accf7db2bc088d1
Previously, the buildBootImage function maintained a list of
missingDeps that was returned from findAndCopyBootJars and was passed
to various other methods that created ninja rules that depended on the
files created by findAndCopyBootJars. The purpose of that list was
basically to record that findAndCopyBootJars could not find some files
so that the subsequent ninja rules could be marked as being in error.
This changes avoids having to explicitly propagate the missing deps to
each rule by instead having findAndCopyBootJars generate an error rule
instead of a Cp rule for any missing file. That means that any attempt
to build any rule that depends on the missing file will fail when the
missing file is created.
Bug: 177892522
Test: Add an unknown module to PRODUCT_BOOT_JARS
lunch art_module_arm64
- Run each of the following targets and made sure it failed with a
message indicating that the unknown module was missing.
m SOONG_ALLOW_MISSING_DEPENDENCIES=true out/soong/module_arm64/dex_bootjars/boot.prof
m SOONG_ALLOW_MISSING_DEPENDENCIES=true out/soong/generic_arm64/dex_bootjars/boot.bprof
m SOONG_ALLOW_MISSING_DEPENDENCIES=true out/soong/generic_arm64/dex_bootjars/updatable-bcp-packages.txt
Change-Id: Ib7196c128419fbffdfeb61c1c5d47a3b08d1e132
The code that has been removed triggers in many cases when it should
not, e.g. an unknown module on the bootclasspath. The code was
originally added to try and ensure that if the attempt to add useful
error messages failed it would help debug the issue. However, it ended
up just creating more failures.
If this does become an issue then this will be revisited.
Bug: 177892522
Test: Add an unknown module to PRODUCT_BOOT_JARS
m SOONG_ALLOW_MISSING_DEPENDENCIES=true
Change-Id: I08dbd4b29d301f3f1f78a0fb396687062b47deb8
Previously, both a bootclasspath_fragment and its contents had to be
explicitly added to the sdk. This change means that adding a
bootclasspath_fragment to and sdk will automatically add its contents
as if they were added using java_boot_libs.
Bug: 177892522
Test: m nothing
Change-Id: I8f7e70649f272c9a109d4606571a2d12c44b7904
Previously, only one of the contents or image_name properties could be
specified at once which meant that there was no way to create a
prebuilt which lists its fixed contents while at the same time allowing
it to check that that the contents matched what the build configuration
required.
e.g. a prebuilt_bootclasspath_fragment that had image_name: "art",
could not list its contents and also check that those contents matched
the ART_APEX_JARS which the build configuration required.
This change allows contents and image_name to be specified together and
adds a check to make sure that the contents are consistent with the
configuration appropriate to the image_name. The check is only
performed for modules that are active so that a
prebuilt_bootclasspath_fragment which was created without coverage
enabled (the default) would not cause a build failure in a coverage
build unless it was preferred.
Bug: 177892522
Test: m nothing
Change-Id: Ie601f29f707b3f6030fa7d252afa2c4826cc9f8e
This will allow them to be used from elsewhere in a follow up change.
Bug: 177892522
Test: m nothing
Change-Id: I60e94e148af5b1810aea7f724cba090b49ae758e
This allows a bootclasspath_fragment (specifically the
art-bootclasspath-fragment) to specify additional contents to be
appended when coverage is enabled.
The art-bootclasspath-fragment will use this to add jacocoagent to its
contents to ensure that it is always consistent with the configuration.
Bug: 177892522
Test: m nothing
Change-Id: I50d05fe5e0e9b8c14bdf3dfd63bba0ac97e31d48
The field isn't used anymore.
And DexPreoptImagesDeps will have the slice of which size is the same as
Archs to avoid an error.
Bug: 158843648
Test: m
Change-Id: I520063ff7376811febbc82e1a0a43785feb5bbb2
The dex boot jar for the apex must have had hidden API flags encoded
into it. Currently, the hidden API processing is done within the java
modules themselves so the apex gets the dex boot jar from them.
However, as part of the hidden API modularization work the hidden API
encoding will be performed by the bootclasspath_fragment so this change
prepares for that by delegating the retrieval of the dex boot jars to
the bootclasspath_fragment, via BootclasspathFragmentApexContentInfo.
For the moment that simply delegates straight back to the java module
so this change does not change the build. It will however make it
easier to switch hidden API encoding to the bootclasspath_fragment in
future.
Bug: 179354495
Test: m com.android.art
- verify that this change does not change its contents
Change-Id: I12eba333749be976bcc72661bb9d6be6cc3c56e3
Currently, it only contains ART boot image related information, i.e.
.art, .oat and .vdex files. However, follow up changes will extend that
to include other information from bootclasspath_fragment.
Bug: 177892522
Test: m nothing
Change-Id: I2b226131c0eccff0c739a18f265f90caa10a91d9
The BootImageInfo is used to populate an apex. A platform_bootclasspath
module cannot be part of an apex so does not need to provide one.
Bug: 177892522
Test: m nothing
Change-Id: I1e1c4962d9d8106a12af80107c4c35828f54ff81
Previously, every module added to an sdk directly through one of the
SdkMemberType specific properties, e.g. java_libs, was exported and
every module added automatically via a transitive dependencies was not
exported. This change allows that behavior to be customized per tag.
Bug: 186290299
Test: m art-module-sdk
- verify that this change does not affect its contents.
Change-Id: I563b5bcd823e61c23cdb706cfcbb13337963d550
Also renames files, tests, module types in a similar fashion.
There are still some references to image and boot image. They are kept
for the following reasons:
* image_name - this is the name of an ART boot image, i.e. the
collection of .art/.oat/.vdex files.
* BootImageInfo - again this is related to the ART boot image.
* .../art_boot_images/... paths - ditto.
Bug: 177892522
Test: m nothing
Change-Id: Ie1f4738061d131fee75de48bc26a7601481bad4d
This is needed to allow a prebuilt_bootclasspath_fragment to be used
interchangeably with a bootclasspath_fragment in the
platform_bootclasspath module.
The platform_bootclasspath module depends on APEX specific variants of
bootclasspath_fragment modules. That works because the
bootclasspath_fragment modules are part of an apex and so have an APEX
specific variant which the platform_bootclasspath can specify.
Using a prebuilt_bootclasspath_fragment in place of a
bootclasspath_fragment requires that the prebuilt also has an APEX
specific variant.
Specifying exported_bootclasspath_fragments on a prebuilt_apex/apex_set
will cause it to create an APEX variant for the named module whcih will
allow it to be selected by the platform_bootclasspath module.
Bug: 186034565
Bug: 177892522
Test: m nothing
Change-Id: I7ddacc6498ec3a4a9f26c5f78b7f9a033e494d78
This exports classesJars constructed in hiddenAPIExtractInformation
through the hiddenAPIIntf interface for use by the
bootclasspath_fragment module type.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: Ic32f02a69229d9518772fe6b2a329501dd8cd849
The platform_bootclasspath and bootclasspath_fragment modules provide
different capabilities but are related and so have some common
functionality. This change moves some platform_bootclasspath code that
will be of use for bootclasspath_fragment in future into a separate
file.
Bug: 177892522
Test: m nothing
Change-Id: I827b85e33d16155fcc920d553100c9e99267dc4e
Adds a BootclasspathDepsMutator that is currently only implemented by
the platform_bootclasspath but which can be implemented by
bootclasspath_fragment too.
Bug: 177892522
Test: m nothing
Change-Id: Ibe35854281004d6e40bf1f797144fb582e8c08b9
The jacocoagent is special as while it is depended on by prebuilts it
is not actually a prebuilt.
Bug: 177892522
Bug: 186118711
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true nothing
Previous command fails without this change and works with it.
Change-Id: I8fba922fc40919936d74a6f95af745e37f1ca61f
As part of that this change:
* Moves code that will be common to platform_bootclasspath and
bootclasspath_fragment from hiddenapi_singleton.go into
hiddenapi_modular.go.
* Fixes the tests in hiddenapi_singleton_test.go but intentionally
does not rename them or move them into a more appropriate place so
as to make it easier to see the differences. A TODO has been added
and these will be cleaned up in a follow up change.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I680e4dab2e6bdf4a655fa9f255c195175904667e
The stubFlagsRule does three separate tasks:
1. It computes the set of modules that provide the stubs.
2. It scans all the modules to find the stub modules and retrieves the
paths to their dex files.
3. It constructs the ninja rule.
Of those three tasks, 1 and 3 will be same for the
platform_bootclasspath. Instead of searching all the modules for the
ones that provide the stubs it will simply add dependencies onto the
stub modules and retrieve the dex file paths from them.
This change extracts tasks 1 and 3 into separate methods for reuse. It
also parameterizes the generation of the ninja rule.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I893845dbddc4b001dfd44d0e0b1c8a31b7f3f89f
They were used to generate export values for BOOTCLASSPATH and friends;
which are now generated by derive_classpath service based on proto
configs at runtime.
Bug: 180105615
Test: m && launch_cvd; presubmit / DeviceBootTest
Change-Id: Ifbf3f076a00e084d47a48180a4286fc53e610c5d
Allow java_sdk_libraries to include libraries statically into their
stubs. The immediate use-case of this is to embed libcore notice files
into their stubs.
Also extend the java_sdk_library tests for impl/stub-only-libs, plus
some not assert utils.
Bug: 173186484
Bug: 184839599
Test: soong tests
Change-Id: I1ebf2f35c048eab5cec5125482a0304fe660f188
The flag prevents developers from skipping updatability lint checks with
baseline files
Test: lint_test.go & manual
Bug: 182349282
Change-Id: Ia74a2b83c7ef686124128bdf16f7b85a919d9e8d
These are needed at the moment to ensure the hidden API processing
generates the same set of flags whether it is being generated from
source or prebuilts. Soon these will be needed to ensure that the
hidden API flags generated for the individual modules are compatible
with previous releases.
Bug: 179354495
Test: m art-module-sdk and check snapshot zip contains the files
and the generated Android.bp references them.
Change-Id: I9a3334cc48faa381bbbcbbb59479db719042796a
Previously, there were two approaches used to construct the temporary
path needed by the commitChangeForRestat method and neither was
suitable for general use. One was:
android.PathForOutput(ctx, outputPath.Rel()+".tmp")
The other was:
combinedAidl.ReplaceExtension(ctx, "aidl.tmp")
The first approach would not work if the supplied path had been created
by PathForModuleOut() or similar as it would drop the module directory.
That could lead to the same path being used for multiple rules.
The second approach would not work for files with a different
extension.
The tempPathForRestat combines the two approaches so it can be used
generally with any WritablePath.
Bug: 179354495
Test: verified that the ninja rules that used these files were not
changed by these changes.
Change-Id: I4439dea0a823512c281eeb1366522fb49dceb4e3
This change ensures that bootclasspath_fragment only depends on source
modules and prebuilt_bootclasspath_fragment only depends on prebuilt
modules.
It does that in two ways:
1. It adds the dependencies in ComponentDepsMutator method which is
called before any renaming of prebuilts is done which makes it very
easy to add a dependency directly onto either the source or prebuilt
as required.
2. It uses a tag which prevents dependencies on a source module from
being replaced with a dependency on a prebuilt module which ensures
that a dependency on the source modules is not replaced with a
dependency on a prebuilt module.
Bug: 177892522
Test: m nothing
Change-Id: Ibcfae39083afbc07fcf729ead3ed5f5d020845bf
There is a check in initHiddenAPI that makes sure that if the source
module has been replaced by a prebuilt the prebuilt provides a boot dex
jar. The check was added to try and detect an issue with hidden API
processing early at build time rather than at runtime.
That check relies on the source module having a PrebuiltDepTag
dependency on the prebuilt module that is preferred and will be used by
hidden API processing. That is true for modules that are not in an APEX
but doesn't work for modules that are in an APEX.
The issue is that an APEX variant of a source module depends on the
non-APEX variant of the corresponding prebuilt module. However, that
variant of the prebuilt is not the one that will be used by hidden API
processing; it will use the APEX variant of the prebuilt module which
is the one that has access to the boot dex jar.
That results in the initHiddenAPI check giving a false negative as it
states that the boot dex jar is not available when it may be.
This change simply skips the check is the source module is an APEX
variant. This is a temporary work around as the hidden API processing
is being modularized for each APEX at which point initHiddenAPI will
either be removed entirely or just skipped for APEXes altogether.
Bug: 179354495
Bug: 185828824
Test: m nothing
Change-Id: I2dc3654c9aa476541855b3f0f243a181ddf8d723
Add jni_libs property to java tests and treat it as test data that
should be copied to the lib or lib64 directory in the test directory.
This relands I3a118b933ab30dcd731c6dc2708da9bc63ab5520 with fixes for
the test on mac.
Fixes: 176593487
Test: java_test.go
Change-Id: I2f8c46643cff7a7ae6dc4d4dbad58f0396e45f09
1. Instead of 'slim' config, use full config even for libs
2. Define moduleJSONConfig for fields which cannot be converted to JSON
field directly(Path type field, ProfileBootListing,
DexPreoptImagesDeps are added in this CL) and exclude fields which is
convertible(DexPreoptImageLocations)
Bug: 158843648
Test: m dist
Change-Id: I3f9192ab5292bd079be1b686bb3b25735a836cbc
Add jni_libs property to java tests and treat it as test data that
should be copied to the lib or lib64 directory in the test directory.
Fixes: 176593487
Test: java_test.go
Change-Id: I3a118b933ab30dcd731c6dc2708da9bc63ab5520
metalava is run inside sbox with a modified $PWD, so putting $PWD in
the output message results in an incorrect path. It was also always
incorrect when the output directory was an absolute path. Add a
cd $ANDROID_BUILD_TOP to the command line and use relative paths
instead.
Bug: 185516277
Test: m out/soong/.intermediates/frameworks/base/system-api-stubs-docs-non-updatable/android_common/metalava/api_lint.timestamp with lint error
Change-Id: Iefe133cea4c3a604ecd2b0ea20f4ba14ae13b425
The hidden API processing needs access to dex jars for the API stubs in
order to determine which dex members are part of an API surface. The
dex stubs used for the monolithic file are provided by normal
java_library modules for legacy reasons. However, the APEXes that
contribute to the bootclasspath, and so need to perform hidden API
processing, typically provide stubs created by a java_sdk_library.
This change adds support to java_sdk_library/_import to make the dex
stub jars available when requested, that involves:
1. Adding compile_dex property to java_sdk_library_import and
propagating it down the the java_import modules for the stubs. That
is already handled for java_sdk_library.
2. Propagating the java_sdk_library compile_dex property to the
java_sdk_library_import in the generated snapshot.
3. Refactoring and wiring to make the dex stubs jar available to other
parts of Soong.
Bug: 179354495
Test: m nothing
Change-Id: I5895d4f2ba0b684870862b9429b2364865e4afc6
Aggregates hidden API flag files from the bootclasspath_fragments which
will allow the hidden API flag files in frameworks/base/boot/hiddenapi
to be modularized and moved to the appropriate repo.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
also verified that changes to the fragment provided files do
affect the monolithic files.
Change-Id: Ifce14c9ef24c58c7ab1085475d85b61cfbfefecd
When Soong looks for boot jars among all modules, it applies certain
constraints to each module that looks like a boot jar (e.g. that it
comes from the right apex or platform). Previously these constraints did
not handle boot jars on /system_ext correctly (they were handled like
apex jars, while they should be handled like platform jars).
Bug: 154976937
Test: m nothing (the modified Soong test would fail previously)
Change-Id: I0746a2fd276ab5ef0400340c5b61cf26c2570e5a
Previously, each category of flag file had its own property in the
hiddenAPIAugmentationInfo struct that required a lot of repetition
to use. This change moves the flag file specific handling into a
new hiddenAPIFlagFileCategory struct which allows use of the
hiddenAPIAugmentationInfo struct to be parameterized.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: I4413134c0c9382139bef3813f847e453f426692c
This change moves the monolithic hidden API index file creation rule
from the hiddenAPISingleton into the platform_bootclasspath.
Bug: 179354495
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ib25be3618e30a83dc2929a18062eb58eefdabefb
This change moves the handling of the prebuilt hiddenapi-index.csv file
from the hiddenAPIIndexSingleton and removes that as it no longer
needed.
Bug: 179354495
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Iab1b39a57f28caa855c48538aa2230795f2c3271
This change moves the monolithic hidden API index file creation rule
from the hiddenAPIIndexSingleton into the platform_bootclasspath. It
also moves the corresponding test from java/hiddenapi_singleton_test.go
to java/platform_bootclasspath_test.go.
Bug: 179354495
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ia295d0f7ae9b51ea816f16921aa42339ed91704e
Instead of embedding "raw" values from PRODUCT_*_CLASSPATH variables
into /etc/classpath, encode them into classpaths.proto binary format.
Existing platform_bootclasspath{} module is used to generate the whole
monolithic config to begin with. Later, the config will be split
among individual bootclasspath_fragment and
systemserverclasspath_fragment modules.
Bug: 180105615
Test: m && launch_cvd
Change-Id: Ia66f521f8976ff78a62ecf91131d26db21064de7
Checks to make sure that every module that is part of the platform
bootclasspath has been initialized property for hidden API processing.
Bug: 177892522
Test: verified that the out/soong/hiddenapi/... files are unchanged
by this change
Change-Id: Ic4368963f2011784b537b8aebf5ef97ea22b2db5
As part of the work to modularize the hiddenAPI processing the
generation of the monolithic hidden API index file needs to be moved
to the platform_bootclasspath module type. Doing that broke the
TestBootDexJarsFromSourcesAndPrebuilts tests which checks the inputs to
the rule that creates that file. Fixing that required added a
platform_bootclasspath module to the test fixture for those tests which
highlighted an issue with the prebuilt_apex module.
Previously, when the prebuilt_apex created apex variants it would use
its own name as the apex variant name, even when that name included the
prebuilt_ prefix. That broke the platform_bootclasspath logic as it was
looking for apex variants for "myapex" but the only ones available were
"prebuilt_myapex".
This change ensures that it always uses the unprefixed name and fixes
the TestNoUpdatableJarsInBootImage to match. This also adds some
improved error reporting in platform_bootclasspath which helped debug
this problem.
Bug: 177892522
Test: m nothing
Change-Id: I3e88b5cec767f77dcc0e94b3ae38b499d07eadf0
incompatibilities.txt doesn't exist anymore, only
"<module>-incompatibilities.txt". Clean up the associated logic that
mapped incompatibilities.txt to android-incompatibilities.txt.
Bug: 178171189
Test: m
Change-Id: I61eeb5dcc82770fa2af356bad11b7205551d6d83
We are enabling NewApi lint check where the min sdk != compile sdk.
At the same time, we are introducing baseline files for existing
projects that fail this check in order to keep the build running.
At the very least we stop introducing new problems and teams might
realise of risks in their projects they were not aware of.
Bug: 150847901
Test: m lint-check
Change-Id: Icfa5eb98cc6b6708149f0c52fac8fc1440d9c3b0
Merged-In: Icfa5eb98cc6b6708149f0c52fac8fc1440d9c3b0
Boot jars, updatable boot jars and art apex jars are part of two
separate but related configuration objects, the main Config struct
(actually the nested productVariables struct) and the dexpreopt
specific GlobalConfig. The fields in both are initialized from the same
data in the make config files but handled separately.
Previously each test that used one of the configuration objects would
generally just initialize the one it used. That would make the test
sensitive to the specific configuration object that was used. A
refactoring that change the code from using one configuration object to
the other would cause the test to fail.
Also, some tests would inadvertently create invalid configurations by
setting ArtApexJars without also setting BootJars. While the ability to
create invalid configurations is useful (and there are some tests that
exist to verify the behavior in that case) most tests should not be
using them.
This change simplifies the configuration of the tests and improves
their realism by:
1. Providing a new FixtureConfigureBootJars method that takes a set of
boot jars and sets ArtApexJars, and BootJars in the
dexpreopt.GlobalConfig and BootJars in the product variables too.
2. Providing a new FixtureConfigureUpdatableBootJars method that takes
a set of boot jars and sets UpdatableBootJars in both the
dexpreopt.GlobalConfig and productVariables.
3. Migrating existing tests to use these new methods.
Some tests still use the dexpreopt.FixtureSet...Jars() methods directly,
generally to create invalid configurations.
Bug: 177892522
Test: m nothing
Change-Id: I4d8f0b9762cfcc7ae6383bef08563d7c3fa13955
Previously attempting to use m UNSAFE_DISABLE_HIDDENAPI_FLAGS would
cause a build failure.
It is necessary when UNSAFE_DISABLE_HIDDENAPI_FLAGS=true to create
empty files for the monolithic files so that those usages which are not
protected by the build flag, e.g. in dists or CTS tests like
CtsHiddenApiBlocklistTestApiTestCases do not cause ninja failures due
to reliance on a file that does not exist and has no rule to create it.
Bug: 177892522
Test: m nothing
m UNSAFE_DISABLE_HIDDENAPI_FLAGS=true CtsHiddenApiBlocklistTestApiTestCases
Change-Id: I05d0b3680dbc0b5b7c7c0d792550faf848829647
Change https://r.android.com/1673266 introduced some code that does
nothing. This change removes that.
Bug: 177892522
Test: m nothing
Change-Id: I349b17c7fe7e2f68a807dab43a4300da7fe0ad4d
Paul Duffin