If a library is statically included in a static executable, it's
behavior is different from the case where the same library is statically
(or dynamically) linked to a non-static executable. To reduce the number
of test configs that we need to consider, it is required to prohibit
static executables in APEXes.
Bug: 185971244
Test: m
Change-Id: I0cd8fca669d55088e2329fef1f859eeb297502dd
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: 193095050
Test: m nothing
- Added unit tests, which all failed and then fixed the tests.
Merged-In: If0706e4551a331b48d383123088e63924dded48b
Change-Id: If0706e4551a331b48d383123088e63924dded48b
(cherry picked from commit 630b11e9d4)
Note that ART apex boot jars and core-icu4j are exceptions here as they
are not part of ApexBootJars. ART apex boot jars are defined in their
own variable, while core-icu4j is treated as a regular non-updatable
boot jar.
Bug: 191127295
Test: atest CtsClasspathsTestCases
Change-Id: I3cea3d82ef521655a1a5ffa8cae2258ab9d08bfc
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
