Getting it back in line with the normal ld.config.txt. This was missed in
http://r.android.com/854740.
Test: Flash and boot on marlin
Bug: 119867084
Bug: 113373927
Change-Id: Ic7e482133250eda20ff2c94c27bdee30e015ab5c
Support netd to load resolv Apex.
Switch namespaces when switching library paths between
/system and the APEX, so that internal library dependencies in both
locations are loaded from their own directory.
Bug: 119527674
Test: make; flash; lsof -p $(pidof netd)
Test: 1. manual test datacall/wifi work
2. manual test tethering work
3. system/netd/tests/runtests.sh
Change-Id: I3f69e85f2f529636f0ef29a2d9d71ad582c46dfb
Move APEX symlink creation to alternative module, one that
is targeted at /system not /. Also added comments to reflect
the tenuous connection between the module chosen and the
symlink creation.
Tested with:
rm -rf out/target/product/taimen/system \
&& make droid \
&& ls -l out/target/product/taimen/system/usr
Test: See above
Bug: 122985829
Bug: 123333111
Change-Id: I841dd42827ac2e082505ebf039f40fd394514e54
This change adds new socket declarations to the init scripts for the
Zygote processes. This socket is used for communication between the
System Server and the Blastula pool.
Bug: 68253328
Topic: zygote-prefork
Test: build image; flash device; launch apps
Change-Id: I5dbb87770b1a3100c6c122bb39ca854006bb0b0d
Merged-In: I5dbb87770b1a3100c6c122bb39ca854006bb0b0d
* changes:
Make libdexfile_external.so accessible from binaries and libraries in /system.
The runtime namespace needs to be visible since libopenjdk is loaded through dlopen().
There are dependencies on libdexfile_external from some central libraries
that are widely used (b/123186083).
One example is vendor/bin/hw/android.hardware.media.omx@1.0-service, which
requries the link from "system" to "runtime" in the [vendor] section.
The direct dependants are libunwindstack and simpleperf, so it's enough to
link from namespaces containing /system/{lib,lib64,bin}.
Test: Flash and boot
Test: Flash and boot with Runtime APEX enabled (http://r.android.com/q/topic:art-move-libs-to-runtime-apex)
Bug: 123186083
Bug: 113373927
Change-Id: I081aa7392c875202acdaf1185c2ff28e17ac7e76
The ICU .dat file was moved into the runtime APEX file
in commit b6d855f081c232309961f31c7c7c8a76abf79c3c.
There are some apps that know the old location and its
absence causes them to fail.
This change adds a symlink from the old directory to
the new directory. The ICU .dat file changes its name
with every ICU major release so this is simpler than
linking the file itself.
Bug: 119293618
Bug: 120853401
Bug: 122985829
Test: make droid / inspect output
Test: Confirm broken app works on an internal master build
Change-Id: I452dcb5e52975011c9ebd3db2caa621bbefedaf3
Regardless of VNDK version, use template ld.config.txt instead of
using prebuilt ld.config.txt.
Bug: 74658756
Bug: 123209911
Test: PRODUCT_EXTRA_VNDK_VERSIONS=27 m -j vndk_snapshot_package
Change-Id: I0eb527b71e56c555079c524542508a093bf53111
This reverts commit 67a09e5791.
Exempt-From-Owner-Approval: Fixes P0 failures.
Bug: 123185917
Reason for revert: media namespace needs to be introduced.
Change-Id: I0c28798a3143c1e627278c3a908207e670171416
And have the linker translate a java library path from an apex
to a linker namespace.
Bug: 122874359
Test: m, boots, gtest, run-test, CtsJdwpTests
Change-Id: I216c3509c45589d28acdac068aec53877aeb104a
Exempt-From-Owner-Approval: Carrying Jiyong's +2
It depends on libdexfile_external, libnative{bridge,helper,loader} and
libart(d), which are provided by the Runtime APEX.
Test: flash & boot
Test: atest CtsJdwpTestCases
Bug: 113373927
Change-Id: I0df99f444e892c47a5f06bd1bcf5d184defb4517
This will be used for system internals to access
secondary volumes without having to bypass sdcardfs.
This reverts commit 54b8844b13
Bug: 121277410
Test: manual
Change-Id: Id5b995dc5899b5999f1dea662ba1c3ee475a0e46
It's replaced with entries in PRODUCT_PACKAGES_DEBUG in
build/make/target/product/base_system.mk
Test: treehugger
Change-Id: I4dc69c34ddc2c494fc74bc4afee6efa240c9b0d3
This reverts commit 2599088ff6.
Reason: Breaks some 3p apps.
Bug: 122920047
Test: run the app, login.
Change-Id: Idea332b1f91e9d2ac6ebd3879da7820c8ba2284f
*/build.prop files are now loaded much earlier than before; from 'on
post-fs' to the time when the property service is started which is
before init starts the action loop.
This ensures that all processes that are launched by init have a
consistent view of system properties. Previously, the processes that
started before 'on post-fs' were initially with the small number of
sysprops loaded from */default.prop and then suddenly get additional
sysprops from */build.prop while they are executing.
Bug: 122714998
Test: device boots
Change-Id: Ic07528421dfbe8d4f43673cea41175d33cfbf298
This will be used for system internals to access
secondary volumes without having to bypass sdcardfs.
Bug: 121277410
Test: manual
Change-Id: I6546fa8df419157b3c2adcf5ff3faa4db4458cff
Bionic libs, regardless of whether they are bootstrap ones or from the
runtime APEX, are available via /system/lib. Since /system/lib is in the
search paths of the default(platform) namespace, there is no need to
list the bionic libs to the namespace link to the runtime namespace.
Bug: 120266448
Test: m; device boots
Test: atest CtsJniTestCases CtsCompilationTestCases CtsBionicTestCases
all passing except for following tests that are also failing at ToT
dl#exec_linker
dl#exec_linker_load_from_zip
dl#exec_linker_load_self
dl#exec_linker_load_file
Change-Id: Ib67acd4f384b2f0e70b5fe8ec6b45a5506367223
This change makes the bionic libs and the dynamic linker from the
runtime APEX (com.android.runtime) available to all processes started
after apexd finishes activating APEXes.
Specifically, the device has two sets of bionic libs and the dynamic
linker: one in the system partition for pre-apexd processes and another
in the runtime APEX for post-apexd processes. The former is referred as
the 'bootstrap' bionic and are located at
/system/lib/{libc|libdl|libm}.so and /system/bin/linker. The latter is
referred as the 'runtime' bionic and are located at
/apex/com.android.runtime/lib/bionic/{libc|libdl|libm}.so and
/apex/com.android.runtime/bin/linker.
Although the two sets are located in different directories, at runtime,
they are accessed via the same path: /system/lib/* and
/system/bin/linker ... for both pre/post-apexd processes. This is done
by bind-mounting the bootstrap or the runtime bionic to the same path.
Keeping the same path is necessary because there are many modules and
apps that explicitly or implicitly depend on the fact that bionic libs
are located in /system/lib and are loaded into the default linker
namespace (which has /system/lib in its search paths).
Before the apexd is started, init executes a built-in action
'prepare_bootstrap_bionic' that bind-mounts the bootstrap bionic to the
mount points. Processes started during this time are provided with the
bootstrap bionic. Then after the apexd is finished, init executes
another built-in action 'setup_runtime_bionic' which again mounts the
runtime bionic to the same mount points, thus hiding the previous mounts
that target the bootstrap bionic. The mounting of the runtime bionic
(which is only for post-apexd processes) is hidden from pre-apexd
processes by changing propagation type of the mount points to 'private'
and execute the pre-apexd processes with a new mount namespace using
unshare(2). If a pre-apexd process crashes and re-launched after the
apexd is on, the process still gets the bootstrap bionic by unmounting
the runtime bionic which effectively un-hides the previous bind-mounts
targeting the bootstrap bionic.
Bug: 120266448
Test: device boots
Test: cat /proc/`pidof zygote`/mountinfo shows that
/system/lib/{libc|libdl|libm}.so and /system/bin/linker are from the
runtime APEX
Test: cat /proc/'pidof vold`/mountinfo shows that the same mount points
are from system partition.
Change-Id: I7ca67755dc0656c0f0c834ba94bf23ba9b1aca68
For consistency with APKs, signature verification is performed
in the system_server. This includes checking that the signature of
an updated install matches the signature of the active package that
it updates. For this, it requires search access to /data/apex and
read access to the files under that directory.
Test: m
Change-Id: I8795b26b9a40ba7126c2a548fbec82ff322a1453
