This change moves the definitions of the following libraries which
directly include ART, conscrypt and i18n stubs, and their associated
java_system_modules from libcore to build/soong/java/core-libraries.
* core.current.stubs
* core-current-stubs-system-modules
* core.module_lib.stubs
* core-module-lib-stubs-system-modules
* legacy.core.platform.api.stubs
* legacy-core-platform-api-stubs-system-modules
* stable.core.platform.api.stubs
* stable-core-platform-api-stubs-system-modules
Bug: 193311122
Test: m droid
Change-Id: I42c4a0b5322897d40ecf41de088152dbdc526c96
Previously, when building from prebuilts boot no rules were created to
produce the boot image files for the host, i.e. the OS on which the
build was running. That caused problems with checkbuilds. No rules were
produced as there was no host variant of a prebuilt apex to provide
them.
This change restructures the code to allow the prebuilt bootclasspath
fragment to build the host variants of the files from the dex files
provided by the prebuilt APEX. The generated files will not be the same
as they would be if built from source as there is no boot image profile
to use but it should be sufficient to satisfy the checkbuild target and
allow for host side testing.
Bug: 192575099
Test: m SOONG_CONFIG_art_module_source_build=false droid dist checkbuild
Change-Id: I6af00f19bb71aa18dd462f5eac6aa38e3e721023
Previously, boot image generation used GetCachedGlobalSoongConfig(ctx)
in order to get access to the GlobalSoongConfig. That required that
some other part of the code had called GetGlobalSoongConfig(ctx) to
initialize the cached value. That was left over from when the boot
image generation was done in a singleton which could not call
GetGlobalSoongConfig(ctx) directly. That is no longer true.
This change switches the uses of GetCachedGlobalSoongConfig(ctx) to
GetGlobalSoongConfig(ctx) and removes the now unnecessary call to
GetGlobalSoongConfig(ctx) from outside the functions.
Bug: 192575099
Test: m nothing
Change-Id: I34b7b1526d072d8b09fda7caa96e381695888e16
Previously, the boot zip file, containing all the boot image files for
all the supported architectures, was only created from source. It was
not created when building from a prebuilt_bootclasspath_fragment. That
lead to build failures when building from ART prebuilts.
This change pulls the boot zip file creation out so that it can be done
for both source and prebuilt bootclasspath_fragment modules as well as
for the platform_bootclasspath module.
Bug: 192575099
Test: m out/target/product/generic_arm64/boot.zip
m SOONG_CONFIG_art_module_source_build=false out/target/product/generic_arm64/boot.zip
- Compare the output of the first command from before the change
with the output from them both after and confirm that when the
ART prebuilts are up to date with the source that there are no
differences.
Change-Id: Ie7dd5e2ca4a865d06fd9ebf87320cf68c4d05bc3
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
When generating zip archive with zip2zip wildcard mask is specified.
Bash attempts to resolve wildcard **/*.class. If android build
top directory containts subfolder(s) with .class, bash wildcard
resolution succeeds. Bash passes list of files to zip2zip instead
of actual wildcard. Created archive doesn't contain required files.
Adding quotes to wildcard to prvent that.
Bug: NA
Test: manual - build with coverage enabled
Change-Id: Iebdaa32693fe820f0f79588d61cb89660ea2b611
Sometimes the stem property is set to change both the installed file
name and the name use to filter the configured module list, e.g. when
adding a test library to replace the standard library, e.g. test_foo
instead of foo.
Sometimes it is used just to change the installed file name.
This change uses both to filter the updatable boot jars and not just
the stem.
Bug: 180105615
Test: m nothing
Change-Id: I6c459fc3597b1e4f062bc9a4e52843305b538c5f
The target is used to generate api_versions.xml file used by Android
Lint, point it to the system stubs in prebuilts/sdk/.
Bug: 190665366
Test: m framework-doc-system-stubs
Change-Id: I27fbad9eb1d84792901974674cbd85f0994bc9f1
Before this fix, compiling a java_library against sdk_version:
"module_current" can't use the @SystemApi(MODULE_LIBRARIES) provided
by the ART module because the system module "core-current-stubs-system-modules"
contains only the public APIs.
Use the new system module with module lib APIs.
Bug: 183097033
Test: m droid
Change-Id: I274e2710d1ff34e896aa620bfafb4481180c53b5
srcFiles is passed to Lint, and given it both the srcjars and the
expanded sources from the srcjars confuses it about which files are
generated. Remove srcjars from srcFiles after handling them.
Bug: 192245952
Test: m lint-check
Change-Id: Ic57d1c623f4cac7cd79f1342bac4b51bd2535ac3
Unless the prebuilt dex jar files are explicitly required to build
system images or dex preopting defer reporting of any missing dex boot
jars from Soong to Ninja.
This will prevent builds that contain prebuilt sdks, containing prebuilt
bootclasspath_fragment modules but without a corresponding apex_set or
prebuilt_apex module from failing even when it is not building against
the prebuilt sdk.
Bug: 179354495
Test: m nothing
Change-Id: Ibde3bf840a7413785cd32bd6cea1c322f90c59af
Now, android_app_import can use apk from other modules like genrule.
Bug: 192200378
Test: m com.android.compos
Change-Id: I5823fdb53b6aa20bfd9ec4dd16aafe63e65b6b68
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
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)
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
