Checking apex_available was missing some corner cases.
For example, the deps of share deps of cc_library modules are missed
while those from cc_library_shared are correctly tracked.
This was due to..
* calling DepIsInSameApex in WalkDeps: both work fine separately, but
when they are used together, it fails to work. It's due to how WalkDeps
works. (We might fix this bug too risky since it is used very widely)
* incorrect receiver for DepIsInSameApex in apex_deps mutator: receiver
is supposed to be parent, but child was used before. Interestingly lots
of deps are within the same group of module types(cc to cc, java to
java), it has worked. (note that receiver's DepIsInSameApex
implementation can be different).
This change fixes them by..
* walkPayloadDeps is now relying on ApexVariation, which is calculated
correctly by TopDown apex_deps mutator.
* use correct receiver for DepIsInSameApex in apex_deps mutator, which
requires for java.SdkLibrary to override the method and for
java.Library/Import to use passed dep instead of receiver to check its
membership of sdk.
Bug: 151071238
Test: build/boot
Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
The whitelistedApexAvailable used to map references to
com.android.art.debug/release to com.android.art before looking it up
in the white list. This change removed that mapping and simply added
both to the white list.
Bug: 142935992
Test: m nothing
Change-Id: Ibad76fb73988688eb303e056197986ee9a6119ae
When the check for apex_available has failed, the build system now shows
the module that brought the unavailable module into the APEX.
Bug: 151051671
Test: m
Merged-In: Id1a3fda67fe56fdc2dc90ec800d10689415de4d6
(cherry picked from commit 7bd9444b0f)
Change-Id: Id1a3fda67fe56fdc2dc90ec800d10689415de4d6
When the check for apex_available has failed, the build system now shows
the module that brought the unavailable module into the APEX.
Bug: 151051671
Test: m
Change-Id: Id1a3fda67fe56fdc2dc90ec800d10689415de4d6
sdk_version is passed for relevant variants.
If not specified or "current",
it maps to "10000" for platform variants, and
"min_sdk_version" of the apex for apex variants.
Bug: 150860940
Test: m (soong test)
manually check build.ninja
Change-Id: I5102ab0c5086b5ad29d16ac45af55d32062167b4
Native modules within APEX should be linked with proper stub version
according to its min_sdk_version.
For example, when min_sdk_version is set to "29", libfoo in the apex
would be linked to libbar of version 29 from platform, even if it has
a newer version like 30.
Bug: 145796956
Test: m nothing (soong tests)
Change-Id: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
Add a min_sdk_version property apexes. Currently a noop, but will
be used to enforce that dependencies are compatible with the
specified version.
Test: m checkbuild
Bug: 149591522
Merged-In: I923773c90fe15becbffae3986791aa9edde8f8f6
Change-Id: I923773c90fe15becbffae3986791aa9edde8f8f6
(cherry picked from commit 50317874ff)
apex { name: "foo" }
override_apex { name: "override_foo", base:"foo" }
PRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES := foo:com.android.foo
Previously, the override was done only for the overridden package "foo",
but not for "override_foo". Fixing this issue by using ctx.ModuleName()
when finding the package name to use.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 150645663
Test: m
Merged-In: I2947e5c75369216a4bbce8749503236be86771c3
(cherry picked from commit a519c54dd3)
Change-Id: I2947e5c75369216a4bbce8749503236be86771c3
apex { name: "foo" }
override_apex { name: "override_foo", base:"foo" }
PRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES := foo:com.android.foo
Previously, the override was done only for the overridden package "foo",
but not for "override_foo". Fixing this issue by using ctx.ModuleName()
when finding the package name to use.
Bug: 150645663
Test: m
Change-Id: I2947e5c75369216a4bbce8749503236be86771c3
This is rarely used feature but cost alot for the local build and build
inra.
Bug: 150506627
Test: m
Change-Id: Iec3ada4a97c7b228f2818563fa0e81b407f2715a
When there is a runtime depedency (via runtime_libs property) to a
library providing stable C APIs, the dependency is considered as
crossing APEX boundary. Therefore, the requested lib doesn't need to be
made available to the APEX where the requesting lib is in.
Bug: 147813447
Test: m
Change-Id: I9cf8a5877850fb85b92c851e15fac921b8b7641b
If an APEX contains APKs and the manifest package name of the APKs are
overridden (either via override_android_app
orPRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES), that the path to the APK
(relative in the APEX) and the overridden manifest package name is
recorded in the bundle config file.
Exempt-From-Owner-Approval: cherry-pick from master
Bug: 148002117
Test: m
Merged-In: Ibb90bcefb77fa6b2dad77cb2facc6079de9ab154
(cherry picked from commit cfaa1643e8)
Change-Id: Ibb90bcefb77fa6b2dad77cb2facc6079de9ab154
bundle config file for apexes are auto-generated. It is included in the
<apex>-base.zip file, which is expected to be extracted and then fed
into the bundletool.
This change is in preparation for the upcoming change to include
information about embedded apks in the bundle confir file.
Exempt-From-Owner-Approval: cherry-pick from master
Bug: 148002117
Test: m
Merged-In: If25d75e0f62036dc777faf8593ed8eb9a74950b0
(cherry picked from commit bd15961043)
Change-Id: If25d75e0f62036dc777faf8593ed8eb9a74950b0
If an APEX contains APKs and the manifest package name of the APKs are
overridden (either via override_android_app
orPRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES), that the path to the APK
(relative in the APEX) and the overridden manifest package name is
recorded in the bundle config file.
Bug: 148002117
Test: m
Change-Id: Ibb90bcefb77fa6b2dad77cb2facc6079de9ab154
bundle config file for apexes are auto-generated. It is included in the
<apex>-base.zip file, which is expected to be extracted and then fed
into the bundletool.
This change is in preparation for the upcoming change to include
information about embedded apks in the bundle confir file.
Bug: 148002117
Test: m
Change-Id: If25d75e0f62036dc777faf8593ed8eb9a74950b0
Using $(call dist-for-goals,droidcore,...) for every apex
installed-files.txt causes every apex to be built for all builds,
causing a signficiant regression in build time. For now only
dist them in checkbuilds, which were going to build all of them
anyways.
Ideally we would like to dist the installed-files.txt only if
the apex was already built, but there is not currently a way to
express that.
Test: treehugger
Bug: 149979076
Change-Id: I21edbc90980f94ad6d497cb86ee80223dd782fe1
Merged-In: I21edbc90980f94ad6d497cb86ee80223dd782fe1
(cherry picked from commit 1c85e8e019)
Which is the list of JNI libraries that are embeded inside the apex.
jni_libs is handled just like native_shared_libs except that it is
stored in apex_manifest.
When linkerconfig finds an apex with JNI libs, it exposes the namespace
for the apex as visible so that libnativeloader can link the namespace
to the corresponding classloader-namespace.
Bug: 149363889
Test: m nothing(runs soong test)
Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
Embed common properties (apexNativeDependencies) so that the logic for
adding dependencies for native modules can be reused.
Bug: N/A
Test: m
Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
ensureExactContent shouldn't return immediately when it finds a match
from expected list of files.
Bug: N/A
Test: m nothing
Change-Id: Ie15c811f9cfcae7ede28dee0fcf203cee24659a0
