Previously, the prebuilt_bootclasspath_fragment was not required to
provide hidden API files as not all usages of that module provided
them. That should no longer be the case so this change makes the
prebuilt_bootclasspath_fragment stricter and so now always require
them.
Bug: 194063708
Test: m out/soong/hiddenapi/hiddenapi-flags.csv
- check that this does not change the contents.
Change-Id: I3f19a1b4246f09a927c0f6b0f41b8678150d6cc2
Previously, the test only checked how the intermediate index file was
created from class jars. This change also checks how the monolithic
index file was created from the intermediate index file and the index
files generated from each bootclasspath_fragment.
At the moment the checks reveal that the monolithic index file is
created solely from the intermediate index file. However, a follow up
change to Soong will alter the behavior of the test.
Bug: 194063708
Test: m nothing
Change-Id: I343712d7d17ab0a07f5b32226321fc6815847e1f
apexBundle was missing InitBazelModule for it to have bazel_module properties.
Test: soong unit test
Fixes: 193866723
Change-Id: I5fb38c8b2e8edaecef44162491d399c0223d3fb1
Previously, the java_import and java_sdk_library_import modules did not
make their permitted_packages available to the rule that generates the
updatable-bcp-packages.txt file. This change corrects that.
Bug: 193763688
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Change-Id: If0706e4551a331b48d383123088e63924dded48b
Even though actual installed module path is the same as source module,
it uses impl's one.
Bug: 188179858
Bug: 193082464
Test: compare dexpreopt_config.zip files from
1. TARGET_BUILD_UNBUNDLED_IMAGE=true m dexpreopt_config_zip
2. m dexpreopt_config_zip
(note that m clean should run between steps)
Test: build aosp_cf_x86_64_phone, launch_cvd, and then
adb wait-for-device \
&& adb root \
&& adb logcat \
| grep -E 'ClassLoaderContext [a-z ]+ mismatch' -C 1
and then check if there is no message.
Change-Id: I34ffd9a2d214a6614c2befc35b2beec003cfcd25
APEX files are sized as 4K-aligned so that they can be passed to Guest
OS via block apexes.
Bug: 192991318
Test: check size of built APEX files
Change-Id: I32d988f3cdf2717dbebd87b2ced01840e07a3a9b
Without these errors, the last encountered deapexer would silently be
used, and we wouldn't know if it was taken from the prebuilt APEX that
actually get installed in the system image.
With this error check there may be only one enabled prebuilt_apex or
apex_set for each apex_name (which defaults to the module name). E.g.
if there are both prebuilt com.android.foo and com.google.android.foo,
it is necessary to disable one of them in the .bp file.
Merged-In is set from https://r.android.com/1745454, a change that has
gone into AOSP and internal master, as well as sc-dev-plus-aosp, but
specifically not sc-dev. This change cannot merge into sc-dev-plus-aosp
and others, because they may or may not have the com.google.android.art
prebuilt APEX present depending on manifest, and with this check
exactly one of com.android.art and com.google.android.art prebuilts has
to be present and enabled. It'll be cherry-picked to AOSP along with a
full fix for b/192006406, when it can be safely enabled everywhere.
Test: m nothing SOONG_CONFIG_art_module_source_build=false
Test: m nothing SOONG_CONFIG_art_module_source_build=true
Test: m nothing
with enabled:true for the com.android.art prebuilt APEX - check that
it fails with an "ambiguous duplicate deapexer" error
Bug: 192006406
Bug: 192542393
Change-Id: I44566fd26b12f82a8a67fe4a69e56303460756d0
Merged-In: Id2410b4e38a78ec2146a42298840954381a7c472
Revert submission 1733232-roboleaf-apex
Reason for revert: b/192523357 Broken build 7512065 on aosp-master on sdk_x86_64-sdk
Reverted Changes:
Ie82c263f6:Add a stub rule for building APEX bundles.
I93e2a25fa:Add partial bp2build support for APEX targets.
Change-Id: I8e836fe7f466e02f3108680f9653412299e929e0
Previously, when determining which dependencies, direct or transitive,
of a prebuilt_apex/apex_set required APEX variants the code assumed
that all dependencies implemented ApexModule. While that is true for
the modules that can be explicitly mentioned in the exported...
properties it is not true for all of them. e.g. A
prebuilt_apex/apex_set can depend on license modules which do not
implement ApexModule.
This change simply ignores any module that does not implement
ApexModule.
Bug: 179354495
Test: m nothing
Merged-In: Iead6f9d1085d169335b88ceadcce2d8cc042254d
Change-Id: Iead6f9d1085d169335b88ceadcce2d8cc042254d
(cherry picked from commit fee8cf36e3)
Previously, when determining which dependencies, direct or transitive,
of a prebuilt_apex/apex_set required APEX variants the code assumed
that all dependencies implemented ApexModule. While that is true for
the modules that can be explicitly mentioned in the exported...
properties it is not true for all of them. e.g. A
prebuilt_apex/apex_set can depend on license modules which do not
implement ApexModule.
This change simply ignores any module that does not implement
ApexModule.
Bug: 179354495
Test: m nothing
Change-Id: Iead6f9d1085d169335b88ceadcce2d8cc042254d
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)
Add an apex_name property to prebuilt APEX modules to allow specifying
the "runtime" name of the APEX, i.e. the one it gets mounted as in /apex/,
which is also the one used for the apex variations.
Introduce a callback to retrieve that name consistently for all APEX
modules (apex, override_apex, prebuilt_apex, and apex_set), and update
some apex mutator code paths to use it.
For APEX source modules (apex and override_apex), it's necessary to add
a new field in apexBundle, since the name property gets overridden for
the override variant that override_apex creates.
Cherry-picked from https://r.android.com/1748294.
Test: m nothing
Bug: 191269918
Change-Id: If8612639bffdf91cbcab3387b0603bf5dffef1f5
Merged-In: If8612639bffdf91cbcab3387b0603bf5dffef1f5
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.
Merged-In: I3ecb80fdaeba0e66d1ee25cb57152ab546d9bfe0
Change-Id: I3ecb80fdaeba0e66d1ee25cb57152ab546d9bfe0
(cherry picked from commit b51db2ed8e)
Adds a test to establish a baseline for a follow up change that adds
module_lib support to hidden API processing.
Bug: 179354495
Test: m nothing
Merged-In: I5630075825c674b2e4f38bd459c7b061c01fc362
Change-Id: I5630075825c674b2e4f38bd459c7b061c01fc362
(cherry picked from commit 48b6741510)
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)
Add an apex_name property to prebuilt APEX modules to allow specifying
the "runtime" name of the APEX, i.e. the one it gets mounted as in /apex/,
which is also the one used for the apex variations.
Introduce a callback to retrieve that name consistently for all APEX
modules (apex, override_apex, prebuilt_apex, and apex_set), and update
some apex mutator code paths to use it.
For APEX source modules (apex and override_apex), it's necessary to add
a new field in apexBundle, since the name property gets overridden for
the override variant that override_apex creates.
Test: m nothing
Bug: 191269918
Change-Id: If8612639bffdf91cbcab3387b0603bf5dffef1f5
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
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
Adds a test to establish a baseline for a follow up change that adds
module_lib support to hidden API processing.
Bug: 179354495
Test: m nothing
Change-Id: I5630075825c674b2e4f38bd459c7b061c01fc362
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
The property is used to allow non-updatable APEXes to use platform APIs
(e.g. symbols marked as "# platform-only").
Bug: 191637950
Test: m com.android.virt com.android.compos
Merged-In: Id2410b4e38a78ec2146a42298840954381a7c472
Change-Id: Id2410b4e38a78ec2146a42298840954381a7c472
(cherry picked from commit fb63625a7f)
This change fixes a bug that rust module in APEX has access to private
symbols of a native library even when the native library is outside of
the APEX.
To fix this, the stub selection logic in the cc package is exctacted as
a function ChooseStubOrImpl and is used also in the rust package.
Bug: 190767845
Test: m
Merged-In: I5c4cbdd5d27f257ab329d9dadbcd87d41a87f46a
Change-Id: I5c4cbdd5d27f257ab329d9dadbcd87d41a87f46a
(cherry picked from commit 3b5f88e091)
The property is used to allow non-updatable APEXes to use platform APIs
(e.g. symbols marked as "# platform-only").
Bug: 191637950
Test: m com.android.virt com.android.compos
Merged-In: Id2410b4e38a78ec2146a42298840954381a7c472
Change-Id: Id2410b4e38a78ec2146a42298840954381a7c472
(cherry picked from commit fb63625a7f)
This change fixes a bug that rust module in APEX has access to private
symbols of a native library even when the native library is outside of
the APEX.
To fix this, the stub selection logic in the cc package is exctacted as
a function ChooseStubOrImpl and is used also in the rust package.
Bug: 190767845
Test: m
Merged-In: I5c4cbdd5d27f257ab329d9dadbcd87d41a87f46a
Change-Id: I5c4cbdd5d27f257ab329d9dadbcd87d41a87f46a
(cherry picked from commit 3b5f88e091)
