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
Symlinking doesn't make sense for host APEXes.
Bug: 150255435
Test: m com.android.art.host and inspect the built APEX; there is
no symlink.
Merged-In: I28492dfaaef471117a430be05255fbef76e557b0
(cherry picked from commit 9b96418dfe)
Change-Id: I28492dfaaef471117a430be05255fbef76e557b0
Symlinking doesn't make sense for host APEXes.
Bug: 150255435
Test: m com.android.art.host and inspect the built APEX; there is
no symlink.
Change-Id: I28492dfaaef471117a430be05255fbef76e557b0
Because APK-in-APEX embeds its jni_libs in it. We don't have to follow
deps of jni_libs.
Bug: 146992436
Test: m com.android.tethering
deapexer extract com.android.tethering.apex apex
ls apex # there should be no /lib dir
Merged-In: Ifa1a6430a420ae7376b155cd59b8ece462cced7e
Change-Id: Ifa1a6430a420ae7376b155cd59b8ece462cced7e
(cherry picked from commit b7bebe2616)
Because APK-in-APEX embeds its jni_libs in it. We don't have to follow
deps of jni_libs.
Bug: 146992436
Test: m com.android.tethering
deapexer extract com.android.tethering.apex apex
ls apex # there should be no /lib dir
Change-Id: Ifa1a6430a420ae7376b155cd59b8ece462cced7e
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
Change-Id: I923773c90fe15becbffae3986791aa9edde8f8f6
The optimization is confusing syshealth because the modules will use
more memory when they are switched to the prebuilt (unbundled) or
updated via Play.
Let's have a per-module switch to control the behavior and turn it on
only for non-updatable modules like ART.
Bug: 149805758
Test: m
Change-Id: Ieb842c47f31f3b06e403b1e1f9e463c3e5524107
This change fixes a regression that was introduced with
I597bccbb177b6b6320c3a3edeff467243230d384. With the change, the content
of the permissions XML file for a java_sdk_library was determined before
the java_sdk_library is mutated for an APEX. As a result, the file path
to the implementation jar library was always set to
/system/framework/*.jar regardless of whether the java_sdk_library is
part of an APEX or not.
This change fixes the problem, by creating the permissions XML file via
a new module type. The content of the xml file is determined after the
xml file is mutated for APEXes.
Bug: 149600642
Test: m
Change-Id: Id21f8d8285df49b0b3be1daf0f101f2bc978eeb0
Bug: 149075752
Test: tapas com.android.conscrypt com.android.tethering arm64
Test: m out/target/product/generic_arm64/{,symbols/}apex/com.android.{tethering,conscrypt}/lib64/libc++.so
Test: Verified that unwinder was dynamically linked to tethering's
Test: libc++ and statically linked to conscrypt's.
Test: lunch flame-userdebug && m
Test: Verified that unwinder was dynamically linked to /system/lib64/libc++.so
Change-Id: I98eed7cb4316962b19b5c12e150c224c25d0e91d
apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }
apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.
libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.
As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.
Fixing the problem by changing the mutator a top-down one.
Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
The apex dependency map wasn't updated for test or non-installable
APEXes to work around the problem that a module being in such APEX
prevented the module from being installed in the system partition.
Since that problem is not happening any more, removing the unnecessary
work-around.
Bug: 123892969
Test: m
Change-Id: I43e07a9611a3e08ff39b9a64454b1c67949d35bc
This library is empty, and its functionality has moved
into libbinder/libhwbinder.
Bug: 148692216
Test: N/A
Change-Id: I5874efda9ab43fc00cf90395a1aabde45cf49579
