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, the hidden API flags generated for a bootclasspath_fragment
did not include removed API members. That was because it did not supply
a file containing the dex signatures of the removed API members.
The monolithic hidden API processing uses combined-removed-dex which is
the output of a genrule that takes as input the *removed.txt files from
all the APIs and uses metalava to construct the dex signatures file.
This change does the equivalent for the *removed.txt files for the APIs
provided by a bootclasspath_fragment and then passes them to the rule
that generates the final all-flags.csv.
Bug: 179354495
Test: - Update packages/modules/RuntimeI18N to enable hidden API
processing.
m out/soong/hiddenapi/hiddenapi-flags.csv
- Before this change that fails as the flags generated for the
i18n-bootclasspath-fragment differ from the monolithic flags.
After this change that passes.
- Verify that this change does not change any of the monolithic
hidden API files.
m com.android.i18n
- Verify that the apex file before and after this change are byte
for byte identical.
Change-Id: I6a21edb8a5231666e3f35b2c99a8687f36dd98fd
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
Previously, the bootclasspathApiInfo was only used for tests and follow
up changes will need to provide the stub dex jars. This change moves
the stubJarsByKind into HiddenAPIInfo and removes bootclasspathApiInfo
and the corresponding provider.
Bug: 179354495
Test: m nothing
Change-Id: I5459c56de561c053ed671dc9d5cb3ee4820c0ee8
Change 70cfdff3da changed the hidden API
flags in com.android.i18n as it stopped the i18n-bootclasspath-fragment
from making the hidden API flag files available for use by
platform-bootclasspath.
This change fixes that by exporting the flag files even if hidden API
flag generation is skipped.
Bug: 179354495
Test: m com.android.i18 out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that the flags in
packages/modules/RuntimeI18n/apex/hiddenapi/hiddenapi-max-target-o-low-priority.txt
are reflected in the core-icu4j dex files in the apex.
Change-Id: I9b5c7c74bd996ab447bc0e0452da5fd49191a35d
This reflects that it has expanded from its initial purpose to include
more than just flag files. It is exported for use in tests in other
packages.
Bug: 179354495
Test: m nothing
Change-Id: I9f780b20e18ce3a774e4aa04a276463070a64c34
Encapsulating the information needed by hidden API processing in a
struct makes it easy to add additional information in future and allows
the code to populate that struct from various different sources to be
grouped together.
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: I53805737dff36a3ae87aca5aad51cf46ae1361fe
HiddenAPIFlagOutput encapsulates the paths to the files produced by the
hidden API flag generation of a single bootclasspath_fragment. It is
returned from hidden API flag generation and is embedded within the
hiddenAPIFlagFileInfo so they can be passed to other modules.
Unlike the fields it replaces in hiddenAPIFlagFileInfo the fields in
HiddenAPIFlagOutput are of type Path not Paths which makes it easier to
use.
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: I7373ba1001cac3a75eb54a23e62fa52f5013ee7f
The hiddenAPIFlagFileInfo was being used for both the input and output
of bootclasspath_fragment and platform_bootclasspath and also to pass
information around to various hidden API rule methods. Supporting
multiple different uses in this way made it hard to reason about.
This change creates a separate structure for use by the
platform_bootclasspath. Follow up changes will split out other
functionality into separate types.
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: Ia5c5f65ae5645486c42819c669a8601588217f88
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
Change-Id: Ib1b6eb8b62ac50e03b9e0d07c877ca70bb6f6d25
Previously, if the method was called multiple times by the same module
the resulting build rules would all use the same temporary directory
which meant that if run in parallel they would conflict with each
other. This change fixes that by providing a jar specific temporary
directory so it can be used by bootclasspath_fragment to encode its
content modules.
Also, cleans up, simplifies and improves the documentation.
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: I0ebe61abc8e16111c6e8a822eb96c57846b98461
java_sdk_library modules in builds with AllowMissingDependencies may
be missing defaults modules that cause them to look for api files that
they normally wouldn't need. Move the error to runtime so it doesn't
block the build unless the branch tries to build that module.
Test: prebuilts/build-tools/build-prebuilts.sh in aosp-build-tools
Change-Id: I279b0cd8493779f972c0ac02235967c10b35a5a0
To avoid duplicates on *CLASSPATH environ variables at runtime, remove
split entries from platform-*classpath, i.e. all updatable jars that
have their own classpath fragments should not appear in the
platform-*classpath's classpaths.proto config.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: Id2759ab8e106cc183e695bf3509a6ab60ab0ef2a
Merged-In: Id2759ab8e106cc183e695bf3509a6ab60ab0ef2a
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
Previously, the hidden API encoding was done before resource merging.
However, hidden API modularization requires that the encoding be done
by the bootclasspath_fragment/platform_bootclasspath modules which will
be after the resource merging. Therefore, this change moves the hidden
API encoding after to match the future behavior.
It also moves the initHiddenAPI() method call after resource merging
too and passes it the result of the resource merging so it is available
for the bootclasspath modules via bootDexJar().
Although the resource merging was not always done when it was done it
would reorder the entries in the generated jar to match java ordering,
which puts the MANIFEST.MF first. This change preserves that behavior
by adding -j to the call to MergeZipCmds. This does mean that jars
which did not require resource merging now have a different order but
as both orders work that is not a significant change.
Bug: 179354495
Test: m com.android.art com.android.ipsec com.android.os.statsd com.android.conscrypt
- verify that apart from the ordering change in the jars that this does
not change the contents of the apex files
Change-Id: If74baad5659301ca6ca9c0f6484374420dda8c34
* changes:
Don't fail if the target module is disabled in dex2oat tool dependencies.
Use oatdump rather than oatdumpd for boot jar boot.*.oatdump.txt files.
The AlwaysUsePrebuiltSdks() causes all java_sdk_library_import modules
to be preferred over the source, i.e. as if they had prefer: true set.
That interacts badly with the work that is being done to integrate the
bootclasspath_fragment/platform_bootclasspath modules into the build.
It would work fine once that integration has been completed but in the
interim it causes problems. e.g. it does not cause a problem in AOSP
because those java_sdk_library_import modules that are affected have
already been integrated into the build properly.
Unfortunately, internally that is not the case because there are
java_sdk_library/java_sdk_library_import modules that still need to
be updated.
Before the java_sdk_library_import can be safely preferred each
java_sdk_library/java_sdk_library_import module that contributes to the
bootclasspath must:
* Be in the contents of matching bootclasspath_fragment and
prebuilt_bootclasspath_fragment modules.
* Have an apex and one of a prebuilt_apex/apex_set that contains the
dex implementation jar and lists the prebuilt_bootclasspath_fragment
name in its exported_bootclasspath_fragments property.
Safely preferred in this context means that the whole build will
continue to work rather than the current situation which is that only
some of the build will work and some will fail if an attempt is
actually made to build it.
Unfortunately, many java_sdk_library_import modules are missing:
* The prebuilt_bootclasspath_fragment.
* The exported_bootclasspath_fragments property on the
prebuilt_apex/apex_set that contains them.
Together these cause the following symptoms:
1. The java_sdk_library_import does not have a dex implementation jar.
2. The java_sdk_library_import does not have a myapex variant.
These workarounds will avoid Soong reporting build failures. However,
the build will still fail if an attempt is made to build anything
produced by the platform-bootclasspath, e.g. hidden API processing or
a system image.
Bug: 188505921
Bug: 179354495
Test: m TARGET_BUILD_APPS=Calendar
Change-Id: I3226e21cd6a7f9e4d6bbe94e54129ac5e1d4c679
Merged-In: I3226e21cd6a7f9e4d6bbe94e54129ac5e1d4c679
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
- 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
Propagate strict_updatability_linting to transitive dependencies using a
top-down mutator.
Test: lint_test.go
Bug: 182349282
Change-Id: Ifc9e58f1a597e3c7725ee49b4027afb6f42f45cb
Each specific classpath_fragment module knows what jars must be part
of the corresponding classpaths.proto config.
Note that bootclasspath_fragment does not implement classpath_fragment
yet, thus all boot jars and all system server jars go into corresponding
platform classpaths.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I6a8c7b0a5d17d62e790a441b8e2c5c1a816e7f30
Add 'host' into the name of fields regarding path on the host side to
distinguish between paths on the device(which will be added in the
following commit), and paths on the host.
Bug: 158843648
Test: build and flash, and then
adb wait-for-device \
&& adb -s $S root \
&& adb -s $S logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch' -C 1
Change-Id: Ib2645ed51591ba2f4b726c115b401ad2bd6675da
Boot jars are different to system server jars at build level, due to
added complexity of dexpreopt. As a logical separation add a new
classpath fragment type and split existing classpaths.proto generation
into relevant pieces.
Bug: 180105615
Test: m && launch_cvd; atest CtsClasspathsTestCases
Change-Id: I88bec09fc920166ffd0092faef980754ddeb6593
Previous refactorings of the code for creating these two files caused
them to be created before the boot.prof file instead of afterwards. As
a result even though they were appended to the list of files to install
they were discarded when the boot.prof file set the list rather than
appended to it. That worked before the refactoring because the
boot.prof file set the list first before the others were appended to
it.
This change appends the boot.prof file to the list making the order in
which they are added irrelevant.
Bug: 187494247
Test: m nothing
- check DEXPREOPT_IMAGE_PROFILE_BUILT_INSTALLED in generated
make_vars file to ensure it includes all 3 files.
Change-Id: Idb94531daf61b1b047c72eb5c67a57d3fdced05c
This is part of the work needed to allow the exported_java_libs
property to be replaced by exported_bootclasspath_fragments.
Bug: 187266082
Test: m nothing
m SOONG_CONFIG_art_module_source_build=false nothing
Change-Id: I2c1d70a390200b93163f9799719290c9d55a041c
The libs property in java_sdk_library is not safe to export as it can
contain libraries that contain implementation specific classes. No
snapshot appears to need this capability but if it does become
necessary then either it will need to use the existing stub_only_libs
property or a new one will need to be added.
Bug: 157884619
Test: m nothing
Change-Id: I60a069177dbee4070d311b23d25f4eb3c5e7ea13
Previously, only those SdkMemberTypes which had specific need to
automatically add some of their dependencies as sdk members would cause
the sdk to visit their transitive dependencies. However, as any module
can have dependencies on license modules and license modules need to be
included in the sdk then it needs to visit transitive dependencies of
all members.
So, this change removes the support for allowing an SdkMemberType to
control whether its transitive dependencies are visited and just visits
them all.
This does not have any effect on sdk snapshots as in order for a
dependency to be added to an sdk it needs to be added with a tag that
implements SdkMemberTypeDependencyTag and the only tags that implement
this are used by SdkMemberTypes that had enabled transitive members.
Bug: 181569894
Test: m art-module-sdk art-module-host-exports art-module-test-exports
- verify that this change has no effect on the generated snapshots
Change-Id: If0293af0237aa7e39335e5b8383a41c023ff5853
A follow up change will add methods to SdkBase which requires its
module field to have been initialized.
Bug: 181569894
Test: m nothing
Change-Id: I9b02f260ad3f82316cc7ab3b5717b7e81090b0d8
Consistent with plumbing of boot jars. SystemServerJars only support /system/framework/ jars.
Bug: 180105615, 155630745
Test: m && launch_cvd
Change-Id: I58b005b7c4103c8e250090e995b1d9b2f9ed4a76
Maintain compatibility with previous behavior by ignoring dex_import
during hidden API processing.
Bug: 179354495
Test: m nothing
Change-Id: I976b02129bf981b7b61dce233567d6f89e04f92d
R8 processes are sometimes hanging on the build servers. Wrap R8 with
run_with_timeout to dump the stacks with jstack and kill the process
after 30 minutes. Switch from running with the r8-compat-proguard
shell script to running the jar directly so that jstack gets the pid
of the java process.
Bug: 181095653
Test: m checkbuild
Test: m NetworkStackNextIntegrationTests
Test: m USE_RBE=true RBE_R8=true RBE_R8_EXEC_STRATEGY=remote NetworkStackNextIntegrationTests
Change-Id: If6996bd8eb39c7a8453d79e825004339c009ade2
The previous attempt, which simply skipped the hidden API processing
altogether when unbundled builds were enabled failed when attempting to
build module snapshots as while they enabled an unbundled build they
actually need the hidden API processing to be performed.
This change just checks whether missing dependencies are allowed and if
so it fakes up any missing files so that the build will only fail if
they are not present AND they are used.
Bug: 186695448
Bug: 185828824
Test: tapas Calendar
m -j60
Change-Id: Ie13fed05af0aba51f45f6791fce944d0e4285037
The main difference between the dexpreopt_bootjars singleton and the
platform_bootclasspath singleton module is the way they find the
modules to use. The former searches all modules, the latter adds
dependencies on the modules that they need. This change separates the
finding of the modules from the copying of the boot jars for those
modules to make it easier to move the remaining functionality to
platform_bootclasspath.
This temporarily creates a singleton specific copy of the hidden API
function isModuleInConfiguredList() to select the modules in place of
the logic in the getBootJar() method. There is a slight loss of context
information from the error messages but as these methods will be
removed once the boot image creation has moved this is not an issue.
While switching the isModuleInConfiguredListForSingleton() to use the
SingletonContext the error message was fixed to include the name of
the module with the issue.
Bug: 177892522
Test: m nothing
Change-Id: Iaea906da95d9da5301fb964fc593890f2216d336
The getBootImageJar function will be removed once the boot image
creation has been moved to the platform_bootclasspath and
bootclasspath_fragment module types. However, the consistency checks
that it performs are still useful so this change moves them out
first.
The ART boot image related checks are now performed in the
bootclasspath_fragment module type. A previous change accidentally
disabled the checks when the contents property was not empty which has
been fixed. Also, the error messages have been tweaked to make it clear
that the art-bootclasspath-fragment is now the source of truth as to
its contents not the configuration.
The framework boot image related checks are now performed in the
platform_bootclasspath module type.
Initially, this change included an extra check to make sure that
UpdatableBootJars comes from updatable APEXes but that broke because
framework-wifi and framework-tethering are not currently marked as
updatable in AOSP.
Bug: 177892522
Test: m nothing
Change-Id: I80fb600fa2c7cec4566b3461c6a33c4c6f0743f4
This annotation is required for linting, but is not useful in stubs.
Bug: 185579441
Test: cherry-pick http://ag/14098354 and regenerate stubs
Change-Id: I7e4da99a8843b9c709f3b59f125f43cbd66bda4e
Bug: 179354495
Test: rm out/soong/make_vars*
m nothing
grep INTERNAL_PLATFORM_HIDDENAPI_FLAGS out/soong/make_vars*
- make sure it is still out/soong/hiddenapi/hiddenapi-flags.csv
Change-Id: I86e56512a9a2091f446bad25294d41ea1f4341ee
This is needed in order to allow it to implement MakeVars so it can
create make variables just like the dexpreopt_bootjars and hiddenapi
singletons currently do.
Bug: 177892522
Bug: 179354495
Test: m nothing
Change-Id: Ida5bf8abeecde531e1f6430151650065445804ac
Bug: 177892522
Test: m oat-dump-boot
- test output to make sure that this change does not change the
generated files, at least no more than no changes do as the
output from this rule is not deterministic. See b/186459873.
Change-Id: Ib2b4203d9bb1fd0ee9443aee4e58b54b38b491cf
Changes generateUpdatableBcpPackagesRule to use ModuleContext instead
of SingletonContext and moves the call from dexpreoptBootJar's
GenerateSingletonBuildActions method to platform_bootclasspath's
GenerateAndroidBuildActions.
Bug: 177892522
Test: lunch art_module_arm64
m out/soong/module_arm64/dex_bootjars/updatable-bcp-packages.txt
- make sure it is not affected by this change
Change-Id: I9741ae1eb9573cafe12dd7a17dc1d8449b224dc8
Bug: 177892522
Test: lunch art_module_arm64
m out/soong/module_arm64/dex_bootjars/updatable-bcp-packages.txt
- make sure it is not affected by this change
Change-Id: I3d35f1664cbbaba5df3f5809859dd9815a26d05d
Trades having to traverse a module's direct dependencies multiple times
for reusable code. While at the minute the amount of duplicated code is
small (checking a tag and appending to a list) follow up changes will
modify the gatherApexModulePairDepsWithTag module to improve error
reporting greatly increasing the benefit of deduping.
The cost of traversing a module's direct dependencies is very small as
there will be only a very few dependencies.
Bug: 177892522
Test: m nothing
Change-Id: I16389102abd8038e1bfa52b63f4153bdf92ff553
Change https://r.android.com/1672245 added support to treat
system_ext:foo in the boot jars configuration the same as platform:foo,
at least for dexpreopt_bootjars.go's getBootJar.
This change replicates that mechanism in platform_bootclasspath and as
that now handles hidden API processing also made a similar change in
the isModuleInConfiguredList function.
Bug: 177892522
Bug: 154976937
Test: m nothing
Change-Id: I105f4fbaa3b0355b013b7c5618d218d888faefb6
The hidden API processing needs access to dex stub jars for the API
scopes provided by the bootclasspath_fragment so that it can mark the
corresponding dex members as being part of that API. This change adds
the ability to specify the modules that provide those jars, resolve the
modules to dex jar stubs and make them available for other modules and
tests to use.
While the stubs are only needed for hidden API at the moment these were
not added to the hidden_api properties section as there are other parts
of the build that may need to access the stubs in future, e.g. api
fingerprint and aidl generation.
The stubs properties can be affected by coverage as when coverage is
enabled the jacoco-stubs needs adding to the list, just like how
jacocoagent is added to the contents.
Bug: 177892522
Test: m nothing
Change-Id: I31097d1ca45c84adeba4cbb38f693698cb289e99
This simplifies the process of moving the updatableBcpPackagesRule to
the platform_bootclasspath by separating the gathering of the list of
updatable modules (which differs between the singleton and the
platform_bootclasspath module) from the gathering of the permitted
packages list and generation of the rule which are generally common.
Bug: 177892522
Test: lunch art_module_arm64
m out/soong/module_arm64/dex_bootjars/updatable-bcp-packages.txt
- make sure it is not affected by this change
Change-Id: I3cb64310f618059758a32cfe00d3745d52388e49
Previously, the method was run in repo manifests that did not include
the frameworks/base repository so it had to handle the file being
missing. However, now that this is being called from
platform_bootclasspath which is only defined in frameworks/base that
is no longer required.
Bug: 177892522
Test: m droid
Change-Id: I77fa5a204d1426a6be24a6f0b48e18f48f3dd908
Changes bootFrameworkProfileRule to use ModuleContext instead of
SingletonContext and moves the call from dexpreoptBootJar's
GenerateSingletonBuildActions method to platform_bootclasspath's
GenerateAndroidBuildActions.
Changing the context also allows the code to switch from
bootFrameworkProfileRule to GetGlobalSoongConfig.
Also extracts the shouldBuildBootImages function so it can be used by
platform_bootclasspath to preserve the existing behavior.
Bug: 177892522
Test: m droid
Change-Id: I30d3ca10be7f84348ad3aa9cc984dd15b8f6f4e9
This change makes the tag that is used to add dependencies onto stubs
from the bootclaspath_fragment module cause the dependency to be
automatically exported from the sdk. If the dependency is a
java_sdk_library then it will be as if it was added to the
java_sdk_libs property, otherwise it will be as if it was added to the
java_header_libs property instead.
Bug: 177892522
Test: m nothing
Change-Id: I97010c4342dd39415dba81a4395db7831410436e
This change allows an SdkMemberTypeDependencyTag to select the
SdkMemberType to use to add a dependency based on the module.
Bug: 177892522
Test: m nothing
Change-Id: I2d6e51b615636dc7cd41da65808ef851dd8ae6ac
Previously, buildBootImage had to be called for the default boot image
config before the art boot image config as it created some rules which
were specific to default boot image. The creation of these rules was
encapsulated in Config().Once(..) to ensure that they were only ever
created once.
This change extracts that functionality out of buildBootImage to the
calling method which means that they are only called once and so no
longer need protecting against being called again.
Bug: 177892522
Test: m droid
Change-Id: I464477de1a08df15e577873a9accf7db2bc088d1
Previously, the buildBootImage function maintained a list of
missingDeps that was returned from findAndCopyBootJars and was passed
to various other methods that created ninja rules that depended on the
files created by findAndCopyBootJars. The purpose of that list was
basically to record that findAndCopyBootJars could not find some files
so that the subsequent ninja rules could be marked as being in error.
This changes avoids having to explicitly propagate the missing deps to
each rule by instead having findAndCopyBootJars generate an error rule
instead of a Cp rule for any missing file. That means that any attempt
to build any rule that depends on the missing file will fail when the
missing file is created.
Bug: 177892522
Test: Add an unknown module to PRODUCT_BOOT_JARS
lunch art_module_arm64
- Run each of the following targets and made sure it failed with a
message indicating that the unknown module was missing.
m SOONG_ALLOW_MISSING_DEPENDENCIES=true out/soong/module_arm64/dex_bootjars/boot.prof
m SOONG_ALLOW_MISSING_DEPENDENCIES=true out/soong/generic_arm64/dex_bootjars/boot.bprof
m SOONG_ALLOW_MISSING_DEPENDENCIES=true out/soong/generic_arm64/dex_bootjars/updatable-bcp-packages.txt
Change-Id: Ib7196c128419fbffdfeb61c1c5d47a3b08d1e132
The code that has been removed triggers in many cases when it should
not, e.g. an unknown module on the bootclasspath. The code was
originally added to try and ensure that if the attempt to add useful
error messages failed it would help debug the issue. However, it ended
up just creating more failures.
If this does become an issue then this will be revisited.
Bug: 177892522
Test: Add an unknown module to PRODUCT_BOOT_JARS
m SOONG_ALLOW_MISSING_DEPENDENCIES=true
Change-Id: I08dbd4b29d301f3f1f78a0fb396687062b47deb8
Previously, both a bootclasspath_fragment and its contents had to be
explicitly added to the sdk. This change means that adding a
bootclasspath_fragment to and sdk will automatically add its contents
as if they were added using java_boot_libs.
Bug: 177892522
Test: m nothing
Change-Id: I8f7e70649f272c9a109d4606571a2d12c44b7904
Previously, only one of the contents or image_name properties could be
specified at once which meant that there was no way to create a
prebuilt which lists its fixed contents while at the same time allowing
it to check that that the contents matched what the build configuration
required.
e.g. a prebuilt_bootclasspath_fragment that had image_name: "art",
could not list its contents and also check that those contents matched
the ART_APEX_JARS which the build configuration required.
This change allows contents and image_name to be specified together and
adds a check to make sure that the contents are consistent with the
configuration appropriate to the image_name. The check is only
performed for modules that are active so that a
prebuilt_bootclasspath_fragment which was created without coverage
enabled (the default) would not cause a build failure in a coverage
build unless it was preferred.
Bug: 177892522
Test: m nothing
Change-Id: Ie601f29f707b3f6030fa7d252afa2c4826cc9f8e
This will allow them to be used from elsewhere in a follow up change.
Bug: 177892522
Test: m nothing
Change-Id: I60e94e148af5b1810aea7f724cba090b49ae758e
This allows a bootclasspath_fragment (specifically the
art-bootclasspath-fragment) to specify additional contents to be
appended when coverage is enabled.
The art-bootclasspath-fragment will use this to add jacocoagent to its
contents to ensure that it is always consistent with the configuration.
Bug: 177892522
Test: m nothing
Change-Id: I50d05fe5e0e9b8c14bdf3dfd63bba0ac97e31d48
The field isn't used anymore.
And DexPreoptImagesDeps will have the slice of which size is the same as
Archs to avoid an error.
Bug: 158843648
Test: m
Change-Id: I520063ff7376811febbc82e1a0a43785feb5bbb2
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
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
The BootImageInfo is used to populate an apex. A platform_bootclasspath
module cannot be part of an apex so does not need to provide one.
Bug: 177892522
Test: m nothing
Change-Id: I1e1c4962d9d8106a12af80107c4c35828f54ff81
Previously, every module added to an sdk directly through one of the
SdkMemberType specific properties, e.g. java_libs, was exported and
every module added automatically via a transitive dependencies was not
exported. This change allows that behavior to be customized per tag.
Bug: 186290299
Test: m art-module-sdk
- verify that this change does not affect its contents.
Change-Id: I563b5bcd823e61c23cdb706cfcbb13337963d550
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 is needed to allow a prebuilt_bootclasspath_fragment to be used
interchangeably with a bootclasspath_fragment in the
platform_bootclasspath module.
The platform_bootclasspath module depends on APEX specific variants of
bootclasspath_fragment modules. That works because the
bootclasspath_fragment modules are part of an apex and so have an APEX
specific variant which the platform_bootclasspath can specify.
Using a prebuilt_bootclasspath_fragment in place of a
bootclasspath_fragment requires that the prebuilt also has an APEX
specific variant.
Specifying exported_bootclasspath_fragments on a prebuilt_apex/apex_set
will cause it to create an APEX variant for the named module whcih will
allow it to be selected by the platform_bootclasspath module.
Bug: 186034565
Bug: 177892522
Test: m nothing
Change-Id: I7ddacc6498ec3a4a9f26c5f78b7f9a033e494d78
This exports classesJars constructed in hiddenAPIExtractInformation
through the hiddenAPIIntf interface for use by the
bootclasspath_fragment module type.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: Ic32f02a69229d9518772fe6b2a329501dd8cd849
The platform_bootclasspath and bootclasspath_fragment modules provide
different capabilities but are related and so have some common
functionality. This change moves some platform_bootclasspath code that
will be of use for bootclasspath_fragment in future into a separate
file.
Bug: 177892522
Test: m nothing
Change-Id: I827b85e33d16155fcc920d553100c9e99267dc4e
Adds a BootclasspathDepsMutator that is currently only implemented by
the platform_bootclasspath but which can be implemented by
bootclasspath_fragment too.
Bug: 177892522
Test: m nothing
Change-Id: Ibe35854281004d6e40bf1f797144fb582e8c08b9
The jacocoagent is special as while it is depended on by prebuilts it
is not actually a prebuilt.
Bug: 177892522
Bug: 186118711
Test: m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true nothing
Previous command fails without this change and works with it.
Change-Id: I8fba922fc40919936d74a6f95af745e37f1ca61f
As part of that this change:
* Moves code that will be common to platform_bootclasspath and
bootclasspath_fragment from hiddenapi_singleton.go into
hiddenapi_modular.go.
* Fixes the tests in hiddenapi_singleton_test.go but intentionally
does not rename them or move them into a more appropriate place so
as to make it easier to see the differences. A TODO has been added
and these will be cleaned up in a follow up change.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I680e4dab2e6bdf4a655fa9f255c195175904667e
The stubFlagsRule does three separate tasks:
1. It computes the set of modules that provide the stubs.
2. It scans all the modules to find the stub modules and retrieves the
paths to their dex files.
3. It constructs the ninja rule.
Of those three tasks, 1 and 3 will be same for the
platform_bootclasspath. Instead of searching all the modules for the
ones that provide the stubs it will simply add dependencies onto the
stub modules and retrieve the dex file paths from them.
This change extracts tasks 1 and 3 into separate methods for reuse. It
also parameterizes the generation of the ninja rule.
Bug: 179354495
Test: verified that the monolithic out/soong/hiddenapi/... files are
unchanged by this change
Change-Id: I893845dbddc4b001dfd44d0e0b1c8a31b7f3f89f
They were used to generate export values for BOOTCLASSPATH and friends;
which are now generated by derive_classpath service based on proto
configs at runtime.
Bug: 180105615
Test: m && launch_cvd; presubmit / DeviceBootTest
Change-Id: Ifbf3f076a00e084d47a48180a4286fc53e610c5d
Allow java_sdk_libraries to include libraries statically into their
stubs. The immediate use-case of this is to embed libcore notice files
into their stubs.
Also extend the java_sdk_library tests for impl/stub-only-libs, plus
some not assert utils.
Bug: 173186484
Bug: 184839599
Test: soong tests
Change-Id: I1ebf2f35c048eab5cec5125482a0304fe660f188
The flag prevents developers from skipping updatability lint checks with
baseline files
Test: lint_test.go & manual
Bug: 182349282
Change-Id: Ia74a2b83c7ef686124128bdf16f7b85a919d9e8d
These are needed at the moment to ensure the hidden API processing
generates the same set of flags whether it is being generated from
source or prebuilts. Soon these will be needed to ensure that the
hidden API flags generated for the individual modules are compatible
with previous releases.
Bug: 179354495
Test: m art-module-sdk and check snapshot zip contains the files
and the generated Android.bp references them.
Change-Id: I9a3334cc48faa381bbbcbbb59479db719042796a
Previously, there were two approaches used to construct the temporary
path needed by the commitChangeForRestat method and neither was
suitable for general use. One was:
android.PathForOutput(ctx, outputPath.Rel()+".tmp")
The other was:
combinedAidl.ReplaceExtension(ctx, "aidl.tmp")
The first approach would not work if the supplied path had been created
by PathForModuleOut() or similar as it would drop the module directory.
That could lead to the same path being used for multiple rules.
The second approach would not work for files with a different
extension.
The tempPathForRestat combines the two approaches so it can be used
generally with any WritablePath.
Bug: 179354495
Test: verified that the ninja rules that used these files were not
changed by these changes.
Change-Id: I4439dea0a823512c281eeb1366522fb49dceb4e3
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
There is a check in initHiddenAPI that makes sure that if the source
module has been replaced by a prebuilt the prebuilt provides a boot dex
jar. The check was added to try and detect an issue with hidden API
processing early at build time rather than at runtime.
That check relies on the source module having a PrebuiltDepTag
dependency on the prebuilt module that is preferred and will be used by
hidden API processing. That is true for modules that are not in an APEX
but doesn't work for modules that are in an APEX.
The issue is that an APEX variant of a source module depends on the
non-APEX variant of the corresponding prebuilt module. However, that
variant of the prebuilt is not the one that will be used by hidden API
processing; it will use the APEX variant of the prebuilt module which
is the one that has access to the boot dex jar.
That results in the initHiddenAPI check giving a false negative as it
states that the boot dex jar is not available when it may be.
This change simply skips the check is the source module is an APEX
variant. This is a temporary work around as the hidden API processing
is being modularized for each APEX at which point initHiddenAPI will
either be removed entirely or just skipped for APEXes altogether.
Bug: 179354495
Bug: 185828824
Test: m nothing
Change-Id: I2dc3654c9aa476541855b3f0f243a181ddf8d723
Add jni_libs property to java tests and treat it as test data that
should be copied to the lib or lib64 directory in the test directory.
This relands I3a118b933ab30dcd731c6dc2708da9bc63ab5520 with fixes for
the test on mac.
Fixes: 176593487
Test: java_test.go
Change-Id: I2f8c46643cff7a7ae6dc4d4dbad58f0396e45f09
1. Instead of 'slim' config, use full config even for libs
2. Define moduleJSONConfig for fields which cannot be converted to JSON
field directly(Path type field, ProfileBootListing,
DexPreoptImagesDeps are added in this CL) and exclude fields which is
convertible(DexPreoptImageLocations)
Bug: 158843648
Test: m dist
Change-Id: I3f9192ab5292bd079be1b686bb3b25735a836cbc
Add jni_libs property to java tests and treat it as test data that
should be copied to the lib or lib64 directory in the test directory.
Fixes: 176593487
Test: java_test.go
Change-Id: I3a118b933ab30dcd731c6dc2708da9bc63ab5520
