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
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
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
Apps that expect to run on older platforms should use JNI libraries
that will also run on older platforms. Require that apps that set
sdk_version have jni_libs modules that also set sdk_version, or
set jni_uses_platform_apis: true to bypass the check.
Fixes: 149591057
Test: app_test.go
Change-Id: I76b9b45fb5773bc4dfc10520108f4f3578723909
As a second step to removing the go/android3p instructions to copy or
to link NOTICE to LICENSE, include LICENSE files in the notices, which
will allow deleting all of the copied/linked NOTICE files.
The change causes a few additions to the system image notice files.
Test: manually built and compared before and after notices
Change-Id: Ia7bc58e2eba7bed5e63934881b5298201a93bc3e
This will allow installing Q launched APEXes built from master on Q
devices.
Test: m com.android.conscrypt
Test: see another CL in topic
Test: lunch blueline-userdebug
Test: TARGET_BUILD_APPS=com.android.resolv m
Test: installed on Q blueline, verified installation succeeded
Bug: 149733822
Change-Id: Ia863b5701716ef4022b470ee758368ea4fffb1d4
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
