Previously, deapexer modules were created by the LoadHook which meant
that the deapexer module could not use any information derived from the
dependencies of the prebuilt_apex/apex_set modules. This change moves
the creation into a separate mutator that runs after
ComponentDepsMutator and before DepsMutator. That means that a follow
up change can use information from dependencies added by the former
mutator in order to create the deapexer module and the deapexer module
can itself add dependencies onto other modules.
This change also dedups the logic to determine whether a deapexer
module is needed by pushing it down into the createDeapexerModule
method which was renamed to createDeapexerModuleIfNeeded to reflect its
conditional nature.
Bug: 187266082
Test: m nothing
m SOONG_CONFIG_art_module_source_build=false nothing
Change-Id: I65316473ff1e4b2827ff48ab5a870a8ce5c0475a
Should manually cut dependencies instead. Previously, this was used to
take advantage of the limited dependencies of variant libs in some APEXes.
Fixes: 175318864
Test: m nothing
Change-Id: Id559fd1bea5c8b8696cf7ab8acc711a7c3844d14
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
The apexBundle.GenerateAndroidBuildActions is 400+ lines long which
makes it difficult to understand what is happening.
Bug: 177892522
Test: m com.android.art
- verify that this change does not change its contents
Change-Id: I07cb31d246377869771bdb18fdc6291365adf399
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
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 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
ApexInfo is not part of the properties struct. It can handle structs
having private fields.
Bug: 1663140
Test: m
Change-Id: Ib07d4410f0ce187c9de347da34b84b814b2eb537
Previously, SdkSpec was constructed only from the user string. It didn't
make use of the Config struct where information about the latest stable
SDK version, etc. is recorded. As a result, the build system couldn't
check if the sdk version "current" is referring to the in-development
(i.e. not-yet-frozen) SDK version or the latest stable version.
"current" was always assumed to be in-development (IsPreview() returns
true) even when Platform_sdk_final == true.
As the first step for fixing that, this change requires
android.EarlyModuleContext to be passed when constructing SdkSpec from
the user string.
In the following changes, "current" will be mapped to either
FutureApiLevel (10000) or one of the FinalApiLevels() depending on
whether the platform SDK was finalized or not.
Bug: 175678607
Test: m
Change-Id: Ifea12ebf147ecccf12e7266dd382819806571543
This change fixes a bug that shared lib dependencies of an rlib is not
installed to the APEX even when the rlib is part of the APEX.
Bug: N/A
Test: m
Change-Id: I88fe461584499839d8018d6b4292374592e7562b
Previously, SdkSpec was constructed only from the user string. It didn't
make use of the Config struct where information about the latest stable
SDK version, etc. is recorded. As a result, the build system couldn't
check if the sdk version "current" is referring to the in-development
(i.e. not-yet-frozen) SDK version or the latest stable version.
"current" was always assumed to be in-development (IsPreview() returns
true) even when Platform_sdk_final == true.
As the first step for fixing that, this change requires
android.EarlyModuleContext to be passed when constructing SdkSpec from
the user string.
In the following changes, "current" will be mapped to either
FutureApiLevel (10000) or one of the FinalApiLevels() depending on
whether the platform SDK was finalized or not.
Bug: 175678607
Test: m
Change-Id: Ifea12ebf147ecccf12e7266dd382819806571543
When `test_for` dependencies are added from libraries to APEX modules,
they can be created from the platform variants of the libraries, since
those are used for building tests. Hence we need an alias from the
platform variant of the APEX module to have a target for those
dependencies.
This is only necessary for libraries that are split by the APEX
mutator, i.e. is a member of some APEX. Normally that's not the case
for test libraries, but there may be exceptions (read
com.android.art.testing).
This relands https://r.android.com/1654679 after decoupling it from the
topic that caused b/184239856.
Test: m nothing
Bug: 183882457
Change-Id: If643c75ce9bc25fa01ad9d1e3ba8e1d060d03bb2
Remove Android-targeting gcc toolchain libraries -- libgcc,
libgcc_stripped, libatomic, and libgcov. Also remove libunwind_llvm,
which is replaced with a libunwind toolchain prebuilt.
The __atomic_* library functions are now part of the compiler-rt
builtins library:
https://android-review.googlesource.com/c/toolchain/llvm_android/+/1625025
Bug: http://b/153025717
Test: treehugger
Change-Id: I971d0a4a49f1aaeb3546e80b6d94208277a171ac
Revert submission 1658000
Reason for revert: Breaks full-eng build: b/184239856
Reverted Changes:
I4f8ead785:Avoid internal APEX stubs for libsigchain and clea...
I68affdf69:Allow dependencies from platform variants to APEX ...
I54b33784e:Rename libdexfile_external_static to libdexfile_st...
Id68ae9438:libdexfile_external is being replaced by libdexfil...
I12ac84eb4:libdexfile_external is replaced by libdexfile.
If05dbffc8:Rename libdexfile_external_static to libdexfile_st...
Ia011fa3a8:Merge libdexfile_external into libdexfile.
Change-Id: If494dc5385042a4620a76a9eadc1613ae0eb1655
When `test_for` dependencies are added from libraries to APEX modules,
they can be created from the platform variants of the libraries, since
those are used for building tests. Hence we need an alias from the
platform variant of the APEX module to have a target for those
dependencies.
This is only necessary for libraries that are split by the APEX
mutator, i.e. is a member of some APEX. Normally that's not the case
for test libraries, but there may be exceptions (read
com.android.art.testing).
Test: m nothing
Bug: 183882457
Change-Id: I68affdf69d7ec05c0ee8730e8ec04d7cb9e0e44a
This avoids having to specify boot libraries in both the boot_image
and separately as java_libs on the apex. Simply add them to the
boot_image (happens automatically ATM when using image_name: "art")
and add the boot_image to the apex.
Bug: 177892522
Test: m nothing
Change-Id: I7e0c41665604b73780cdf0dc555067497b1e6ef0
This is part of the work to rename boot_image to bootclasspath_fragment
which is being done for two reasons:
1. To avoid clashing with the bootimg module type.
2. To better reflect what this represents.
While a bootclasspath_fragment can create what ART calls a boot image
(which is different to what the bootimg module type represents) it does
not have to do so.
Bug: 177892522
Test: m nothing
Change-Id: Ib45604be7adc790ded9e27a2ac812dd7522ca8db
Creates a new deptag type for it so that it can implement the marker
interfaces that will exclude it from being added to the APEX and from
visibility enforcement. The latter is probably not an issue ATM because
the dependencies are added after visibility checks are enforced but
this code is undergoing lots of refactoring so that may change.
Bug: 177892522
Test: m nothing
Change-Id: Ibd167d557adec761a2e3eed78f4d334c40a04fb9
The ExcludeFromApexContentsTag marker interface was added to avoid
every implementation of DepIsInSameApex() from having to deal with the
special tags, like PrebuiltDepTag. Unfortunately, when adding that
not all calls to DepIsInSameApex() were protected which meant that the
BootImageModule, which panics if it doesn't recognize a tag, was
causing failures. This change documents the need and improves the
consistency.
A follow up change will add a test for this.
Bug: 182992071
Test: m nothing
Change-Id: If0bf9a7447ebf7a0bb0c88e91951a7220d4af45c
