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
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
