bind mounts create administrivia in /proc/mounts that can not be
easily discerned to confirm expectations. We squash the stutter,
and filter out overlay backing references for /system/<path>/<file>.
Test: adb-remount-test.sh
Bug: 122737045
Change-Id: I61342f5f76f54a1a8201a52efb8054acde100a6f
*/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 way the list of exported symbols will be limited by symbols
that need to be exported.
Test: make
Change-Id: Iffc8e0b3b589e78f5d213f75971a54b473760c94
Consolidate the checking of /proc/<pid>/smaps_rollup support
in libmeminfo and do it in a thread safe way.
Use the API in ProcMemInfo as well to eliminate the extra
parameters passed to SmapsOrRollup* methods.
Bug: 111694435
Test: libmeminfo_test 1 --gtest_filter=TestProcMemInfo.IsSmapsSupportedTest
Test: Tested with and without the smaps_rollup support in kernel.
Change-Id: I992057f06b54569025fa0cdade9618da2675d1de
Merged-In: I992057f06b54569025fa0cdade9618da2675d1de
Signed-off-by: Sandeep Patil <sspatil@google.com>
The Vma and ProcMemInfo objects do not need separate stats
objects for storing working set. The Vma either has working set
or memory usage information and never both.
Bug: 111694435
Test: libmeminfo_test 1
Change-Id: I2df05f7e750bbba4325474633e705d6d68dd2ccb
Merged-In: I2df05f7e750bbba4325474633e705d6d68dd2ccb
Signed-off-by: Sandeep Patil <sspatil@google.com>
Caused by passing invalid parameters to getline(3) and the test
failure went unnoticed.
Bug: 111694435
Test: libmeminfo_test 1 --gtest_filter=TestProcMemInfo.ForEachVmaFromFileTest
Change-Id: Ideb39604c58f89237b05d2f7c8edb67c5ae65768
Merged-In: Ideb39604c58f89237b05d2f7c8edb67c5ae65768
Signed-off-by: Sandeep Patil <sspatil@google.com>
I7d47ea1223f7792a834981c729694242ab3f28c9 tried to identify processes that crash
after apexd is ready by introducing an 'updatable' class. However, after
I7ca67755dc0656c0f0c834ba94bf23ba9b1aca68 we now have a pre_apexd_ field we can
reuse instead of introducing a new class type.
Bug: 120598832
Test: Killing a !pre_apexd_ process 4 times in 4mins sets the
ro.init.updatable.crashing prop while killing a pre_apexd_ process reboots
into the bootloader
Change-Id: Icb9f405b9b54d11546bbf6d3bc28212936a78b0e
In order to move the library into the runtime APEX.
Test: m and boot
Bug: 119840313
Bug: 122710865
Change-Id: I4aac5954d2fb5f9e3ba92e486d69f1e76614df92
In case some power supply paths should not be considered, add a black list
to the healthd_config to instruct BatteryMonitor of the power supply paths
to ignore on init.
Bug: 117903348
Change-Id: I6f9ddeff9351ad01772b43728ddc2627da81df2a
Signed-off-by: Thierry Strudel <tstrudel@google.com>
This will let us clean up a lot of external/*/OWNERS files by
indirecting them through here.
Test: N/A
Change-Id: Ieda353b78deeb94baeab6306b6a734b63484d351
Before, this process had no threadpool, so it could make blocking
calls, but if it did, they would block forever. Now when this
happens, an error is logged so that we can easily see this happen.
Bug: 36424585
Test: boot
Change-Id: I7d2fa12b6d5a243bdde13ce4d974a444133749f7
Also remove some tests for implementation details in the libdexfile API that
are now covered by unit tests there (http://r.android.com/867370).
Test: mmma system/core/{libunwindstack,libbacktrace} and run host gtests
Bug: 119632407
Change-Id: Ie731bb929a564de56ce1c78385da12a43d0954ff
This change adds an install-atomic command to adb that is shorthand for
creating an atomic install session and an individual session for each
APK supplied to the command.
Bug: 109941548
Test: run command with multiple APKs, observe atomic install
Change-Id: I2817a1ed2d312925d9c7bd621e6c82670a6275fd
* changes:
Don't create separate mount namespaces for pre-apexd processes
Bionic libs are located at /system/lib
Bionic libs and the dynamic linker are bind mounted
It is causing problem to the sdcardfs. Specifically, re-mounting events
for /mnt/runtime/{runtime|write} done by the vold process (which is a
pre-apexd process) are not being propagated to other mount namespaces.
As a result, SDCard access isn't working.
The propagation problem is a bug in sdcardfs which is fixed by [1].
However, we can't make all Android devices to have the patch at the same
time. Therefore, by default the separate mount namespace is not created
and will be created only for the devices where the kernel patches are in and
ro.apex.bionic_updatable sysprop is set to true.
[1]
d73d07673edbdbe78e1a7d00e7827ba9bfd86a59 ("ANDROID: mnt: Fix next_descendent")
b5858221c1c4f4bdc9ef67eb75ecf22580368820 ("ANDROID: mnt: remount should propagate to slaves of slaves")
Bug: 122559956
Test: m
Test: device boots
Test: sdcard works (e.g. camera can take pictures)
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Change-Id: I7a309bab46356ee5782f34c5963d1760963c0b14
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
