In violation to the documentation of GateKeeper::GetAuthTokenKey and
GateKeeper::GetPasswordKey, the implementations in SoftGateKeeper
allocate and return buffers and relinquish ownership causing a memory
leak, because the caller expects the implementation to retain ownership.
Bug: 129768470
Bug: 134557251
Test: gatekeeper-unit-tests
Change-Id: I0af9539d3dcd47dfd1e7d80cdee700ea0c2d6d0f
Merged-In: I0af9539d3dcd47dfd1e7d80cdee700ea0c2d6d0f
This reverts commit 1ec3b78b67.
Reason for revert: breaks all camera use cases
Bug: 135568875
Exempt-From-Owner-Approval: revert, no build cop
Change-Id: Iec8e1f94f5bedced3f3faf73f851fd2f13e2e768
libhwbinder symbols are being moved into libhidlbase in order to
optimize linking/memory usage. libhwbinder will no longer be
required in the future (however removing references to it will come
separately).
Bug: 134961554
Test: boot
Change-Id: I2b9a4fb9d87913b6c0e4291d3debadbf27511111
libprocessgroup symbols are being moved into libcutils in order to
optimize linking/memory usage. libprocessgroup will no longer be
required in the future (however removing references to it will come
separately).
Bug: 135145426
Test: boot
Test:
BEFORE:
$ adb shell showmap -a $(pid hwservicemanager) | grep -P "libprocessgroup|libcutils" -A1 | grep -P 'libprocessgroup|libcutils|\.bss' | awk '{s += $9}END{print s}'
28
AFTER:
$ adb shell showmap -a $(pid hwservicemanager) | grep -P "libprocessgroup|libcutils" -A1 | grep -P 'libprocessgroup|libcutils|\.bss' | awk '{s += $9}END{print s}'
12
Change-Id: I10d7c2d2b2b14cbbe0a128b9156d31206419d24c
We need vold on early-fs so we can handle userdata checkpointing.
Without this, devices will take an extra minute or two as checkpointing
related vdc calls attempt to reach vold before it is available.
Bug: 134114000
Test: Boot, see vold has started before vdc checkpointing tries to call
out to vold.
Change-Id: Idfdb304503a163fbb91f9317949eb98c06fecce1
Since ACgroupController_getFlags was introduced after LLNDK freeze it
causes media crashes due to missing symbol. Remove the new function and
re-implement cgroup controller detection to not require flags field but
instead check for its existence on the first access.
Bug: 135049992
Test: libcutils_test with and without CONFIG_CPUSETS enabled
Change-Id: I0220d6a926884dc22a7424d7d0a980c379c6f4eb
Merged-In: I0220d6a926884dc22a7424d7d0a980c379c6f4eb
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
To avoid introducing dependencies on target libraries, use a statically
compiled test instead.
Bug: 134912860
Test: run vts-kernel -m VtsKernelLiblpTest
Change-Id: Ie24cc8532c7821cb225c024c240c4d485557bfa7
This change is to support importing property file with its path
variations.
By substitute its filename with another, it can be used to handle
runtime varying filename within single binary.
Here's an example of usage in property defined file.
import /odm/build_${ro.boot.product.hardware.sku}.prop
Bug: 132592551
Test: boot a device and checks above example import statement in
"/odm/build.prop" loading expanded filename correctly
Merged-In: If3fdcf620a5d717e0930b1e4e58261bc8f79ec24
(cherry picked from commit a87c0f99ad)
Change-Id: If3fdcf620a5d717e0930b1e4e58261bc8f79ec24
while enable fdsan (file descriptor sanitizer),
fdsan report use-after-close error after boot complete (sedom).
Because, in SetCgroupAction::EnableResourceCaching() currently has a data race against all the
use fd_ functions like SetCgroupAction::ExecuteForProcess(uid_t uid, pid_t pid) etc.
ThreadA | ThreadB
-------------------------------------------------------------------------------------------------
in SetCgroupAction::EnableResourceCaching() | in SetCgroupAction::ExecuteForProcess(...)
-------------------------------------------------------------------------------------------------
| in SetCgroupAction::AddTidToCgroup(int tid, int fd)
-------------------------------------------------------------------------------------------------
fd_ = std::move(fd); /*modified fd_ value*/ |
-------------------------------------------------------------------------------------------------
| write(fd) /* crash here, fd is closed by ThreadA*/
-------------------------------------------------------------------------------------------------
So, add mutex lock to protect fd_ data race.
Bug: 134120826
Test: auto test, run the adb reboot test 100 times and no fdsan error report on libprocessgroup
Merged-In: Iccf2f705e030f79324f1164509e715dc5be825de
Change-Id: Iccf2f705e030f79324f1164509e715dc5be825de
If we just disabled verity, take the step to setup the backing
storage for overlayfs.
Test: adb-remount-test.sh
Bug: 130131892
Change-Id: Ic56569eaf363e4417a0ce5df11ee5480a07b8b03
Merged-In: Ic56569eaf363e4417a0ce5df11ee5480a07b8b03
This works around a deadlock when a bridge that is about to be closed
is reused for a new call to openFile. The call to open() ends up holding
the vold lock, waiting for appfuse to respond. The appfuse event loop
calls onClosed(), which ends up calling vold.unmountAppFuse(), which
cannot get the lock.
Closing this file descriptor causes any current calls to open() on its
mount path to fail with either ECONNABORTED or ENOTCONN, allowing the
event loop to make progress, call onClosed() and unmount the path.
Note that the failed call to open() will result in a retry, which
will create a new appfuse bridge. This is not ideal but not a new
problem -- the common case here is that that each call to
openProxyFileDescriptor creates a new bridge. This should ideally
be improved.
Bug: 132344997
Test: flick through info of photos with location info attached
Exempt-From-Owner-Approval: verbal approval of approach
Change-Id: I878e5cf86f18c5233f8505f52eb9db076bd72d01
When reading/writing proxy FD, if it returns EAGAIN,
BridgeEpollController updates epoll entries to observe specific FD
events. Before updating epoll entries, BridgeEpollController checks if
it really needs to update by comparing |state_| and |last_state_|.
|last_state_| has not been updated correctly so it resulted in wrong
epoll settings and keeps blocking the event loop.
Bug: 134104939
Test: atest libappfuse_test
Change-Id: I1c4a0164c1c016baf24ecfd523476ced981d3b28
Currently, if init encounters a fatal issues it reboots to fastboot
but this may be not desirable in all cases, especially the case of
critical services crashing. Therefore this change adds the ability
for vendors to customize the reboot target via the
androidboot.init_fatal_reboot_target= kernel command line.
This applies to all LOG(FATAL) messages as well as fatal signals in
userdebug/eng builds, except for signals before logging is enabled in
first stage init.
Bug: 121006328
Test: device reboots to configurable target with LOG(FATAL)
Test: device reboots to configurable target after a segfault in the
various stages of init
Test: device reboots to fastboot without a configured target
Change-Id: I16ea9e32e2fee08dece3d33b697d7a08191d607b
Merged-In: I16ea9e32e2fee08dece3d33b697d7a08191d607b
(cherry picked from commit 75e13baf32)
Dump init stacks when aborting either due to LOG(FATAL) or in
userdebug/eng builds due to signals, including signals from
sanitizers.
Doesn't work for static first stage init yet, b/133450393 tracks
that.
Also, ensure that LOG(FATAL) in child processes calls abort() in all
stages of init, not just 2nd stage init.
Bug: 131747478
Test: abort init in various ways and see stacks
Test: hang or crash in backtrace handler and see child reboot
Change-Id: Ib53b5d3e7e814244203f875de016ada9900dfce8
Merged-In: Ib53b5d3e7e814244203f875de016ada9900dfce8
(cherry picked from commit 59656fb377)
non-aio USB read function was stuck in a loop waiting for more data
because data length parameter is always set 64 for fastbootd commands.
It should be a normal case to get less data than expected
since lengths of these commands are usually less than 64.
Add logic to check this and one more parameter to distinguish
fastbootd from general adbd case.
Bug: 133189029
Test: try various fastbootd commands
Change-Id: I6690324840d78f3f1e04235040301520329976db
Memory mapping the central directory of specific APKs caused memory
mappings to build up over time because they were never unmapped
correctly. This is because MappedFile is not calling munmap with the
size of the data after aligning the mmap offset to a page boundary.
Bug: 133463863
Test: install APKs and verify that the entire mapped CD is unmaped
Test: ran aapt2 as daemon and confirmed that mapped CD is unmapped
Change-Id: Icb6cfebe0e8d67160fee34c5e6423d0f05de526b
This directory is no longer used. OBB content is
placed in /data/media/$user/Android.
Test: make
Test: manually verify the path doesn't exist.
Bug: 129167772
Change-Id: I8549826586b9a68c8cfa3fe2e51295363f9b4e11
Some USB controllers can only support transfers upto 16K.
Bug: 133208811
Test: fastboot flashall
Change-Id: Ic025bdd8e7a6cf2634fc24524fd189e0cc9efbb5
Merged-In: Ic025bdd8e7a6cf2634fc24524fd189e0cc9efbb5
(cherry picked from commit d747dba9c0)
In device root directory, we have the following symlinks:
- /odm/app -> /vendor/odm/app
- /odm/bin -> /vendor/odm/bin
- /odm/etc -> /vendor/odm/etc
...
This allows the Generic System Image (GSI) to be used on both devices:
1) Has a physical odm partition, where those symlink will be hidden
when /odm is used as the mount point
2) Has no physical odm partition and fallback to /vendor/odm/.
We can't just have the symlink /odm -> /vendor/odm, because the former
devices won't have /vendor/odm directory, which leads to mount failure
when the mount point /odm is resolved to /vendor/odm.
The existing /vendor/odm/build.prop won't be loaded in the latter
devices, because there is no symlink
- /odm/build.prop -> /vendor/odm/build.prop.
Note that init blocks reading through direct symlinks (O_NOFOLLOW) so
the above symlink won't work either. This CL moves the odm build.prop
to /odm/etc/build.prop for init to load it (symlinks in earlier
components of the path will still be followed by O_NOFOLLOW).
Bug: 132128501
Test: boot a device and checks /odm/etc/build.prop is loaded
Change-Id: I0733c277baa67c549bb45599abb70aba13fbdbcf
Merged-In: I0733c277baa67c549bb45599abb70aba13fbdbcf
(cherry picked from commit c49655b2a4)
