This makes it possible to pass an extensions_dir containing finalized
module APIs to prebuilt_apis. The extension versions are compared to the
api level versions to figure out what the "latest" finalized API is for
each module. This is done using the base_sdk_extension_version, such
that any extension higher than than base_sdk_extension_version is
assumed to be finalized after any of the existing api level versions.
Bug: 220086085
Test: prebuilt_apis_test.go
Test: existing module in prebuilts/sdk
Change-Id: Ib792f84202d436f594ba5e8716c6a187f9cd60dc
After this change, `bootImageConfig.installDirOnDevice` can be set to a
path outside of the APEX, in which case, the boot image will not be
installed in the APEX. Instead, it will be installed to the given path
by Make.
This is a no-op change. Current behavior is not affected.
Bug: 211973309
Test: m nothing
Test: -
1. m com.android.art
2. See the boot image still being installed in the ART APEX.
Test: -
1. Change `installDirOnDevice` of the ART boot image config to
`system/framework`.
2. See the boot image being installed in `/system/framework/<arch>`.
Change-Id: Ib13b17cc9e94dc5754c9b51b04df3307323b8783
Renames to core-public-stubs-system-modules so that it is of the format
core-<sdk-kind>-stubs-system-modules.
Bug: 204189791
Test: m nothing
Change-Id: Iac565c940c2ef92be9cc64c0c6b8102a26afe0dd
When building from source the build uses the java system modules for
the public or module APIs as needed. However, previously when building
from prebuilts it would always use the public API. That difference lead
to build failures when building from prebuilts.
This change makes the selection of java system modules when building
from prebuilts consistent with the selection when building from
sources.
As API levels 30 and 31 (which are the only previous releases to
provide system modules) did not provide separate java system modules
for the module-lib API those levels always use the public APIs.
Bug: 204189791
Test: - before applying these change
m TARGET_BUILD_APPS=framework-connectivity
- build fails with compilation error due to missing module APIs
m sdk dist
cp out/dist/system-modules/module-lib/core-for-system-modules.jar prebuilts/sdk/current/module-lib/core-for-system-modules.jar
- apply these changes
m TARGET_BUILD_APPS=framework-connectivity
- build passes as expected
Change-Id: Id113ff014e7892b1009fbcaad89b1ae23a7c3b79
Previously, the fixture preparer for prebuilt_apis would add a
core-for-system-modules.jar file in every API directory even though
currently they only exist in the public API directories.
This change makes the test environment more realistic by only creating
them for the public API. Rather than hard code that into the test code
(which would duplicate the hard coding in the decodeSdkDep func) this
extracts a function that is used by both. That ensures that any changes
to that func will be reflected in both the test and runtime behavior.
Bug: 204189791
Test: m nothing
Change-Id: I346ac9c0dcf407c61de16b6027663a05821bcf62
Previously, the TestClasspath test cases were only run with the default
setting of Always_use_prebuilt_sdks=false. That meant that some of the
code under test that depended on the setting of that variable was not
tested properly.
This change runs the test cases m with Always_use_prebuilt_sdks=true as
well. Those test cases whose behavior depends on the setting of that
variable are split into two separate test cases, each of which only
runs with the appropriate setting of that variable. All other test
cases are run for both settings of the variable.
That revealed a slight issue with the test setup (a missing
prebuilts/sdk/public/core/android.jar file) which broke the
core_current test when run with Always_use_prebuilt_sdks=true which has
also been fixed.
Bug: 204189791
Test: m nothing
Change-Id: If2ea3fde40c7573262e93691af0b5a57e4d54469
The annotations zip file is produced by the "main" sdk build and is
primarily consumed by android studio.
In order to support building the main SDK without requiring the sources
of all modules, we are adding module SDK artifacts that allows
reconstructing these outputs. The annotations zip contains XML files
which should be fairly easy to merge from all the individual parts.
Bug: 187397779
Test: unit tests in this CL
Test: m sdkextensions-sdk and inspect output
Change-Id: I955cae720e6f1382936836ee1d8fb11003f51b7d
Adds a test case to TestJavaStableSdkVersion for the case where a
module uses sdk_version: "core_platform" but is in the list of modules
that can use the legacy version.
This required storing the lookup map in the Config to allow it to be
customized for the test.
Bug: 180399951
Test: m nothing
Change-Id: I404705c3fd8a559649c6ab2624856cf78f49f85c
This reverts commit 92346c4832.
Reason for revert: Fixed build error.
The build error is fixed by ag/15841934. This CL remains unchanged. This
CL will be submitted AFTER ag/15841934 is submitted.
Bug: 200024131
Test: 1. Patch this CL and ag/15841934 into internal master.
2. sudo vendor/google/build/build_test.bash
Change-Id: I5f2b8357846fc7dda56e25ebe6ffb095e8047ec8
The path to the artifacts will in the form of
/system/framework/oat/<arch>/<encoded-jar-path>@classes.{odex,vdex,art},
where <encoded-jar-path> is the path to the jar file with "/" replaced
by "@". For example,
/system/framework/oat/x86_64/apex@com.android.art@javalib@service-art.jar@classes.odex
There will be a follow-up CL to update ART runtime to recognize
artifacts in that path.
Test: m com.android.art
Bug: 194150908
Change-Id: Ic89fd63c4b1cd565684cead83fc91dae3bc97a4c
Note that ART apex boot jars and core-icu4j are exceptions here as they
are not part of ApexBootJars. ART apex boot jars are defined in their
own variable, while core-icu4j is treated as a regular non-updatable
boot jar.
Bug: 191127295
Test: atest CtsClasspathsTestCases
Change-Id: I3cea3d82ef521655a1a5ffa8cae2258ab9d08bfc
Before this fix, compiling a java_library against sdk_version:
"module_current" can't use the @SystemApi(MODULE_LIBRARIES) provided
by the ART module because the system module "core-current-stubs-system-modules"
contains only the public APIs.
Use the new system module with module lib APIs.
Bug: 183097033
Test: m droid
Change-Id: I274e2710d1ff34e896aa620bfafb4481180c53b5
Any apex classpath fragment that doesn't generate its own classpaths
proto, must still propagate it's boot jars for the platform classpath
fragment to include for complete CLASSPATH variables on device.
Bug: 191127295
Test: atest CtsClasspathsTestCases derive_classpath_test
Change-Id: I93687f69006741fcd66eb6e04891a4b4bbcc3b47
Adds a message parameter and allows leading spaces in the expected file
string to allow them to be nicely indented.
Bug: 177892522
Test: m nothing
Change-Id: I33df26610738c48879fa0b8250dc377dd04bb07d
dependencies.
dexpreopt.RegisterToolDeps runs late after prebuilt dependencies have
been resolved, and there's special code in dex2oatPathFromDep to
resolve the prebuilt from the source module. However, if the source
module is disabled then the dependencies check in validateAndroidModule
will complain, so we need to disable that check in this particular
situation.
Also add a comment to explain why dexpreopt.RegisterToolDeps needs to
run so late.
Test: m nothing
Bug: 145934348
Bug: 172480615
Change-Id: Ibc673303d0336768fa23261a2068e91a08f46a30
.. in preparation for the upcoming change. This change doesn't alter any
behavior.
InApexes is a misleading name. People expects that it has the list of
soong module names of the APEXes that a module is part of. So, for
example, `core-oj` is a part of both `com.android.art` and
`com.google.android.art`. However, in reality, that's not true. The
field has `com.android.art` only. This is because the two APEXes
(android and Google) have the same apex name which is `com.android.art`.
That apex name is used in various places like the `apex_available` and
allows us to keep using the same name regardless of whether the APEX is
overridden or not.
However, this is causing problems in some cases where the exact list of
soong module names is required. The upcoming change will add a new field
to handle the case and the new field actually will get the name
'InApexes'. So, the existing field is renamed to a less misleading name
`InApexVariants`.
Bug: 180325915
Test: m nothing
Change-Id: I0c73361b452eddb812acd5ebef5dcedaab382436
Propagate strict_updatability_linting to transitive dependencies using a
top-down mutator.
Test: lint_test.go
Bug: 182349282
Change-Id: Ifc9e58f1a597e3c7725ee49b4027afb6f42f45cb
Boot jars are different to system server jars at build level, due to
added complexity of dexpreopt. As a logical separation add a new
classpath fragment type and split existing classpaths.proto generation
into relevant pieces.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I88bec09fc920166ffd0092faef980754ddeb6593
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
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
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
Adds the fragments property to the platform_bootclasspath to allow the
fragments that contribute to it to be specified.
Bug: 177892522
Test: m nothing
Change-Id: I14f83d9336f6984442c7315cc86dfdd0a0fd2d20
Adds a FinalDeps mutator to add dependencies from the
platform_bootclasspath to the configured boot jars which can be from
either the platform or any apex. It adds dependencies for every
configured boot jar, whether in ArtApexJars, BootJars or
UpdatableBootJars.
At the moment the dependencies are only used for testing purposes
but following changes will make more use of them.
Bug: 177892522
Test: m nothing
Change-Id: I981305bf45bc20539a3d36987252f490e2b885cc
Initially, this is just a placeholder but functionality will be added
in follow up changes.
Bug: 177892522
Test: m nothing
Change-Id: I890b0d5a117c51a19c9ac5df98c766761d3aa16c
Also, stops exporting methods that are no longer used outside the java
package.
Bug: 181070625
Test: m nothing
Change-Id: I23d35bbc21f82f2dae802aa53badda4c58b41024
This change needed to add some additional files to the registered
files for PrepareForTestWithJavaDefaultModules because otherwise they
would fail when "TestAllowNonExistentPaths = false". Those files were
being added by the TestJavaLintRequiresCustomLintFileToExist (albeit in
some cases in different locations to that required by the default
modules but as the files are needed by the modules defined in
PrepareForTestWithJavaDefaultModules they should be defined in it.
A couple of other places also provided some files so moving them into
PrepareForTestWithJavaDefaultModules caused some conflicts which needed
to be resolved.
Bug: 183184375
Test: m nothing
Change-Id: I76ce9f1673c1c1c4000635b76b8377d582224bf1
Make it easier to test dexpreopt functionality by grouping all the
fixture preparations together.
Bug: 177892522
Test: m nothing
Change-Id: I94f66e3ec82efc4fd791f4fdab678d298565e452
The fixture mechanism makes it easy to refactor by splitting up an
existing preparer into separate ones and then combining them back
together. Unfortunately, that becomes slightly more tricky when
preparers and legacy tests use the same functions to register build
components and define default modules.
This change splits the RegisterRequiredBuildComponentsForTest and
GatherRequiredDepsForTest methods into two methods each, with the
existing method used for legacy tests and calling the new method that
is used for the preparer.
At the moment all the functionality is in the new methods but over
time, as functionality is extracted into separate preparers, the
functionality can also be moved from the method that is common to both
legacy and fixture based tests into the legacy only method.
Bug: 177892522
Test: m nothing
Change-Id: I233a4fe1fb072a00292acc2bb20821ec82a9bd67
It appears as though this is the first pre-singleton type to actually
be registered with the InitRegistrationContext as it failed due to an
uninitialized map, so this change also fixes that.
Bug: 182885307
Test: m nothing
Change-Id: Ibbf6d0db5f3c2fcc89291a16aa5f16b8b5009bd3
Java build components invariably require android build components such
as the arch mutator (to create the common variant) so include them
together.
Bug: 181070625
Test: m nothing
Change-Id: I435b09a34c48c67b890368b37b8da27e8de97c9a
Also, removes the workaround that allowed preparers to override files
added in javaMockFS().
The performance of the java tests was determined by running:
m nothing
rm -fr out/soong/.bootstrap/soong-java/test/
time m nothing
Prior to starting this work that returned:
real 1m30.060s
user 33m3.028s
sys 13m25.413s
Immediately prior to this change that returned:
real 1m2.777s
user 14m14.352s
sys 9m40.745s
After applying this change that returned:
real 0m20.282s
user 3m7.429s
sys 0m43.601s
So, this reduced the real time cost of running the java tests from 90
seconds to 20 seconds.
Bug: 182638834
Test: m nothing
Change-Id: I30490fd40ddb0684a5a4975ce1811bab5dc79e4e
Adds general support for generating a set of prebuilt apis for a set of
releases and modules. Plus some wrappers for common use cases.
This temporarily will delete any existing conflicting files and replace
them so that it can be used in tests without first removing
javaMockFS(). The future update that removes javaMockFS() will also
remove that workaround.
Bug: 182638834
Test: m nothing
Change-Id: If4e2118f2384b9866cf3f85a5afec1e2e4f9ac95
Restructures the java package test setup code to create FixturePreparer
instances for setting up a test fixture and converts some tests to
use it.
The goal with this change is not to switch all the java tests over to
directly using the new model but instead to ensure that the majority of
the java tests run with the new model, to allow existing tests to
easily switch to the new model when needed and to allow dependent
packages to be switched to the new model.
Bug: 181070625
Test: m nothing
Change-Id: I1c9d96ddbc973aaf9733dcd7fa0479f79b0f471f
Invokes hiddenAPIExtractInformation() on the java_sdk_library_import's
dex implementation jar provided by the deapexer (on behalf of
prebuilt_apex) so that hiddenAPI can extract the information it needs,
if anything, from the dex file.
The dex file provided by deapexer has already had the hiddenapi
information encoded into it so it does not need to do that again.
Usually, it would require a classes implementation jar as well in
order to extract information from UnsupportedAppUsage annotations but
that is not available for a java_sdk_library_import. Fortunately, the
modules that are currently affected by this do not contain any such
annotations. This just uses a public api stubs jar instead.
Bug: 181267622
Test: m nothing
Change-Id: I96275e46f8b7fecba88075319e9f2da5ae315c03
A follow up change needs to be able to contribute to the information
the hiddenapi process collates without having a dex file encoded. This
change pushes all the functionality related to information gathering
into the hiddenAPIGenerateCSV() method and then renames it and the
hiddenAPI() method to make it clearer what they do.
Bug: 178361284
Test: m droid
Verified that hiddenapi files (both aggregated ones and for the
individual modules) are not affected by this change.
Change-Id: I04417720216a0fbadcd88e6185e7de6570af6216
Mistakenly used HostAndDeviceDefault (which builds host and device
variants by default) instead of HostAndDeviceSupported which only
builds a device variant by default.
Moved the test definitions of art and framework boot images from being
defined in all Java related tests into the test where they belong. This
is needed in order to improve the ART and framework boot image specific
testing.
Bug: 177892522
Test: m droid
Change-Id: I16771f09bd789033e18c58ae6dd4b6b9e865d831
Adds a boot_image module type. Follow on changes will add instances of
boot_image to represent the ART and framework boot images in the art
and frameworks/base repositories respectively.
For the moment they retrieve their associated boot image configuration
from the map returned by genBootImageConfigs() and leave the actual
work of creating the ninja rules to create the boot images to the
dex_bootjars singleton.
Bug: 177892522
Test: m droid
Change-Id: Ib69701de0d24d996bb8e8be7a20b941be907390e
The main difference between a singleton and a singleton module that
affects this change is that the latter requires a module to be defined
in order for the singleton to be instantiated. This change defines the
module in both the tests and the standard build.
Bug: 177892522
Test: m droid
Change-Id: Id6669835cf3a2ab7359fa53047eb9042992a9362
Insulate tests that exercise code in the java package from having to
register the build components provided by the java package by providing
a single function that registers them all. This follows the pattern
currently used in the cc and rust packages.
This change is in preparation for switching the dex_bootjars singleton
from a singleton, which does not require a module definition in order
to be instantiated, to a singleton module which does. That will require
adding a module definition into java.GatherRequiredDepsForTest() and
this change ensures that the required components will have been
registered in every test.
Bug: 177892522
Test: m nothing
Change-Id: I6475db8240894947dd07c89a940a3e4f201aa598
