Revert submission 1733232-roboleaf-apex
Reason for revert: b/192523357 Broken build 7512065 on aosp-master on sdk_x86_64-sdk
Reverted Changes:
Ie82c263f6:Add a stub rule for building APEX bundles.
I93e2a25fa:Add partial bp2build support for APEX targets.
Change-Id: I8e836fe7f466e02f3108680f9653412299e929e0
Add an apex_name property to prebuilt APEX modules to allow specifying
the "runtime" name of the APEX, i.e. the one it gets mounted as in /apex/,
which is also the one used for the apex variations.
Introduce a callback to retrieve that name consistently for all APEX
modules (apex, override_apex, prebuilt_apex, and apex_set), and update
some apex mutator code paths to use it.
For APEX source modules (apex and override_apex), it's necessary to add
a new field in apexBundle, since the name property gets overridden for
the override variant that override_apex creates.
Test: m nothing
Bug: 191269918
Change-Id: If8612639bffdf91cbcab3387b0603bf5dffef1f5
The property is used to allow non-updatable APEXes to use platform APIs
(e.g. symbols marked as "# platform-only").
Bug: 191637950
Test: m com.android.virt com.android.compos
Merged-In: Id2410b4e38a78ec2146a42298840954381a7c472
Change-Id: Id2410b4e38a78ec2146a42298840954381a7c472
(cherry picked from commit fb63625a7f)
This must always be true for updatable apexes, but is not necessary
for non-updatable apexes like com.android.i18n.
In a follow up this will be used to figure out whether apex boot jars
should be bundled into platform_bootclasspath.
Bug: 191127295
Test: atest CtsClasspathsTestCases derive_classpath_test
Change-Id: Ib7dc5b057cb24955222fb97f3ff9da079f30ed77
Previously, the prebuilt_apex/apex_set did not have an apex specific
variant created which meant that they depended upon the platform
variant of the modules it depended upon. This change creates an
apex variant for them just as is done for the apex module type which
causes it to depend upon the apex specific variant of the modules it
depends upon.
Test: m droid
Bug: 179354495
Change-Id: I7d6f3609c267b3e90b90b9befe7d76f351a0c2bd
Add apex dependencies.
Bug: 188004865
Test: 1. aidegen frameworks/base/apex/appsearch frameworks/base/apex/appsearch/testing frameworks/base/services/tests/servicestests frameworks/base/core/tests/coretests cts/tests/appsearch external/icing vendor/google_testing/integration/tests/scenarios
2. The dependency graph shows it is workable to provide the result to let IDE's [Project structure] to include the service-appsearch as source directory.
Change-Id: Ifd1548f0a86c1c73f8279e8ecea67756aeb1281e
In order not to introduce any changes in the system image default value
of generate_hashtree is currently set to false. Once all the APEXes that
shouldn't have hashtree enable (i.e. non-updatable ones) explicitly set
`generate_hashtree: false` default value will be switched to true.
Test: checked that are no diffs between ${OUT}/system/apex without this
change and with this change.
Test: m
Bug: 190621617
Change-Id: I5a3144f8f6ea7dee25678af43e2b07a8c85daa9e
Merged-In: I5a3144f8f6ea7dee25678af43e2b07a8c85daa9e
(cherry picked from commit da6dc31389)
make.
Avoids TARGET_FLATTEN_APEX lying about it, so we can trust it in
scripts, e.g. in art/build/apex/runtests.sh.
Test: banchan com.android.art; art/build/apex/runtests.sh
Bug: 179900989
Change-Id: I5361957c448e61634689968424450420479f6111
This happens when com.android.art.host is not disabled in
prebuilts/build-tools/build-prebuilts.sh.
Test: m nothing
Test: env OUT_DIR=out prebuilts/build-tools/build-prebuilts.sh
on the aosp-build-tools branch
Bug: 188922057
Change-Id: Ib21d17bb627e4cf7faee320febe65e1bb4566d4e
Previously, the DexBootJarPathForContentModule(module) simply called
directly through to the module to retrieve the dex jar path. This
change changes it so the bootclasspath_fragment retrieves the dex
jars from the module and stores them in the info structure for this
method to retrieve directly.
This makes it easier for the bootclasspath_fragment to stop retrieving
hidden API encoded dex jars from the module and perform the encoding
itself.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
Change-Id: Ic79dea080f10f4017f1a75d6d1fb5a3bfe04c2ce
Consider this case:
apex {
name: "com.android.foo",
native_libs: ["foo"],
}
override_apex {
name: "com.mycompany.android.foo",
base: "com.android.foo",
}
cc_library {
name: "foo",
}
There are two APEXes defined: "com.android.foo" and
"com.mycompany.android.foo" which is a copy of "com.android.foo" with
some properties overridden (e.g. signing keys).
The module "foo" is mutated into two variants by the apex mutator: the
platform variant and the apex variant. The former has the variation name
"" and the later has "apex<min_api_ver>" which usually is "apex10000".
Internally, the apex variant has an alias "com.android.foo".
ApexInfo.InApexVariants() returns only "com.android.foo" when called for
the module "foo".
We can see that the information that "foo" is also part of
"com.mycompany.android.foo" is completely lost. This is causing problem
when we compare the apex membership by their "soong module name", not
the "apex name". In the example above, the two modules have different
soone module names, but have the same apex name: "com.android.foo".
To fix that, this CL introduces a new field `InApexes` to the `ApexInfo`
struct. It has the actual name of the APEXes that the module is part of.
With the example above, `InApexes` is ["com.android.foo",
"com.mycompany.android.foo"].
Bug: 180325915
Test: m nothing
Test: m nothing on non-AOSP targets with ag/13740887 applied.
Change-Id: I4e7a7ac5495d2e622ba92a4358ed967e066c6c2e
.. 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
- All contents of the fragment are added as java_lib dependencies.
- Generated classpaths.proto is added into etc as required.
Bug: 180105615
Test: m nothing
Change-Id: I8e8e8b019c4ca2909182f205a47deffa946de6da
The new info struct can be easily shared with systemserverclasspath
fragments.
Bug: 180105615
Test: m nothing
Change-Id: I9986e64fdf19f4168da63c156de3dc9bcafac8d8
The destination path, i.e. the path the file will occupy in the APEX is
more stable and less likely to change than the source path, i.e. the
path of the file in the out or source directories. This makes it easier
to diff changes in the copy commands.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that this does not change the contents of the apex files
- verify that this does change the order of copy_commands for the above apexes
Change-Id: Ia9ebe8418c59903cd738ee0fb9262b3f32a4ddbf
Refactors the vendor snapshot support to use the LinkableInterface
so that support can be extended to Rust. This CL does not add
vendor snapshot support for Rust; that is left for a follow-on CL.
Bug: 184042776
Test: m nothing
Change-Id: Id0c4970ca00053484a52677d182153cbc454c301
This will allow the apexMutator to use the NotAvailableForPlatform()
method initialized by the markPlatformAvailability mutator to help
determine whether to create a platform variant or not.
Bug: 187910671
Test: m droid
Change-Id: I745b4428afc68e7ca4cd2f4cbe810b8df1eebdb7
- 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
