- Adds all required details for bootclasspath_fragment to implement
classpath_fragment.
- Keeps the actual boot jars in platform-bootclasspath to begin with.
- Makes sure to put the file in apex/etc/classpath on device. Note that
for platform versions of classpath fragment AndroidMkEntries perform
the installation, while for APEXes it must be plumbed via apex.go.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I6101ebdf5b8bcbe95c0b7ce21f3f67a2685aef50
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
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
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
Adds the AlwaysRequireApexVariantTag interface to enable
ApexInfoMutator to differentiate between a tag that is excluded from
apex contents but still requires an apex variant and a tag that is
excluded from apex contents and does not require an apex variant.
That is needed to support the sdkMemberVersionedDepTag which excludes
the target from being added to the APEX but requires an APEX variant.
A more detailed explanation is in the comments.
The AlwaysRequireApexVariant() method follows the pattern used in
ReplaceSourceWithPrebuilt of having a method that returns a bool to
trigger the behavior and not say ExcludeFromApexContentsTag that simply
relies on the tag implementing an interface to trigger. That is because
the former is more flexible and allows a tag type to parameterize the
behavior if necessary.
The tags that this will exclude from creating an apex variant are:
* PrebuiltDepTag - by the time the apex variant has been created any
preferred prebuilts will have replaced the sources so there is no
need to create an APEX variant if the only dependency path from the
APEX to the prebuilt is via this tag.
* hiddenApiAnnotationsDependencyTag - the target of which is a purely
build time artifect and MUST NEVER end up in the APEX.
It will also stop calling DepIsInSameApex for any dependency created
by the sdkMemberVersionedDepTag. Which will fix the issue reported in
the bug.
Bug: 182992071
Test: m nothing
Change-Id: I9569e488d6446ca45d3ea8f32a9b74524eb865df
It just provides the metadata needed by the global singleton as the
rest is in the apex.
Bug: 182402754
Test: m nothing
Change-Id: I511df7a3a06dab13ddb9ad63392ae5310dfee9c4
An upcoming change to create a prebuilt_platform_compat_config module
will break if the apex tries to use it instead of a
platform_compat_config because the former does not provide all the
information that the apex needs. This change will allow the
compatConfigsTag to be configured to prevent the prebuilt from being
used even when it is preferred.
Bug: 182402754
Test: m nothing
Change-Id: Ib9dc06c038f7cf3fc229f3c4d2b025335a4715b4
While debugging an issue with some work I was doing on boot image
modules I noticed that markPlatformAvailability() is calling
DepIsInSameApex() even when the dependency tag indicates that it is
excluded from the apex contents.
Test: m droid
Change-Id: Iac49049546a886f7a3a0d9640ffd31ce24c61364
1) suggest a fix at the end of the message
2) add new lines around the dependency path so that they are visually
separated from rest of the error message
Bug: N/A
Test: m with an intentional break
error: bionic/apex/Android.bp:32:1: module "com.android.runtime" variant "android_common_com.android.runtime_image": "libutils_headers" requires "libsystem_headers" that doesn't list the APEX under 'apex_available'.
Dependency path:
via tag apex.dependencyTag: { name:executable payload:true}
-> crash_dump{os:android,image:,arch:arm_armv8-a,sdk:,apex:apex10000}
via tag cc.libraryDependencyTag: { Kind:staticLibraryDependency Order:normalLibraryDependency wholeStatic:false reexportFlags:false explicitlyVersioned:false dataLib:false ndk:false staticUnwinder:false makeSuffix: skipApexAllowedDependenciesCheck:false excludeInApex:false}
-> libtombstoned_client_static{os:android,image:,arch:arm_armv8-a,sdk:,link:static,apex:apex10000}
via tag cc.libraryDependencyTag: { Kind:staticLibraryDependency Order:normalLibraryDependency wholeStatic:true reexportFlags:true explicitlyVersioned:false dataLib:false ndk:false staticUnwinder:false makeSuffix: skipApexAllowedDependenciesCheck:false excludeInApex:false}
-> libcutils{os:android,image:,arch:arm_armv8-a,sdk:,link:static,asan:,apex:apex10000}
via tag cc.libraryDependencyTag: { Kind:headerLibraryDependency Order:normalLibraryDependency wholeStatic:false reexportFlags:false explicitlyVersioned:false dataLib:false ndk:false staticUnwinder:false makeSuffix: skipApexAllowedDependenciesCheck:false excludeInApex:false}
-> libutils_headers{os:android,image:,arch:arm_armv8-a,sdk:,asan:,apex:apex10000}
via tag cc.libraryDependencyTag: { Kind:headerLibraryDependency Order:normalLibraryDependency wholeStatic:false reexportFlags:true explicitlyVersioned:false dataLib:false ndk:false staticUnwinder:false makeSuffix: skipApexAllowedDependenciesCheck:false excludeInApex:false}
-> libsystem_headers{os:android,image:,arch:arm_armv8-a,sdk:,asan:,apex:apex10000}
Consider adding "com.android.runtime" to 'apex_available' property of "libsystem_headers"
Change-Id: I09f92c3086ea433780133a33ba0ad73baee6dc41
Originally, when the prebuilt_apex was first created, it selected the
source to use in its DepsMutator. It did that because that was a
convenient place for it to perform that work which had to be:
* After the arch mutator had run so MultiTargets() was available.
* Before the prebuilt_select mutator runs as that relied on the Source
property to have been set.
Change 064b70c9 then duplicated the call from the DepsMutator of the
deapexer module type that was added as part of the work to make dex
files available for hiddenapi processing.
Change 356f7d45 moved it out of the the DepsMutator methods into its
their own mutators, presumably because it interfered with the
Soong -> Bazel conversion work.
This change improves the existing PrebuiltSrcsSupplier mechanism to
support reporting errors so that the logic for selecting the source can
be done on demand rather than in separate mutators.
The main complication was that PrebuiltSrcsSupplier is called with a
BaseModuleContext for both source and prebuilt modules so it cannot use
any methods on it that are related to the current module. That
necessitated adding MultiTargets() to android.Module.
Bug: 181267622
Test: m droid
Change-Id: I106c78fd21016f051a315b82b470d8f12b1f820b
Some filesystems (like boot_image type) are arch-specific. This change
allows us to have filesystems property inside the arch.<arch> struct.
Bug: 178978059
Test: m
Change-Id: I09faa6186b4a3fa35f348fc0805d894b4dc27ffd
This currently expands all globs, still need to support converting glob
syntax.
Test: go build_conversion_test
Test: GENERATE_BAZEL_FILES=true m nothing
Test: m nothing
Bug: 165114590
Change-Id: If7b26e8e663d17566fad9614ca87a8da1f095284
Previously, the apex module had to hard code behavior specific to the
art apex module in order to include the art boot image. This change
adds support to the apex module to allow the boot images to be
specified per apex.
In combination with a change to add the "art-boot-image" to the ART
apex this allows the custom code for handling the art boot image in
apex to be removed.
That custom apex code also included the logic to ensure that the
GlobalSoongConfig was initialized for use by the dex_bootjars
singleton. That logic has been moved from the APEX to the boot_image
module. That ensures that it will be run if and only if a boot_image
module is present in the checked out repos. So, limited manifest
checkouts which do not contain the art or frameworks/base repos (which
is where the boot_image modules are defined) will not attempt to run
this logic, which would fail because dex2oat would not be present.
Bug: 177892522
Test: m droid
Change-Id: I02d25fbef6e864e31eb5e0f4eb50358c79486db0
If we don't check "current", it won't be checked even in the finalized
branch.
If we don't check "preview", it should be done during the SDK
finalization. It'd be better done before the SDK finalization regarding
that setting min_sdk_version is to get approval from deps library owners.
Bug: 177833148
Test: m (soong tests)
Change-Id: I712b61cfe5a134fbb69c73956d26fb3a1e5c011e
