Moves common properties, fields and method into the prebuiltCommon
type.
One slight change is that this change causes the Prebuilt module to use
the outputApex when generating the AndroidMkEntries instead of the
inputApex that it used before. They are the exact same files as the
inputApex is simply copied to the outputApex. The only impact will be
on build time as some rules now depend on the cp rule being run when
they did not before and the base name of the file may be different.
Test: m droid
- check generated out/soong/Android...mk file before and after
to make sure the only difference is due to switching from the
inputApex to outputApex.
Bug: 179354495
Change-Id: I8437af00d6bb7d0d339f25b3b02cd1cf67d6938a
Previously, copyBootJarsToPredefinedLocations relied on all its
parameters having the same length and the same order. That made it
quite fragile as changes to one of the parameters without corresponding
changes to the other would cause failures. It also combined the
retrieval of the boot dex jars from the modules, handling of missing
boot dex jar files and the generation of the rules to copy the files.
This change separates the retrieval of boot dex jars and handling of
missing files from the copying of those files while at the same time
making the function less fragile by replacing the three ordered
parameters with two maps that shared common keys.
Bug: 179354495
Test: m nothing
Change-Id: Idbcd24a7e8af89f7895a20aeddc58502dcbaad03
Move the bootclasspath_fragment to be part of an apex to match how they
are expected to be used. Also adds the bar library to the boot jars
config as every module in a bootclasspath_fragment that is referenced
from a platform_bootclasspath module is expected to be in the config.
Bug: 179354495
Test: m nothing
Change-Id: I6f826dce9c006d630ee31d4171fe6fb458cc9442
This test checks that fragments which are referenced from a
platform_bootclasspath module contribute their hidden API flags to those
used by platform_bootclasspath module. Previously, it was unrealistic
because the bootclasspath_fragment does not belong in an APEX.
This change moves the test from the java package to the apex package to
allow it to be modified to make the bootclasspath_fragment part of an
apex.
Bug: 179354495
Test: m nothing
Change-Id: Icb57f2e1eaea4b14aab5f47f3af7d05ea0555816
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
Coverage is applied to java libraries that are directly in an apex.
Mark java libraries that are in an apex through a bootclasspath_fragment
or a systemserverclasspath_fragment as directly in the apex by
implementing CopyDirectlyInAnyApexTag on the dependency tags used for
their contents.
Bug: 183759446
Test: TestApexJavaCoverage
Change-Id: I0116f5f415083b5194000988cb257454ef115200
Merged-In: I0116f5f415083b5194000988cb257454ef115200
(cherry picked from commit c33e5216f1)
We have versions of the same apex targetting different min_sdk_versions;
however, fingerprint is overriding the hardcoded min_sdk_version. We
should only be overriding if it is current or unset.
Test: go test apex soong tests
Change-Id: Id030a5ba7d8edebb806ce83d318132fd839a00a5
* changes:
Treat java libraries in classpath fragments as directly in apex
Make CopyDirectlyInAnyApex match the documentation
Remove unused cc.copyDirectlyInAnyApexDependencyTag
Coverage is applied to java libraries that are directly in an apex.
Mark java libraries that are in an apex through a bootclasspath_fragment
or a systemserverclasspath_fragment as directly in the apex by
implementing CopyDirectlyInAnyApexTag on the dependency tags used for
their contents.
Bug: 183759446
Test: TestApexJavaCoverage
Change-Id: I0116f5f415083b5194000988cb257454ef115200
Neither InApexVariants nor InApexModules should have them. This allows
us to get rid of InApexVariantByBaseName as well.
Test: m nothing
Test: m nothing SOONG_CONFIG_art_module_source_build=false
Bug: 180325915
Change-Id: Icbe4e025ce1a4c8dd258ff95d326ca2f27905188
Previously, the generation of the rules to create the boot image files
was separate from the code to provide those files to the APEX which
meant that it was possible for the APEX to try and use files that had
no rules to create them.
This changes avoids that by only exporting the files once the rules
have been created.
This necessitated a few changes to tests that were relying on the
previous behavior. Including removing completely the test that used an
image_name: "boot" as that is no longer a valid configuration name as
its functionality has been replaced by platform_bootclasspath.
A follow up change will make the validation of the properties of
bootclasspath_fragment stricter to prevent "boot" being used as the
image_name.
Bug: 177892522
Bug: 188680624
Test: lunch qemu_trusty_arm64-userdebug
m droid dist
- verify that before this change it fails and after this change
it works.
m com.android.art
- verify that this change does not change the APEX contents with
either qemu_trusty_arm64-userdebug or aosp_arm64-userdebug
Merged-In: I0497a151eb0731cbe6a1a7e7bbbb1e4dda75898f
Change-Id: I0497a151eb0731cbe6a1a7e7bbbb1e4dda75898f
(cherry picked from commit 58e0e769c9)
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
Previously, a bootclasspath_fragment that depended on classes provided
by another bootclasspath_fragment did not support hidden API processing
as it would not supply information about those dependencies.
This change adds support for that as follows. Each fragment:
1. Exports the transitive sets of stub dex jars for each of the public,
system, test and core_platform APIs (where relevant).
2. Adds dependencies onto its dependent fragments.
3. Retrieves the API stubs dex jars from its dependent fragments and
passes them to the "hiddenapi list" tool which will use them to
resolve dependencies but will not output them to the generated
flags.
Once the flags are generated the existing encoding functionality
encodes the flags into the dex files of the bootclasspath_fragment's
content modules which are then packaged into the apex.
Bug: 179354495
Test: m com.android.sdkext
- verify that this does not change the contents of the apex files
Merged-In: I3e82a6dbb437f1e417e5d7e25aeb212e378603d0
Change-Id: I3e82a6dbb437f1e417e5d7e25aeb212e378603d0
(cherry picked from commit f1b358cb57)
Previously, the generation of the rules to create the boot image files
was separate from the code to provide those files to the APEX which
meant that it was possible for the APEX to try and use files that had
no rules to create them.
This changes avoids that by only exporting the files once the rules
have been created.
This necessitated a few changes to tests that were relying on the
previous behavior. Including removing completely the test that used an
image_name: "boot" as that is no longer a valid configuration name as
its functionality has been replaced by platform_bootclasspath.
A follow up change will make the validation of the properties of
bootclasspath_fragment stricter to prevent "boot" being used as the
image_name.
Bug: 177892522
Bug: 188680624
Test: lunch qemu_trusty_arm64-userdebug
m droid dist
- verify that before this change it fails and after this change
it works.
m com.android.art
- verify that this change does not change the APEX contents with
either qemu_trusty_arm64-userdebug or aosp_arm64-userdebug
Change-Id: I0497a151eb0731cbe6a1a7e7bbbb1e4dda75898f
Previously, a bootclasspath_fragment that depended on classes provided
by another bootclasspath_fragment did not support hidden API processing
as it would not supply information about those dependencies.
This change adds support for that as follows. Each fragment:
1. Exports the transitive sets of stub dex jars for each of the public,
system, test and core_platform APIs (where relevant).
2. Adds dependencies onto its dependent fragments.
3. Retrieves the API stubs dex jars from its dependent fragments and
passes them to the "hiddenapi list" tool which will use them to
resolve dependencies but will not output them to the generated
flags.
Once the flags are generated the existing encoding functionality
encodes the flags into the dex files of the bootclasspath_fragment's
content modules which are then packaged into the apex.
Bug: 179354495
Test: m com.android.sdkext
- verify that this does not change the contents of the apex files
Change-Id: I3e82a6dbb437f1e417e5d7e25aeb212e378603d0
There is no need to leak soong module names.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I04f4e181d2f42b9d71641980a2c7c4e8cbc8e426
Merged-In: I04f4e181d2f42b9d71641980a2c7c4e8cbc8e426
There is no need to leak soong module names.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I04f4e181d2f42b9d71641980a2c7c4e8cbc8e426
Previously, the apex content info was populated with hidden API encoded
dex jars retrieved directly from the java module. This change retrieves
the unencoded dex jars from the java module, encodes them and then
stores the result in the apex content info.
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
Merged-In: Ib1b6eb8b62ac50e03b9e0d07c877ca70bb6f6d25
Change-Id: Ib1b6eb8b62ac50e03b9e0d07c877ca70bb6f6d25
(cherry picked from commit 54c98f5b4a)
Previously, the apex content info was populated with hidden API encoded
dex jars retrieved directly from the java module. This change retrieves
the unencoded dex jars from the java module, encodes them and then
stores the result in the apex content info.
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: Ib1b6eb8b62ac50e03b9e0d07c877ca70bb6f6d25
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
Merged-In: Ic79dea080f10f4017f1a75d6d1fb5a3bfe04c2ce
Change-Id: Ic79dea080f10f4017f1a75d6d1fb5a3bfe04c2ce
(cherry picked from commit 1a8010a241)
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"].
Cherry-picked from https://r.android.com/1710529.
Bug: 180325915
Test: m nothing
Test: m nothing on non-AOSP targets with ag/13740887 applied.
Change-Id: I4e7a7ac5495d2e622ba92a4358ed967e066c6c2e
Merged-In: 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`.
Cherry-picked from https://r.android.com/1710528.
Bug: 180325915
Test: m nothing
Change-Id: I0c73361b452eddb812acd5ebef5dcedaab382436
Merged-In: I0c73361b452eddb812acd5ebef5dcedaab382436
This change adds a test to verify the existing behavior to provide a
baseline against which following changes can be compared.
Bug: 179354495
Test: m nothing
Merged-In: Ib7dadf3e65151f4e925251f7b1a9c099e824ea63
Change-Id: Ib7dadf3e65151f4e925251f7b1a9c099e824ea63
(cherry picked from commit f2fa0b5e8e)
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
