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
When a java_sdk_library module is added, both impl jar and permission
xml files are packaged together.
For example, when a java_sdk_library "foo" is listed, following two
entries will be in an APEX package.
/javalibs/foo.jar
/etc/permissions/foo.xml
Bug: 145474221
Test: m com.android.cronet
deapexer list com.android.cronet.apex
Change-Id: If5883c02255e9309f20810b1532d3fbe73bf4e95
In case that an apex module depends on a module with stubs directly
*and* indirectly, the build system should follow the deps graph further.
Note that WalkDeps() visits deps in DFS and it won't visit again visited
modules.
Bug: n/a
Test: m (apex_test.go amended)
Change-Id: I1a6f135dbda6d1eb641575a3fbbc9bbee0622076
This change fixes a bug that LOCAL_PATH for modules included in an APEX
is set to the path of the APEX bundle, not to the path of the embedded
module. For example, LOCAL_PATH of libconscrypt included in
com.android.adbd was set to /system/core/adb instead of
/external/boringssl. This caused a problem that NOTICE file in
/external/boringssl is not tagged to libconscrypt, but the NOTICE file
for adbd is.
Fixing the problem by recording the module directories of the included
modules and emitting it in LOCAL_PATH.
Bug: 145347092
Test: Settings -> About Phone -> Legal Information -> Third-party
license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is
OpenSSL.
Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
APEXes with "legacy_android10_support" will have apex_manifest.json for
compatibility as well as apex_manifest.pb.
Bug: 143951586
Test: m (soong tests)
Change-Id: I019252aee5a9423f4b180ba1026e6e99c9961437
GSI targets are supposed to have both 'flattened' and 'unflattened'
APEXes. By adding 'flattened' APEX as REQUIRED moduled for 'unflattened'
APEX, both will be installed togetther.
This is done by a new variable PRODUCT_INSTALL_EXTRA_FLATTENED_APEXES,
which is set only for GSI targets.
Bug: 137802149
Test: lunch aosp_arm64-userdebug && m
resulting apex images under /system/apex
and flattened apexes under /system/system_ext/apex
Change-Id: I336e2674e427b358542e0045b2a49dfa3d84095b
Previously, it was defaultable only for cc_library. Now, it is
defaultable for all module types.
Bug: 128708192
Test: m
Change-Id: If248f593da6f4b724bf889ccd7f2e077d48069b5
This change is to make it easier to add new fields to the struct.
transitiveDep field is added to distinguish apexFiles coming from
transitive dependencies of the APEX. We will later use the info to
reduce the size of bundled APEXes by replacing the transitive deps with
symlinks to the corresponding files in the system partition outside of
the APEX.
Bug: 144533348
Test: m
Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
This build rule is specific to platform APEXes.
For non-platform APEXes, MakeAsSystemExt() is not applied.
This fixes the cases of "soc_specific: true" apexes which fails to
build.
Bug: 139053989
Test: m nothing (soong tests)
Change-Id: I98d0257499647ab41cdaa62a3671d89addbdf833
Exempt-From-Owner-Approval: got +1 before rebasing
When an override_apex named Foo overrides an apex module named Bar, the
Make modules from Foo have Foo as their suffix. Previously the suffix
was Bar for both of the overriding and the overridden APEXes, causing
name conflicts in the Make side.
Bug: 144338929
Test: apex_test.go
Change-Id: I1396910ab294ba5f5e0585af6d37f1eab9460250
For platform APEXes, file_contexts should point a file under
/system/sepolicy.
Bug: 144732805
Test: m
Change-Id: Ib2d5db715bbebc80a6178d1c42e387b268cc4a0d
prebult_etc module type does not respect prefer32, i.e. its primary arch
is 64-bit on 64/32-bit device even when built with TARGET_PREFER_32_BIT
is true. However, the apex module type respects prefer32 and therefore
when TARGET_PREFER_32_BIT is true its primary arch becomes 32-bit. Then
the problem is that the apex tries to depend on 32-bit variant of the
prebuilt_etc modules which don't exist.
Fixing the problem by force using the first arch of the device when
adding dependencies to prebuilt_etc modules.
Bug: 144532908
Test: choosecombo 1 aosp_arm64 userdebug; TARGET_PREFER_32_BIT=true m;
Change-Id: I7642c57b05a837495587bbe4d3589d8549607862
Prepare for making the image mutator available to all modules and
moving it between the os and arch mutators by moving it into the
android package and using an interface implemented by the module
types to control it.
Bug: 142286466
Test: No unexpected changes to out/soong/build.ninja
Change-Id: I0dcc9c7b5ec80edffade340c367f6ae4da34151b
override_apex module type is used to override existing apex module with
certain properties overridden. Currently, only the 'apps' property is
overridable.
Bug: 144338929
Test: m
Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
apex.go is too big. Separate the build rule and android.mk generation
logic into builder.go and androidmk.go, respectively. prebuilt_apex is
moved to prebuilt.go as well.
No refactoring has been made other than the splitting.
Test: m
Change-Id: I839ab0a1ba2b70ce82d98ac1fa8e3534808b5fd3
