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, bootclasspath_fragment modules would only perform hidden
API processing if they provided some stub libraries and fragments. That
was needed because the bootclasspath_fragment modules were added before
Soong supported hidden API processing on all the different modules and
before they all provided the necessary information that hidden API
processing required.
This change stops hidden API being conditional as it is no longer
required as it has been enabled on all existing bootclasspath_fragment
modules.
Bug: 179354495
Test: m nothing
Change-Id: Ibf81a7de63b888a3ebf445528326fa6101fdb1ba
Previously, bootclasspath_fragment modules would only perform hidden
API processing if they provided some stub libraries and fragments. That
was needed because the bootclasspath_fragment modules were added before
Soong supported hidden API processing on all the different modules and
before they all provided the necessary information that hidden API
processing required.
This change stops hidden API being conditional as it is no longer
required as it has been enabled on all existing bootclasspath_fragment
modules.
Bug: 179354495
Test: m nothing
Change-Id: I0cbf11986adff1f2f967b96f86e6bfe0e9b8b1ef
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
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.
Merged-In: Ib137825ebffe94b2bf220732bae6077f7b7ac6db
Change-Id: Ib137825ebffe94b2bf220732bae6077f7b7ac6db
(cherry picked from commit 280a31aac3)
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
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
Merged-In: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
Change-Id: Ia8b79830ed0e6d42100de03d76b0c51b7f6c8ade
(cherry picked from commit 5cca7c44e5)
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.
Merged-In: I97968f58535121652852b8d25217aa288afd2bfd
Change-Id: I97968f58535121652852b8d25217aa288afd2bfd
(cherry picked from commit 31fad800a7)
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
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
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
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
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)
Previously, the prebuilt art-bootclasspath-fragment did not provide any
boot image files. That meant it was impossible to build any module that
requires access to those files from prebuilts, e.g. any module that
needs to be dexpreopt-ed.
This change enables that module to retrieve those files from the
prebuilt_apex.
Bug: 177892522
Bug: 189298093
Test: m nothing
m droid SOONG_CONFIG_art_module_source_build=false SKIP_BOOT_JARS_CHECK=true
- the previous command does not work but this change does fix one
of the issues reported.
Merged-In: I1d4d9545172d79282918130df6b9aa55471bffc1
Change-Id: I1d4d9545172d79282918130df6b9aa55471bffc1
(cherry picked from commit 5466a3699c)
Previously, the boot dex jars were only copied to the predefined
locations used by the build from the source art-bootclasspath-fragment
if it was preferred, otherwise no files were copied. That caused build
failures when attempting to build with ART prebuilts. This change
copies the files from prebuilts too.
Bug: 177892522
Bug: 189298093
Test: m nothing
m droid SOONG_CONFIG_art_module_source_build=false SKIP_BOOT_JARS_CHECK=true
- the previous command does not work but this change does fix one
of the issues reported.
Merged-In: I35b37355170546daf6ecac2134d1ca9a73d0e3bc
Change-Id: I35b37355170546daf6ecac2134d1ca9a73d0e3bc
(cherry picked from commit ce918b0278)
Removes some unnecessary logic left over from previous changes.
Bug: 177892522
Test: m nothing
Merged-In: Id11e2ea8a647283af1b152b33757132e44dcd6c3
Change-Id: Id11e2ea8a647283af1b152b33757132e44dcd6c3
(cherry picked from commit 58e7586b3d)
Previously, the rules to perform hidden API encoding were generated
separately to the rules to perform hidden API flag generation. This
change combines them within the (renamed) produceHiddenAPIOutput()
method and makes the paths to the encoded dex files an output of the
generateHiddenAPIBuildActions method alongside the paths to the
generated flag files.
As encoded dex jars are now an output of the produceHiddenAPIOutput()
method which is implemented for both prebuilts and source
bootclasspath_fragment modules that necessitated the prebuilt also
providing paths to encoded dex files. That in turn required updates to
some of the tests to provide dex files from prebuilt_apex modules.
Similarly, as the produceHiddenAPIOutput() method may not be called
for some bootclasspath_fragment modules as they do not yet provide all
the information needed to perform hidden API encoding then it is
necessary to extract the encoded dex files produced by the modules
themselves. That also required a few changes to tests that did not
previously provide dex files.
Bug: 177892522
Test: m com.android.art
- check that this change does not change the contents of the apex
file, i.e. is byte-for-byte identical.
Merged-In: I60996a34d06ed1c87ed244ab3509621999ad86ec
Change-Id: I60996a34d06ed1c87ed244ab3509621999ad86ec
(cherry picked from commit e521881bd4)
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
Change-Id: I5dc77c8fb272bac289b8891d1eac801e541af1f5
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
Change-Id: I5cc341b5b4168b8eb196f72273a00d498de6856f
Previously, the prebuilt art-bootclasspath-fragment did not provide any
boot image files. That meant it was impossible to build any module that
requires access to those files from prebuilts, e.g. any module that
needs to be dexpreopt-ed.
This change enables that module to retrieve those files from the
prebuilt_apex.
Bug: 177892522
Bug: 189298093
Test: m nothing
m droid SOONG_CONFIG_art_module_source_build=false SKIP_BOOT_JARS_CHECK=true
- the previous command does not work but this change does fix one
of the issues reported.
Change-Id: I1d4d9545172d79282918130df6b9aa55471bffc1
Previously, the boot dex jars were only copied to the predefined
locations used by the build from the source art-bootclasspath-fragment
if it was preferred, otherwise no files were copied. That caused build
failures when attempting to build with ART prebuilts. This change
copies the files from prebuilts too.
Bug: 177892522
Bug: 189298093
Test: m nothing
m droid SOONG_CONFIG_art_module_source_build=false SKIP_BOOT_JARS_CHECK=true
- the previous command does not work but this change does fix one
of the issues reported.
Change-Id: I35b37355170546daf6ecac2134d1ca9a73d0e3bc
Previously, the rules to perform hidden API encoding were generated
separately to the rules to perform hidden API flag generation. This
change combines them within the (renamed) produceHiddenAPIOutput()
method and makes the paths to the encoded dex files an output of the
generateHiddenAPIBuildActions method alongside the paths to the
generated flag files.
As encoded dex jars are now an output of the produceHiddenAPIOutput()
method which is implemented for both prebuilts and source
bootclasspath_fragment modules that necessitated the prebuilt also
providing paths to encoded dex files. That in turn required updates to
some of the tests to provide dex files from prebuilt_apex modules.
Similarly, as the produceHiddenAPIOutput() method may not be called
for some bootclasspath_fragment modules as they do not yet provide all
the information needed to perform hidden API encoding then it is
necessary to extract the encoded dex files produced by the modules
themselves. That also required a few changes to tests that did not
previously provide dex files.
Bug: 177892522
Test: m com.android.art
- check that this change does not change the contents of the apex
file, i.e. is byte-for-byte identical.
Change-Id: I60996a34d06ed1c87ed244ab3509621999ad86ec
Previously, an []android.Module was converted to an []hiddenAPIModule
that was then used to retrieve boot dex jars. That was ok when
obtaining the dex jar files from source modules for
bootclasspath_fragment but does not work well for other use cases as
it would require doing that conversion in multiple places.
This change pushes the use of hiddenAPIModule down to the methods that
retrieve information from it which makes the methods more flexible and
easier to reuse.
Bug: 177892522
Test: m nothing
Change-Id: Ib84aaf03d8f5a63b48232036fe4589646fc23352
Merged-In: Ib84aaf03d8f5a63b48232036fe4589646fc23352
(cherry picked from commit dd5993f6d4)
Previously, copyBootJarsToPredefinedLocations relied on all its
parameters having the same length and the same order. That made it
quite fragile as changes to one of the parameters without corresponding
changes to the other would cause failures. It also combined the
retrieval of the boot dex jars from the modules, handling of missing
boot dex jar files and the generation of the rules to copy the files.
This change separates the retrieval of boot dex jars and handling of
missing files from the copying of those files while at the same time
making the function less fragile by replacing the three ordered
parameters with two maps that shared common keys.
Bug: 179354495
Test: m nothing
Merged-In: Idbcd24a7e8af89f7895a20aeddc58502dcbaad03
Change-Id: Idbcd24a7e8af89f7895a20aeddc58502dcbaad03
(cherry picked from commit 5f148ca7cf)
This will export some hidden api related types and fields so they can
be used from outside the java package. This is needed to allow a follow
up change to move the TestPlatformBootclasspath_Fragments from the java
to the apex package.
Bug: 179354495
Test: m nothing
Merged-In: Ib69eea9d79cc83b8e3fc29919a29f071e1ec17b5
Change-Id: Ib69eea9d79cc83b8e3fc29919a29f071e1ec17b5
(cherry picked from commit 524c82c01a)
Add apex dependencies.
Bug: 188004865
Test: 1. aidegen frameworks/base/apex/appsearch frameworks/base/apex/appsearch/testing frameworks/base/services/tests/servicestests frameworks/base/core/tests/coretests cts/tests/appsearch external/icing vendor/google_testing/integration/tests/scenarios
2. The dependency graph shows it is workable to provide the result to let IDE's [Project structure] to include the service-appsearch as source directory.
Change-Id: Ifd1548f0a86c1c73f8279e8ecea67756aeb1281e
Previously, an []android.Module was converted to an []hiddenAPIModule
that was then used to retrieve boot dex jars. That was ok when
obtaining the dex jar files from source modules for
bootclasspath_fragment but does not work well for other use cases as
it would require doing that conversion in multiple places.
This change pushes the use of hiddenAPIModule down to the methods that
retrieve information from it which makes the methods more flexible and
easier to reuse.
Bug: 177892522
Test: m nothing
Change-Id: Ib84aaf03d8f5a63b48232036fe4589646fc23352
Previously, copyBootJarsToPredefinedLocations relied on all its
parameters having the same length and the same order. That made it
quite fragile as changes to one of the parameters without corresponding
changes to the other would cause failures. It also combined the
retrieval of the boot dex jars from the modules, handling of missing
boot dex jar files and the generation of the rules to copy the files.
This change separates the retrieval of boot dex jars and handling of
missing files from the copying of those files while at the same time
making the function less fragile by replacing the three ordered
parameters with two maps that shared common keys.
Bug: 179354495
Test: m nothing
Change-Id: Idbcd24a7e8af89f7895a20aeddc58502dcbaad03
This will export some hidden api related types and fields so they can
be used from outside the java package. This is needed to allow a follow
up change to move the TestPlatformBootclasspath_Fragments from the java
to the apex package.
Bug: 179354495
Test: m nothing
Change-Id: Ib69eea9d79cc83b8e3fc29919a29f071e1ec17b5
As long as we have boot jars defined in make, we should try to keep
global.UpdatableBootJars as a source of truth when it comes to classpath
configuration. However, for testing purposes there is a need to add
java libraries to bootclasspath that aren't present in
PRODUCT_UPDATABLE_BOOT_JARS variable.
Ideally, we would unconditionally add all contents to the config for
test apexes, however, I don't fully understand apex merging to support
it.
Bug: 180105615
Test: atest sdkextensions_classpaths_e2e_tests
Change-Id: I552f93289c27b3713e75dcda1faed909b0bfcef2
Merged-In: I552f93289c27b3713e75dcda1faed909b0bfcef2
(cherry picked from commit 1b75a3ce62)
As long as we have boot jars defined in make, we should try to keep
global.UpdatableBootJars as a source of truth when it comes to classpath
configuration. However, for testing purposes there is a need to add
java libraries to bootclasspath that aren't present in
PRODUCT_UPDATABLE_BOOT_JARS variable.
Ideally, we would unconditionally add all contents to the config for
test apexes, however, I don't fully understand apex merging to support
it.
Bug: 180105615
Test: atest sdkextensions_classpaths_e2e_tests
Change-Id: I552f93289c27b3713e75dcda1faed909b0bfcef2
Coverage is applied to java libraries that are directly in an apex.
Mark java libraries that are in an apex through a bootclasspath_fragment
or a systemserverclasspath_fragment as directly in the apex by
implementing CopyDirectlyInAnyApexTag on the dependency tags used for
their contents.
Bug: 183759446
Test: TestApexJavaCoverage
Change-Id: I0116f5f415083b5194000988cb257454ef115200
Merged-In: I0116f5f415083b5194000988cb257454ef115200
(cherry picked from commit c33e5216f1)
* changes:
Treat java libraries in classpath fragments as directly in apex
Make CopyDirectlyInAnyApex match the documentation
Remove unused cc.copyDirectlyInAnyApexDependencyTag
