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
oatdumpd isn't available as a prebuilt.
Test: m SOONG_CONFIG_art_module_source_build=false droid
Bug: 172480615
Change-Id: I70317eb8f253272d629f23063cbe265d556caad3
The intention before was to use relative paths to a partition where a
config is defined. However, jars in /system_ext partition are planned to
be declared in /system's classpaths.proto config.
Bug: 180105615
Test: derive_classpath_test, CtsClasspathsTestCases
Change-Id: Icc3e1a903c34187cfcd67a3ae7bc3dd746445c03
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
* changes:
Add systemserverclasspath_fragments property to apex.
Add "contents" property to systemserverclasspath_fragment.
Move classpaths.proto related info into a separate provider.
- 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
Similar to bcp_fragment's contents, this property lists all java library
contributions made by this fragment.
Bug: 180105615
Test: m nothing
Change-Id: Ifb1f54d5db290fffaa31933d15207014bb72d2fb
The new info struct can be easily shared with systemserverclasspath
fragments.
Bug: 180105615
Test: m nothing
Change-Id: I9986e64fdf19f4168da63c156de3dc9bcafac8d8
This would allow to start introducing these modules for apexes that
contribute to SYSTEMSERVERCLASSPATH.
In follow up, it will be evolved:
- platform_systemserverclasspath would have "fragments" property to
list all individual systemserverclasspath_fragments;
- systemserverclasspath_fragment would have "contents" property to list
contibuting java libs;
- systemserverclasspath_fragment would generate non-empty
classpaths.proto config within individual apexes.
Bug: 180105615
Test: m nothing
Change-Id: Ibaaa3fae5f1eab9a41ceecc1214a53be6bbc8ba6
In order for the bootclasspath_fragment to perform dex encoding on its
contents it needs to know whether the dex file is uncompressed or not.
This change makes that information available by passing it to
initHiddenAPI, storing it in hiddenAPI struct and providing access
through the hiddenAPIModule.
Bug: 179354495
Test: m droid
Change-Id: I913416b4836766de194203fd8ed5124b61dfa3dd
Now that the individual modules no longer participate in the generation
of the monolithic files it is no longer necessary to select a single
primary module to provide the information they need.
Bug: 179354495
Test: m droid
Change-Id: If09796de710927e3e3f2ccecad0b57ca5fce5dc9
These two methods did very similar jobs and merging them together
simplifies the behavior.
Bug: 179354495
Test: m droid
Change-Id: Ibe1a23d54105e6a0e5693079cd8743679301fc85
The configurationName was intended to separate the name of the module
from the name used in configuration (such as BootJars) so that the
child implementation library of a java_sdk_library on the bootclasspath
would have hidden API encoding performed on it just as for the main
java_library embedded within the java_sdk_library.
While that did use to work it no longer does as the test added in the
preceding change proves. It is not surprising that this regression does
not appear to have caused any issues as the the child implementation
library is only a build time artifact and not used at runtime.
In future the only modules that will require hidden API encoding are
those that are part of a bootclasspath module so there is no point in
maintaining this capability.
Bug: 179354495
Test: m droid
Change-Id: Ief8136fa9e98600cdd8d36108ec22edc2ebd7c69
Fill a hole in the testing of hidden API encoding. Some comments in the
code indicate that the child implementation java_library of a
java_sdk_library should have hidden API flags encoded in its dex jar
just like the embedded java_library. However, this test proves that it
is not working. This will be fixed in a follow up change.
Bug: 179354495
Test: m nothing
Change-Id: Ia581a17f1e48dff252d17f16bf76adf039f46b60
Hidden API processing of a bootclasspath_fragment requires the fragment
provides information, such as dependencies on other fragments and flag
files to override the default flags. Failing to do so will cause hidden
API generation to either fail or to generate different flags to that
generated by the hidden API processing done by platform_bootclasspath
which will cause the build to fail.
Previously, this was handled by only performing hidden API processing
for those modules that provide stub libs and relied on there only being
bootclasspath_fragments defined for ART (which already supports hidden
API processing), and Conscrypt and I18n neither of which provide stubs.
Unfortunately, that can no longer be relied upon due to a couple of
recent changes:
1. A java_sdk_library in a bootclasspath_fragment's content property is
automatically treated a stub library. That avoids duplication for
most bootclasspath_fragments that provide the implementation and
stub libraries through the same java_sdk_library. It does not affect
either ART, conscrypt or i18n as they all define the implementation
separately to the stubs.
2. bootclasspath_fragment modules have been defined for a number of
android modules as they are needed for reasons other than hidden API
processing.
In combination this meant that rules to perform hidden API processing
were being created but they were not currently being used which is
good because they fail.
However, adding the fragment to the platform-bootclasspath will cause
those rules to be used as the platform_bootclasspath module performs a
consistency check on the hidden API flags generated by each of the
fragments to ensure that they are consistent with those it generates
itself.
The dynamic bootclasspath work will need to add fragments to the
platform_bootclasspath and without this change that would be blocked
until all fragments had been switched to generating hidden API flags
properly.
This change adds a new fragments property to the bootclasspath and
disables hidden API processing for everything other than ART and tests
if the fragments property or stub libs is empty.
Bug: 179354495
Test: - Before making this change.
- Add com.android.os.statds-bootclasspath-fragment to platform-bootclasspath.fragments
m out/soong/hiddenapi/hiddenapi-flags.csv
- hidden API processing fails in statsd as it cannot find java.lang.Object.
- After making this change, run the above command again and it should pass.
Change-Id: Ifbb362f8fcfb2c06595fbd5ae39421b536e329ef
For running dex2oat on the target_files, the paths should be use the
device install path instead of the path starting with $(OUT).
So add usesTargetFiles option and basePath option which indicates
extracted path. With those options, the path is replaced with
$(basePath)/$(device path)
And also, add DexPreoptImageDeviceLocations in the config which refers
to the boot image path(without arch) on the device. Because
DexPreoptImage related device path was missing.
Bug: 158843648
Test: dexpreopt_gen -usesTargetFiles -basePath (extract path) and then
check if paths in the generated shell script are based on on-device
path.
Change-Id: I9667fadbf3b7c6f770e0d1bcbee5d67c1ecd8a3d
A previous change treated this as an error in order to try and detect
issues with misconfigured java_sdk_library modules and/or
bootclasspath_fragment modules but unfortunately this is not always an
error, e.g. when migrating a library that was a shared library to the
bootclasspath.
This change stops treating that as an error.
Bug: 179354495
Test: m nothing
Change-Id: I4a833ab5f4caf86c6cd340090fc65d2c2f141512
Instead of encoding the hidden API with an empty set of flags when the
monolithic flags are not available this simply disables encoding
altogether which should have the same behavior at runtime.
This change also removes the unused flags field in hiddenAPISingleton
which was set but never read.
Bug: 179354495
Test: m nothing
Change-Id: I32d5825e5271829993dd4e5be4d4ee1b22fa7b22
The rules to extract hidden API information from an individual module
in order to create module specific files are no longer necessary as
the monolithic files are created directly from the module's class jars
and not the module specific files.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I573ac17f3ea5da5a2a7e4f08718160dacca71c0c
Previously, the monolithic hidden API files, e.g. hiddenapi-index.csv
file, were generated in two steps. First, each module created its own
files using the information in its class jars. Then, the monolithic
files were created by merging those module specific files into a larger
file.
This change switches to generating the monolithic files directly from
the class jar files and bypassing the intermediate files.
In order to ensure that this change did not change the monolithic files
it is necessary for the hiddenapi-metadata.csv to go through a
reformatting step. Hopefully, this will be able to be removed in a
follow up change.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I5a78e747516014b7c0f402a4b4431b14be6a84b2
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I54b677c97712a7573ff5eed017c1b2198b80bc51
Previously, when code coverage was enabled the monolithic hidden API
processing would add jacoco-stubs to public APIs only as that would
make them accessible for everyone. However, the
art-bootclasspath-fragment added jacoco-stubs to public, system and
test APIs as that was the simplest way of handling it and while the
extract APIs were unnecessary they would not change behavior.
Unfortunately, that lead to a difference in the flags generated which
caused the check that verifies flags are consistent between the
monolithic and modular files to fail.
This change adds jacoco-stubs to system and test APIs for the
monolithic hidden API processing to ensure consistency.
Bug: 179354495
Bug: 188143639
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true out/soong/hiddenapi/hiddenapi-flags.csv
- ran before making the change to reproduce the problem and after
to verify the fix.
Change-Id: Icbd15f0ece871a8c44d9e4a73fd0f7acc3760bba
A java_sdk_library specified in the bootclasspath_fragment contents
must be providing APIs for the bootclasspath_fragment and so must be
treated as if they were specified in the stub_libs. This avoids having
to specify them in both contents and stub_libs.
Bug: 179354495
Test: m nothing
Change-Id: I535065ee1a79b439e2676f35e06a75d4626adcaf
This makes sure that where there is overlap between the hidden API
flags generated for a module and the monolithic flags that they are
identical. That ensures that the modular hidden API flags will be
compatible with previous releases that relied on the monolithic flags.
Bug: 179354495
Test: m out/soong/.intermediates/art/build/boot/art-bootclasspath-fragment/android_common_apex10000/modular-hiddenapi/all-flags.csv
m out/soong/hiddenapi/hiddenapi-flags.csv
- Create some inconsistencies between the above two files.
m out/soong/hiddenapi/hiddenapi-flags.csv.valid
Change-Id: Iaf9e23cef63e221608955d89dc8d496bcc70c86e
This change adds support for generating the hidden API flags for the
contents of a bootclasspath_fragment. Currently, it will only work for
the art-bootclasspath-fragment as it has no support for creating
dependencies between bootclasspath_fragment modules which will be
needed for handling any other bootclasspath_fragment.
The hidden API flag generation added by this change is completely
separate to the normal hidden API processing and is not as yet encoded
in dex jars so will have no effect on the runtime.
The generated files are provided for use by other modules and copied
into the sdk snapshot. That is needed to allow the build to verify that
the hidden API flags generated by the individual bootclasspath_fragment
modules are consistent with the flags generated for the whole
bootclasspath, whether building from source or prebuilts.
Bug: 179354495
Test: m art-module-sdk
m out/soong/.intermediates/art/build/boot/art-bootclasspath-fragment/android_common_apex10000/modular-hiddenapi/all-flags.csv
m out/soong/hiddenapi/hiddenapi-flags.csv
- test that the former file is a subset of the latter and that
where they overlap they are identical.
Change-Id: Ie27303e2960953db1b7abe95510e3bca4411b09a
The modular hidden API processing needs access to the classesJarPaths
and bootDexJarPath fields of the hiddenAPI structure even if the
modules are not themselves considered to be active participants in the
existing hidden API processing.
This change moves the initialization of those fields to before inactive
modules are ignored.
Bug: 179354495
Test: m art-module-sdk out/soong/hiddenapi/hiddenapi-flags.csv
Change-Id: I06f96d39d0b413295d3e2af50453ebe7e4d3e9c8
A java_library specified in a bootclasspath_fragment's contents
property will be automatically added to the sdk containing that
bootclasspath_fragment. Previously, if that was attempted with a
java_sdk_library it would be added to the sdk as if it was a normal
java_boot_libs which would prevent the sdk from containing the
API specific artifact such as current.txt files and stub libraries
and sources.
This change fixes that and adds a java_sdk_library as a java_sdk_libs
module.
Bug: 177892522
Test: m nothing
Change-Id: Ided57b846ce5b8940c7e898c786fd77602582ea2
Moves the building of boot images from the dexpreopt_bootjars singleton
to the bootclasspath_fragment and platform_bootclasspath.
The art boot image is generated by the art-bootclasspath-fragment
module and the framework boot image by the platform-bootclasspath
module.
This does temporarly duplicate the generation of an identical boot
profile for each image. As part of the work to modularize the boot
image profile each image will have its own custom default boot profile.
Bug: 177892522
Bug: 186455808
Test: m droid and TreeHugger
Change-Id: I23cf05ec7648749b21c7cf6fcba282b46649a981
Previously, the initialization of the dexpreoptBootJars fields used to
store information needed in its MakeVars method was interleaved with
the calls to buildBootImage(). In fact those fields were initialized
from the *bootImageConfig returned by buildBootImage(). However, the
method simply returned the *bootImageConfig value that was passed in.
Separating the initialization from the calls to buildBootImage() allows
the functionality to be moved to platform_bootclasspath separately.
Bug: 177892522
Test: m nothing
Change-Id: I8ba460f60be553516de5f186e14377bb0ec1b2cd
The art dex files are copied in the bootclasspath_fragment and the
non-updatable and updatable dex files are copied in the
platform_bootclasspath.
Bug: 177892522
Test: m nothing
Change-Id: I5d3d533d1a7a9f8e7ae20c12eb33029a898a2cd6
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
