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
Bug: 158843648
Test: check if dexpreopt.config for the module defined in mk file has
DexPreoptImageLocationsOnDevice field
Change-Id: Idb2de398871ff114245393a9dd92b5a1b5c942e7
Merged-In: Idb2de398871ff114245393a9dd92b5a1b5c942e7
(cherry picked from commit e3165c8de3)
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, 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)
Use classpath elements in newMonolithicHiddenAPIInfo. That means the
method can collate information from both fragments and libraries rather
than just fragments. So, this change moves the collation of the
classesJars into the method.
Bug: 177892522
Test: m out/soong/hiddenapi/hiddenapi-flags.csv out/soong/hiddenapi/hiddenapi-index.csv
- make sure that this change does not affect the contents.
Merged-In: I7c2a229fab60d02bd211438735a8d7303ed83386
Change-Id: I7c2a229fab60d02bd211438735a8d7303ed83386
(cherry picked from commit 89f570ac44)
Some build configurations do not configure boot jars. In those cases
the boot jars package check fails so should be skipped.
Bug: 177892522
Test: m nothing
lunch fvp_mini && m
Change-Id: I5498a8f5cdfb2fabf5223e94dfcee0e853059d01
Uses the apex relative path to the file as the identifier that is used
to obtain the path to the corresponding file extracted from the apex.
That is instead of a special constructed string id.
Bug: 177892522
Test: m nothing
Merged-In: I5dc77c8fb272bac289b8891d1eac801e541af1f5
Change-Id: I5dc77c8fb272bac289b8891d1eac801e541af1f5
(cherry picked from commit b4bbf2ca10)
Removes the special case in createDeapexerModuleIfNeeded for handling
java libraries and just get the Import and SdkLibraryImport module
types to implement RequiredFilesFromPrebuiltApex instead.
Bug: 177892522
Test: m nothing
Merged-In: I5cc341b5b4168b8eb196f72273a00d498de6856f
Change-Id: I5cc341b5b4168b8eb196f72273a00d498de6856f
(cherry picked from commit fef5500a76)
