| Age | Commit message (Collapse) | Author | 
|---|
|  | 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 92346c483249726164f4bd140413d60391121763.
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 | 
|  | This reverts commit ca9bc98e0cfe9a519cfdd13450a68f1ed7ad5b02.
Reason for revert: breaks build
Bug: 200024131
Change-Id: Ide07b4c4d267370ae31107b1598b2f878c701282 | 
|  | 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 | 
|  | @SystemApi(MODULE_LIBRARIES)
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 | 
|  | * changes:
  Record the actual APEXes that a module is part of.
  Rename InApexes -> InApexVariants | 
|  | 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 | 
|  | Bug: 177892522
Test: m nothing
Change-Id: I54fe0537b758a0e3dacd34b139ef3eb21b8841fd | 
|  | 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 | 
|  | Bug: 182885307
Test: m nothing
Change-Id: I550d39ba46c548b6b099d8dc6a9c458ca931b2fa | 
|  |  | 
|  | 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 | 
|  | Bug: 182402754
Test: m nothing
Change-Id: Ife3f4f64fc116d62eb7c3cc10c50e00f19d1d81c | 
|  | 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 | 
|  | Needed for tests in both java and sdk packages.
Bug: 182638834
Test: m nothing
Change-Id: Ia8c5e7db47d8b63bf8dcf2965b3af60a4d35a9e5 | 
|  | 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 | 
|  |  | 
|  | Bug: 177892522
Test: m nothing
Change-Id: I594bddae692ef76dc8c3da504934d0151b13d4c9 | 
|  | Use ints instead of strings for version comparison.
Bug: 178171189
Test: m
Change-Id: I53d71b138a64b902b3f00adafec5d354630a5e35 | 
|  | 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 | 
|  | Setting this to true by default is dangerous as it can mask bugs. Create
a dedicated attribute for java_sdk_library to enable this behavior
instead. The default will be flipped in a future CL when all the current
offenders have been fixed.
Fix all the tests to have the right API files.
Bug: 176092454
Test: m nothing
Change-Id: Ieab94bcb74abf8d018365a56fb447fe3dbd46957 | 
|  | Also, add tests for compatibility libraries in class loader context.
This CL separates special-case handling of compatibility libraries into
a "fixup" step that is done after class loader context is constructed by
Soong. This allows to handle compatibility libraries and normal
libraries uniformly, which should enable further simplification of class
loader context representation (in subsequent CLs).
Currently the only "fixup" step is removal of libraries from conditional
class loader context if they already are in unconditional context. This
check cannot be done at the time when the libraries are added to
conditional context, because the full uncoditional context is not yet
known at that time. Previously construction of unconditional context was
delayed, now it is no longer delayed and handled in the same way as
unconditional context, and the "fixup" does the filtering.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: Ie71e9fb2d3d529b5317cd84e09ab3c853017c349 | 
|  | Fixes a panic when trying to build something with
sdk_version: "module_30".
Test: m nothing
Change-Id: I9b2ce50957f59e2bead335ffa58888e15cda1f78 | 
|  | Bug: 160455085
Test: build_unbundled_mainline_module.sh (with disabled source-stubs)
Test: hiddenapi_singleton_test.go
Change-Id: Id93c974351b3f8efdf8e4efe4192d3809f4fcaa5 | 
|  |  | 
|  | Test: go java tests
Test: m
Bug: 160455085
Change-Id: Ib6e826e32ca73ceea0799b26145ad06b1e62a1bf |