Originally, vndk_lite does not include system/lib/vndk-* directory but
searching the required files in system/lib instead. However, in GSI,
they are using the vndk libs which has symbols than core variants.
To avoid this problem, allow the vendor processes in vndk_lite devices
to search system/lib prior to vndk libs.
Bug: 124063441
Test: Check boot for vndk_lite devices.
Change-Id: I89a72e9d43d6fb05f4b6d87bbd4500f8febfe970
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>
JSON supports only decimal values and therefore file mode which should
use octal values has to be represented as strings. Fix the implicit
octal-to-decimal conversion and convert from string to octal in the code.
Bug: 111307099
Test: confirmed by verifying correct file permissions
Change-Id: I3ef9de0aea259f93bf74efeffca72d37d4740e15
Signed-off-by: Suren Baghdasaryan <surenb@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
As of Id663c5f284e3b4fc65ed8cb8c2da6bcf6542e034, the asan libs
are in the TARGET_COPY_OUT_X subpath of the /data/asan/ dir, rather
than just 'x' unconditionally.
Test: presubmit
Change-Id: I3a515791e237ad10703415ea532c7a089660d8e9
TARGET_COPY_OUT_PRODUCT_SERVICES can be equal to
TARGET_COPY_OUT_PRODUCT, in which case the ld.config
lines containing PRODUCT_SERVICES are redundant.
Test: make and diff
Change-Id: I1dc24eb49d37f1ab0faa6eecdb0ccc974321f4ac
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>
Add cgroups.json and task_profiles.json file to be places under /etc/ on
the device to describe cgroups to be mounted and task profiles that
processes can request. This adds additional layer of abstraction between
what a process wants to achieve and how system implements that request.
Bug: 111307099
test: builds, boots
Change-Id: If92f011230ef5d24750e184bad776f30ba226f86
Merged-In: If92f011230ef5d24750e184bad776f30ba226f86
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>
Add cgroups.json and task_profiles.json file to be places under /etc/ on
the device to describe cgroups to be mounted and task profiles that
processes can request. This adds additional layer of abstraction between
what a process wants to achieve and how system implements that request.
Bug: 111307099
test: builds, boots
Change-Id: If92f011230ef5d24750e184bad776f30ba226f86
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
The vulkan runtime loads drivers into the sphal namespace and relies
on them being in the sphal search path so that it doesn't have to
hardcode /vendor/${LIB}/hw.
These paths used to be allowed, but were removed by commit 2498e1b
because they were believed not to be required. Things didn't break
immediately because the vulkan runtime has a (supposed to be
temporary) fallback to hw_get_module, which loads from
/vendor/${LIB}/hw using absolute paths.
Bug: 123600276
Test: Launch Vulkan app on device with hw_get_module disabled
Change-Id: I07ac43bc9d2d877d8f427058b2d62c62d065c558
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
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
