Keys may be required for apex updates (post-installs), so load them
before starting apexd.
Bug: 125474642
Test: m
Test: manual
Change-Id: I32ddb6ae6854334e8ee7e195173ecfaed565d783
Bind-mounting of the bionic files on /bionic/* paths no longer required
as there are direct symlinks from bionic files in /system partition to
the corresponding bionic files in the runtime APEX. e.g.,
/system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
Bug: 125549215
Test: m; devices boots
Change-Id: I4a43101c3e3e2e14a81001d6d65a8a4b727df385
This CL change the mini-keyctl tool to make it compitable with libkeyctl
tool to make it more useful.
Bug: 112038861
Test: mini-keyctl padd asymmetric 'desc' .fs-verity < /path/to/cert.der
Test: mini-keyctl unlink <key_id> <keyring_id>
Test: mini-keyctl restrict_keyring <keyring_id>
Change-Id: I950f07c7718f173823ce5a5cd08e0d1a0e23a007
This directory is used to store the Weaver/GateKeeper slot map so GSIs
do not overwrite host keys in secure storage.
Bug: 123716647
Test: /metadata/password_slots exists after boot
Change-Id: Ib0ca13edec38e68cba1fc2124465571feedc4be7
Summary: Boot sequence around apexd is changed to make it possible for
pre-apexd processes to use libraries from APEXes. They no longer need to
wait for the apexd to finish activating APEXes, which again can be
done only after /data/ is mounted. This improves overall boot
performance.
Detail: This change fixes the problem that processes that are started
before apexd (so called pre-apexd processes) can't access libraries
that are provided only by the APEXes but are not found in the system
partition (e.g. libdexfile_external.so, etc.). Main idea is to activate
system APEXes (/system/apex/*.apex) before /data is mounted and then
activate the updated APEXes (/data/apex/*.apex) after the /data mount.
Detailed boot sequence is as follows.
1) init prepares the bootstrap and default mount namespaces. A tmpfs is
mounted on /apex and the propagation type of the mountpoint is set to
private.
2) before any other process is started, apexd is started in bootstrap
mode. When executed in the mode, apexd only activates APEXes under
/system/apex. Note that APEXes activated in this phase are mounted in
the bootstrap mount namespace only.
3) other pre-apexd processes are started. They are in the bootstrap
mount namespace and thus are provided with the libraries from the system
APEXes.
4) /data is mounted. init switches into the default mount namespace and
starts apexd as a daemon as usual.
5) apexd scans both /data/apex and /system/apex, and activate latest
APEXes from the directories. Note that APEXes activated in this phase
are mounted in the default namespaces only and thus are not visible to
the pre-apexd processes.
Bug: 125549215
Test: m; device boots
Change-Id: I21c60d0ebe188fa4f24d6e6861f85ca204843069
/apex is not mounted via init.rc but directly by the first_stage init
before the mount namespaces are configured.
This allows us to change the propagation type for /apex mount point to
private to isolate APEX activatesions across post- and pre-apexd
processes.
Bug: 125549215
Test: m; device boots to the UI
Change-Id: I10e056cd30d64cb702b6c237acd8dab326162884
To differentiate IO priority for different groups.
Bug: 111422845
Bug: 117857342
Test: tasks are assigned to the group as expected
Change-Id: Ibb108d1b8e0f720f7ac4cab248b3c33d35e5483d
tzdatacheck references files in the runtime apex so should
not be executed before the apex mounts are ready.
Test: Manual tests (see b/123270813); observed tzdatacheck running after
apex files are mounted
Bug: 123270813
Bug: 116191025
Bug: 119293618
Bug: 113373927
Change-Id: I249d127c1d568bc5025d81b0bb4187c81363d897
This change fixes the problem that apexd is delaying the entire boot
sequence while waiting for the loopback devices to be created. The delay
was as big as 50 ms per a loopback device.
With this change, apexd is started much earlier: from "on post-fs-data"
to "on init". When it is first started, it scans /system/apex to
determine the number of APEXes and creates that number of loopback
devices priori. Since then it enters into the binder loop.
When the data partition is mounted, init lets apexd to initiate the
apexd boot sequence where APEXes in /data is scanned, verified, and
activated. Since the creation of the loopback devices were requested far
before, it is very likely that dev nodes for the devices are ready at
this moment (even if not, this isn't a lose).
Bug: 123404717
Bug: 123772265
Test: compare boot times.
init_zygote_START_TIME_avg is improved from 2831ms to 2622ms on blueline
Change-Id: I12450cee44aa4d17a11def62261c2f82d3f2c718
The sys.use_memfd property is set by default to false in Android
to temporarily disable memfd, till vendor and apps are ready for it.
The main issue: either apps or vendor processes can directly make ashmem
IOCTLs on FDs they receive by assuming they are ashmem, without going
through libcutils. Such fds could have very well be originally created with
libcutils hence they could be memfd. Thus the IOCTLs will break.
Set default value of sys.use_memfd property to true once the issue is
resolved, so that the code can then self-detect if kernel support is present
on the device. The property can also set to true from adb shell, for
debugging.
Bug: 113362644
Change-Id: I0f572ef36cac2a58fe308ddb90bbeffbecdaed3b
Signed-off-by: Joel Fernandes <joelaf@google.com>
- package manager needs to read from /data/apex/active, hence 0750
- both /data/apex/backups and /data/apex/sessions are internal to apexd,
hence 0700
Bug: 123927167
Fixes: 123927167
Test: apex_e2e_tests, flashall -w & checked folders were created
Change-Id: I06c28328afe4945d082acd890401651bd37fcb20
Abstract usage of cgroups into task profiles that allows for changes
in cgroup hierarchy and version without affecting framework codebase.
Rework current processgroup and sched_policy API function implementations
to use task profiles instead of hardcoded paths and attributes.
Mount cgroups using information from cgroups.json rather than from init.rc
Exempt-From-Owner-Approval: already approved in internal master
Bug: 111307099
Test: builds, boots
Change-Id: If5532d6dc570add825cebd5b5148e00c7d688e32
Merged-In: If5532d6dc570add825cebd5b5148e00c7d688e32
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Abstract usage of cgroups into task profiles that allows for changes
in cgroup hierarchy and version without affecting framework codebase.
Rework current processgroup and sched_policy API function implementations
to use task profiles instead of hardcoded paths and attributes.
Mount cgroups using information from cgroups.json rather than from init.rc
Bug: 111307099
Test: builds, boots
Change-Id: If5532d6dc570add825cebd5b5148e00c7d688e32
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
This CL fixes the design problem of the previous mechanism for providing
the bootstrap bionic and the runtime bionic to the same path.
Previously, bootstrap bionic was self-bind-mounted; i.e.
/system/bin/libc.so is bind-mounted to itself. And the runtime bionic
was bind-mounted on top of the bootstrap bionic. This has not only caused
problems like `adb sync` not working(b/122737045), but also is quite
difficult to understand due to the double-and-self mounting.
This is the new design:
Most importantly, these four are all distinct:
1) bootstrap bionic (/system/lib/bootstrap/libc.so)
2) runtime bionic (/apex/com.android.runtime/lib/bionic/libc.so)
3) mount point for 1) and 2) (/bionic/lib/libc.so)
4) symlink for 3) (/system/lib/libc.so -> /bionic/lib/libc.so)
Inside the mount namespace of the pre-apexd processes, 1) is
bind-mounted to 3). Likewise, inside the mount namespace of the
post-apexd processes, 2) is bind-mounted to 3). In other words, there is
no self-mount, and no double-mount.
Another change is that mount points are under /bionic and the legacy
paths become symlinks to the mount points. This is to make sure that
there is no bind mounts under /system, which is breaking some apps.
Finally, code for creating mount namespaces, mounting bionic, etc are
refactored to mount_namespace.cpp
Bug: 120266448
Bug: 123275379
Test: m, device boots, adb sync/push/pull works,
especially with following paths:
/bionic/lib64/libc.so
/bionic/bin/linker64
/system/lib64/bootstrap/libc.so
/system/bin/bootstrap/linker64
Change-Id: Icdfbdcc1efca540ac854d4df79e07ee61fca559f
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
