When generating the stub-flags.csv for a bootclasspath_fragment the
hiddenapi list tool is not given a complete set of all classes and
members. This change causes it to ignore them by passing the new
--fragment option to it.
This does not risk changing the flags as the stub-flags.csv files
created with the --fragment option are compared with the monolithic
out/soong/hiddenapi/hiddenapi-stub-flags.txt file which is not run
with this option to ensure that they match.
Bug: 179354495
Test: m out/soong/hiddenapi-stub-flags.csv
- make sure that this does not change the file.
Change-Id: I890c7374c445759cade4d685f51e81261b7ccea2
When this file was initially created by extracting the test from the
java_test.go file it was not added to Android.bp file so was not being
built and tested as it should. That lead to a recent change that left
it unable to compile. This change corrects both those issues.
Bug: 186723288
Bug: 179354495
Test: m nothing
Change-Id: I06f32bb572f57b6df3c772f1d9d21fe323fbf353
Previously, hidden API processing could only be done by those
bootclasspath_fragment modules that either did not depend on any other
fragments (e.g. art-bootclasspath-fragment) or only depended on APIs
provided by other fragments (e.g. i18n-bootclasspath-fragment). That
meant that modules like com.android.os.statsd-bootclasspath-fragment
that depended on APIs provided by parts of the platform which are not
yet part of another bootclasspath_fragment could not perform hidden
API processing.
This change adds support for a bootclasspath_fragment to specify the
additional stubs needed to perform hidden API processing. It adds a new
additional_stubs property that can be used to specify the additional
stub libraries.
Most bootclasspath_fragments that need to use the property will need
access to the APIs provided by the android-non-updatable.* libraries.
Rather than have each fragment explicitly specify the correct module
for each scope it treats "android-non-updatable" as if it was a
java_sdk_library that can provide different jars for each scope.
Soong will handle mapping that to the correct android-non-updatable.*
module.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv \
out/soong/hiddenapi/hiddenapi-index.csv \
out/soong/hiddenapi/hiddenapi-stub-flags.txt \
out/soong/hiddenapi/hiddenapi-unsupported.csv
- make sure that this change does not change the contents.
m TARGET_BUILD_APPS=Calendar nothing
Change-Id: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-stub-flags.txt
- check that an error is reported if a modular stub-flags.csv file,
i.e. one created by a fragment is not a subset of the monolithic
file, e.g. because a signature in the modular file has different
flags than it does in the monolithic or is not present there.
Change-Id: I46ebb495cb093a5e3abe7571c49933c845318549
Previously, the func created a rule and returned it for the caller to
create with the appropriate name and description. This change passes
the name and description into the func and causes it to create the rule
itself. The func is also renamed to make it more consistent with the
other similar rules.
Bug: 179354495
Test: m nothing
Change-Id: I2a4455daa8a6090ed5568994b255848d063e1ab2
Lint's NewApi checks currently produce a lot of false positive findings.
The filtered lint database removes information of classes defined by
mainline modules which are the cases that might become a false positive.
This commit updates soong to use this database instead of the normal one
when linting mainline modules.
Test: m lint-check
Fixes: 186478867
Change-Id: Ica646081b9189303c393b36b2f02914d69eee291
Although the hidden API runtime does not support a module-lib API flag
the hidden API processing does need to used them as they are needed by
the "hiddenapi list" tool for any bootclasspath_fragment module whose
contents builds against an sdk_version of "module_current". Without it
the "hiddenapi list" tool could fail to resolve references to classes
provided by other modules which would break the build.
Bug: 179354495
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that this change has no effect on the generated flags.
Change-Id: I3ecb80fdaeba0e66d1ee25cb57152ab546d9bfe0
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, a java_sdk_library with shared_library = true would create
a variation per APEX because it depends on an sdkLibraryXml module
which generates a file containing the APEX name. However, a shared
java_sdk_library_import would create a merged APEX variation. The
inconsistent variations caused failures in sdkDepsReplaceMutator.
This change ensures that both java_sdk_library and
java_sdk_library_import create an APEX specific variation when their
shared_library property is true.
Bug: 190499958
Test: m nothing
- ran the above command after modifying the test to reproduce the
problem and then after fixing to verify that it fixed the problem.
Change-Id: Iee81776a8569db3e871c40cbde14d248dfeb56e4
Previously, an sdk snapshot could contain the following:
* A java_sdk_library_import module, e.g. "foo" which creates component
modules "foo.stubs", etc.
* A corresponding versioned module, e.g. "sdk_foo@current" which
created component modules "sdk_foo@current.stubs", etc.
* An internal (to the sdk snapshot) java_import for one of "foo"'s
components, e.g. "sdk_foo.stubs"
* A corresponding versioned module, e.g. "sdk_foo.stubs@current".
That causes a few problems:
1. The "foo.stubs" is duplicated.
2. The names of the components created by the versioned
java_sdk_library_import are invalid, as they append the component's
suffix to the version and not the name before the version.
The latter causes problems when building against prebuilts and fixing
that causes the generated snapshot to be invalid because it contains
duplicate definitions of the "sdk_foo.stubs@current" module. One
explicitly in the Android.bp file and one created by the
"sdk_foo@current" module.
Removing the duplicates from the snapshot causes errors as the name
generated by the snapshot for the component module, i.e.
"sdk_foo.stubs@current" does not match the name generated by the
"sdk_foo@current", i.e. "sdk_foo@current.stubs".
This change fixes them together.
Bug: 179354495
Test: m nothing
Merged-In: I515f235fe21755b5275af12366e96c24c94c0273
Change-Id: I515f235fe21755b5275af12366e96c24c94c0273
(cherry picked from commit a1aa7387f7)
Previously, an sdk snapshot could contain the following:
* A java_sdk_library_import module, e.g. "foo" which creates component
modules "foo.stubs", etc.
* A corresponding versioned module, e.g. "sdk_foo@current" which
created component modules "sdk_foo@current.stubs", etc.
* An internal (to the sdk snapshot) java_import for one of "foo"'s
components, e.g. "sdk_foo.stubs"
* A corresponding versioned module, e.g. "sdk_foo.stubs@current".
That causes a few problems:
1. The "foo.stubs" is duplicated.
2. The names of the components created by the versioned
java_sdk_library_import are invalid, as they append the component's
suffix to the version and not the name before the version.
The latter causes problems when building against prebuilts and fixing
that causes the generated snapshot to be invalid because it contains
duplicate definitions of the "sdk_foo.stubs@current" module. One
explicitly in the Android.bp file and one created by the
"sdk_foo@current" module.
Removing the duplicates from the snapshot causes errors as the name
generated by the snapshot for the component module, i.e.
"sdk_foo.stubs@current" does not match the name generated by the
"sdk_foo@current", i.e. "sdk_foo@current.stubs".
This change fixes them together.
Bug: 179354495
Test: m nothing
Change-Id: I515f235fe21755b5275af12366e96c24c94c0273
The commonSdkLibraryAndImportModule defines the methods that a module
which embeds the commonToSdkLibraryAndImport struct need to provide.
Bug: 179354495
Test: m nothing
Merged-In: I7a469ae03ea5c19922200284da08a9ae38a46751
Change-Id: I7a469ae03ea5c19922200284da08a9ae38a46751
(cherry picked from commit 71b33cca9d)
Adds support for printing a PropertySet that has a property whose value
is an array of structs.
Bug: 179354495
Test: m nothing
m conscrypt-module-sdk
- check generated Android.bp file
Change-Id: I71be04188465610bcbea4d3c9a5e8204171a1eeb
Bug: 158843648
Test: check if dexpreopt.config for the module defined in mk file has
DexPreoptImageLocationsOnDevice field
Change-Id: Idb2de398871ff114245393a9dd92b5a1b5c942e7
The commonSdkLibraryAndImportModule defines the methods that a module
which embeds the commonToSdkLibraryAndImport struct need to provide.
Bug: 179354495
Test: m nothing
Change-Id: I7a469ae03ea5c19922200284da08a9ae38a46751
Added test demonstrates the error case. The bug was that java modules'
ShouldSupportSdkVersion() converts min_sdk_version into effective
version before comparison, which discards "preview" version into
"future" version. That caused a weird case like rejecting with error
"should support "S"" even when it is set to "S".
Bug: n/a
Test: m nothing
Change-Id: Ieb53f0097b2969a8535778b1286dbfa0d4895ad4
Any apex classpath fragment that doesn't generate its own classpaths
proto, must still propagate it's boot jars for the platform classpath
fragment to include for complete CLASSPATH variables on device.
Bug: 191127295
Test: atest CtsClasspathsTestCases derive_classpath_test
Change-Id: I93687f69006741fcd66eb6e04891a4b4bbcc3b47
Prebuilt modules do not provide classesJars containing annotations.
Previously, the monolithic hidden API processing just used classesJars
from all the modules that provided them so when building against
prebuilts would have fewer classesJars than when building against
sources and so would produce different hidden API flags.
This change will generate the monolithic files from both classesJars
and files previously generated from hidden API processing. A fragment
that has performed hidden API processing will contribute its generated
files whereas standalone libraries and fragments which have not
performed hidden API processing will contribute classesJars.
Bug: 177892522
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
m SOONG_CONFIG_art_module_source_build=false out/soong/hiddenapi/hiddenapi-flags.csv
- verify that the files are identical whether built from
source or prebuilts.
Merged-In: I06f3c7df49626bec21a452bc9abf1bb9e7545e5c
Change-Id: I06f3c7df49626bec21a452bc9abf1bb9e7545e5c
(cherry picked from commit d061d40eb6)
Adds a message parameter and allows leading spaces in the expected file
string to allow them to be nicely indented.
Bug: 177892522
Test: m nothing
Merged-In: I33df26610738c48879fa0b8250dc377dd04bb07d
Change-Id: I33df26610738c48879fa0b8250dc377dd04bb07d
(cherry picked from commit 51d7da2c4e)
