Previously, the split_packages, single_packages and package_prefixes
properties were all optional and the split_packages defaulted to ["*"].
As that value conflicted with the other package properties that meant
that split_packages always had to be specified even if it was to just
set it to an empty array.
This change requires at least one of them to be specified and defaults
split_packages to an empty list which means it is not required,
although it can be helpful to make that explicit.
Bug: 194063708
Test: m nothing
Change-Id: I5a4c2d68e72e39f5c4a2441326dfce8685fc8ff2
Treats bootclasspath_fragment modules that have not yet been converted
to test modules as if they were test modules. This is a temporary work
around to ease the migration to bootclasspath_fragment_test modules and
is expected to be reverted.
Bug: 194063708
Test: m nothing
Change-Id: I093fbec4e926719b644c64ebfc63f9e3070e28db
This is needed to allow the behavior of the bootclasspath_fragment to
be tweaked for test fragments.
Bug: 194063708
Test: m nothing
Change-Id: Iee5c09d5b580d088ba081d95a788dbde883078ed
This is in preparation to r.android.com/1740313 where setting correct
variables would be enforced (i.e. apex and non-apex boot jars must be in
config.ApexBootJars and config.BootJars correspondingly).
Bug: 191369843
Test: m nothing
Change-Id: Ic86680c1f7af53d229083b2cc58beb3ceccb4b6a
Previously, if a bootclasspath_fragment had both a java_sdk_library
module and one of its components in stub_libs properties they would be
treated as separate modules instead of simply different APIs from the
same module. That would result in them both providing stub dex jars to
"hiddenapi list" which would fail because it found duplicate
definitions of the same class.
e.g. Specifying something like this:
api: {
stub_libs: [
"art.module.public.api",
],
},
core_platform_api: {
stub_libs: [
"art.module.public.api.stubs.module_lib",
],
},
would cause "hiddenapi list" to fail because it would have been passed
paths to two dex jars (actually the same dex jar but that does not
matter) each of which defined the same class, e.g. java.lang.Object.
This change treats the "art.module.public.api.stubs.module_lib" and
"art.module.public.api" modules as being the same for the purposes of
hidden API processing.
Bug: 192446466
Test: m nothing
Change-Id: I9de96337f64f26e24cff040d4bbed9eecc67b1ed
Previously, the stub dex jars for each HiddenAPIScope was created by
merging the stub dex jars provided by each module for that scope. Then
the widest stub dex jars were chosen. So, if module A provided public,
system and test stub dex jars and module B provided only public then
the stub dex jars for each scope would be:
* public -> A,B
* system -> A
* test -> A
So, the widest API scope for which there are stub dex jars is "test"
and so the widest stub dex jars would just come from module A and not
module B. So, when "hiddenapi list" is run for module C which depends
on modules A and B it only gets given stub dex jars for module A which
means that it cannot resolve all the types that C may use which can
lead to incorrect flags being generated.
This change does not merge the stub dex jars from each module together
and instead keeps them separate by module. The widest stub dex jars
list is constructed by asking each module in turn for their widest stub
dex jars. e.g. Given the above example we would have:
Module A:
* public
* system
* test <- widest
Module B:
* public <- widest
So, the widest stub dex jars will be A's test and B's public stub dex
jars.
Bug: 179354495
Test: m out/soong/hiddenapi-flags.csv
- make sure that this does not change the file.
Change-Id: Ib137825ebffe94b2bf220732bae6077f7b7ac6db
The widest stub dex jars should include the widest stub dex jars
provided by each module. So, if module A has public, system and test
and module B has only public then the widest stub dex jars should
include module A's test and module B's public stub dex jars. Instead,
they just include module A's test.
That behaviour is needed so that when the "hiddenapi list" tool is run
against a module C that it is passed stub dex jars from both module A
and module B so that any references to the types provided by those APIs
can be resolved.
A follow up change will fix this issue.
Bug: 179354495
Test: m nothing
Change-Id: Ibd31964e8d2a33fa92fbd0b800c9fe054ee359c7
Previously, the hidden API processing used SdkKind to identify the API
scopes, e.g. public, system, etc. that are of interest for hidden API
processing. Unfortunately, there is a mismatch between the SdkKind and
what hidden API processing needs. e.g. SdkKind includes values that are
not used by hidden API processing and hidden API processing needs
additional API scope specific information not provided by SdkKind. The
apiScope struct used in sdk_library.go is also not a suitable
representation for similar reasons.
This change adds the HiddenAPIScope (following a similar approach as
apiScope) that rectifies that and uses it as a replacement for SdkKind
in most parts of the hidden API processing. The SdkKind is still used
for retrieving information from java_sdk_library[_import] modules.
Follow up changes will extend the HiddenAPIScope with more information.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that this change has no effect on the generated flags.
Change-Id: I97968f58535121652852b8d25217aa288afd2bfd
Previously, due to legacy reasons, the property validation did not
require a contents property and allowed the image_name to be either
"art" or "boot". Those reasons no longer apply and so this change
requires a contents property and only allows the image_name to be set
to "art" if specified.
Bug: 177892522
Test: m nothing
Change-Id: I8855d6e5365ef0b55490e90e7b6c0081cf070ee5
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
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
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
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 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
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
