This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is set to the platform variant when creating the APEX variations.
3) The ApexAvailableWhitelist is added with the dependencies that were
revealed with this change.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 147671264
Test: m
Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
(cherry picked from commit fa89944c79)
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
This reverts commit a952495643.
Reason for revert: PermissionController may need to be built outside of APEX
Fixes: 148957736
Change-Id: I80a2cd666ea5028741250dd2cebf2bd7d7b331ad
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is set to the platform variant when creating the APEX variations.
3) The ApexAvailableWhitelist is added with the dependencies that were
revealed with this change.
Bug: 147671264
Test: m
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
apex module accepts PlatformCompatConfigIntf as prebuilt,
and places it in the etc folder of the apex.
Test: m
Test: flash device with dummy config in mediaprovider APEX -
the config is present
Change-Id: Ifc62cd262f6c6571c1bf6c2943879aa20877ecad
Leaving out LOCAL_CERTIFICATE for flattened apex APKs causes
the apkcerts.txt to have empty keys for those APKs, which
confuses the signing tools. Set LOCAL_CERTIFICATE for them.
Also refactor the Certificate support to avoid introducing
duplicated handling for presigned certificates.
Bug: 147765187
Test: m apkcerts-list
Change-Id: Ife07661761cd5a89c9f009b8ce041db4dff9ec54
This change fixes a bug that license info for non-flattened APEXes are
not captured in /system/etc/NOTICE.xml.gz file. For non-flatted APEXes,
we have been creating NOTICE.html.gz file by concatenating all the
license infos of the modules that contributes to the APEX and embedding
the file into the asset directory of the APEX. Then at runtime, the info
is shown through the "Google Play System Update Licenses" UI. However,
this was problematic because the UI only shows license info for the
Google-signed APEXes, leaving OEM-signed APEXes (a.k.a. optional
modules).
The problem is now fixed by associating a merged license file with each
APEX and exporting them to Make, so that the merged license files are
included in the partition level /system/etc/NOTICE.xml.gz file
regardless of whether the APEX is a Google-signed one or not.
This also fixes a bug that license info entries are created for the
runtime paths /apex/<apex_name>/<path_to_a_file>, which is not necessary
as they are already included in the license info of the containing APEX.
Bug: N/A
Test: Go to Settings->About Phone->Legal information and check
that a) /system/apex/*.apex files are shown and b) /apex/<apex_name>/*
files are not shown
Change-Id: I2c25c803b6a4c39b24bb3f724502699382fab50c
This reverts commit 5df3b11f78.
Reason for revert: re-land with a fix
Fix a broken soong test
Add implicit dependency (libprofile-clang-extra) to make a test pass.
Bug: n/a
Test: m
Change-Id: I0b179199bc032501354f8e24782837453781bd8c
VNDK APEX is supposed to contain "vendor" variants of VNDK libraries.
This is different from normal APEXes which have "apex" variants.
Bug: 146758869
Test: build / flash / boot
Change-Id: I5e035678c337334092616b58d2e0e404788a6639
Exempt-From-Owner-Approval: Got ORV, but rebased with resolving merge conflicts.
This reverts commit 31c65d4fe4.
Bug: 144533348
Test: checkout master-art-host and run
ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist /art/tools/dist_linux_bionic.sh -j80 com.android.art.host
the result is successful
Change-Id: Ica11eec9b64867088b16720a41c6d83905976ec5
This means everything that goes into apexes need to be
explicitly labeled to be available for apex.
Whitelist the current offenders. This list should be
trimmed down.
Bug: 147364041
Test: m
Test: multiproduct_kati -only-soong
Exempt-From-Owner-Approval: cherry-pick from internal
Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
(cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
Used in coverage builds.
Test: NATIVE_COVERAGE=true \
EMMA_INSTRUMENT_FRAMEWORK=true \
EMMA_INSTRUMENT=true \
m nothing
Change-Id: I6309d8149fce016eb9689326eeae221914e4c3bb
This means everything that goes into apexes need to be
explicitly labeled to be available for apex.
Whitelist the current offenders. This list should be
trimmed down.
Bug: 147364041
Test: m
Test: multiproduct_kati -only-soong
Exempt-From-Owner-Approval: Just added more whitelist entries
Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
This reverts commit 7cb4d378e7.
Test: m
Test: ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist ./art/tools/dist_linux_bionic.sh -j80 com.android.art.host
(in the master-art-host branch)
Change-Id: I9beca73aafdf42f03bfa19cf1634b2641dac417b
This reverts commit 956305c61c.
Reason for revert: broke master-art-host branch
Exempt-From-Owner-Approval: reverting a bad change
Change-Id: Id7faed4ee85328c7c65847a3543ea9e67a3d50b3
For each APEX, <apexname>-installed-files.txt is dist'ed to show the
list of files and their sizes that are included in the APEX.
Bug: 147605944
Test: m dist and examine the txt files
Change-Id: I565479523e51280fc88d5fbf8ea3f48ac0ae9fee
This change fixes a bug that jacoco-report-classes-all.jar does not
include info for APK-in-APEX such as the MediaProvider apk in
com.android.mediaprovider APEX.
Firstly, LOCAL_SOONG_JACOCO_REPORT_CLASSES_JAR is correctly set also for
the APKs included in APEXes. Secondly, the Make modules for the embedded
APKs are now built with soong_app_prebuilt.mk to correctly import the
jacoco file into the Make world.
Bug: 147296855
Test: execute the following command in internal master.
$ choosecombo cf_x86_phone userdebug
$ NINJA_ARGS="-t path out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar" EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m
The result shows that there is a path as follows:
out/target/product/vsoc_x86/jacoco-report-classes-all.jar
out/target/product/vsoc_x86/apex/com.android.mediaprovider/priv-app/MediaProvider/MediaProvider.apk
out/target/product/vsoc_x86/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/package.apk
out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar
Change-Id: I52d11534a34eb35219bfafca4453e75a1b701c0e
When prebuilt_apex overrides/replaces other apex, the same symlinks need
to be created as well.
Bug: 143192278
Test: 1. add prebuilt_apex with vndk apex
with overrides set as ["com.android.vndk.current"]
2. m <prebuilt apex>
3. check if vndk symlinks are created
Change-Id: I8ee9c981ea9c7202ccf5143b3f43e6848773cd63
When a module is included in an APEX and the module is not directly
installed to the system partition, the 'required' property of the module
is lost. The APEX containing the module now carries the property from
its dependencies.
Bug: 146549048
Test: m
Change-Id: Ie21cc7b8420c6126c855e66c2363644de4a7ef42
We need to have a way to see the list of modules that directly or
indirectly contribute to an APEX. People find it difficult to determine
whether a module is included in which APEXes because APEX tracks
indirect dependencies as well as direct dependencies. Therefore, just
looking at Android.bp for the APEX itself doesn't give the answer.
This change adds a new make target <apex_name>-deps-info, which
generates out/soong/<apex_name>-deps-info.txt file that shows the
internal and external dependencies of the said APEX.
Here, internal means the dependencies are actually part of the
APEX, while external means the dependencies are still external to the
APEX.
Bug: 146323213
Test: m (apex_test amended)
Change-Id: I33d1ccf5d1ca335d71cd6ced0f5f66b8c3886d13
Create an APEX variation of a module only when it is either directly
included in an APEX or the dependency to the module demands that the
module should be included. For example, a non-static dependency to a
java library no longer creates an APEX variant of the library.
Bug: 146907857
Test: m (apex_test amended)
Test: cat out/soong/build.ninja | grep "Module:" | wc -l
reduced from 47132 to 45881
Change-Id: Icd79fb4b60668d852b9f018343b934b5e42a8eda
Permission XML file for java_sdk_library is generated by
java_sdk_library itself now.
And, build rule is switched to android.WriteFile since "echo -e" is
not supported from build server. (-e is printed to output)
Bug: 145474221
Test: m com.android.cronet and check its permissions xml file
also, m org.chromium.net.cronet.xml (created dynamically)
Change-Id: Iffb119151c49bc4fe6c4386fa267cca193f37dbc
java_import doesn't support dex jar which is necessary to be packaged in
an APEX. Supporting this would require non-trivial work. By the way
java_import is not used and there is a workaround.(defining java_library
and static-linking with it)
We drop the support for `java_import` in APEX.
Bug: 139175488
Test: m (soong tests amended)
Change-Id: I924386571079090c701276d87f665ce7fbb6f074
