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)
Failing to write to the endpoint results in subsequent reads on ep0 to
fail with EL2HLT, so do an empty write to fulfill the transfer.
Bug: http://b/131867920
Test: manually tested with modified auto client
Change-Id: If2eec162ca4b31a9974c7bd5802be51cee9e2708
Currently, during a 'fastboot flashall/fastboot update', the 'getvar
max-download-size' command is issued once to the device when it is in
bootloader mode and the same value is used even after the device boots
into fastbootd. If the max-download-size returned by bootloader is
greater than the max-download-size in fastbootd, this could break flash
as large images are broken down into chunks before downloading by using
the max-download-size variable. This will cause fastbootd to return
an error since it checks whether the buffer being downloaded has a size
greater than the max-download-size limit.
Test: fastboot flashall
Bug: 132917902
Change-Id: Ife7c1ec0583d80d4a31ecf01f1fc14a8365afe0d
Merged-In: Ife7c1ec0583d80d4a31ecf01f1fc14a8365afe0d
(cherry picked from commit 83d856e4c5)
Executable in /data/ runs in default linker namespace, not
classloader namespace.
In Q, we moved libicuuc.so and libicui18n into the runtime
namespace, and allow linking from runtime namespace and classloader
namespace.
This change further allows linking from default namespace, and tries
to fix the regression temporarily.
Bug: 130788466
Test: The app issue is fixed after this CL
Merged-In: Ifae52b554124514e433cfe78875643a7450fbabd
Change-Id: Ifae52b554124514e433cfe78875643a7450fbabd
(cherry picked from commit 0c7edece94)
It seems like we're blowing up when receiving a control transfer that's
intended for Android Auto, because we're not expecting to get the data
for the control transfer in a subsequent read.
Bug: http://b/131867920
Test: none
Change-Id: Icfd642e6dfc02d2ccbdd60c39f89e534298c944d
Controllers listed in cgroups.json file might fail to mount if kernel is
not configured to support them. We need a way to indicate whether a
controller was successfully mounted and is usable to avoid logging errors
and warnings when a controller that failed to mount is being used. Add
flags bitmask to cgrouprc controller descriptor and use a bit to indicate
that controller is successfully mounted. Modify cpusets_enabled() and
schedboost_enabled() functions to use this bit and report the actual
availability of the controller.
Bug: 124080437
Test: libcutils_test with cpuset and schedtune controllers disabled
Change-Id: I770cc39fe50465146e3205aacf77dc3c56923c5d
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Kernel does not accept non-zero value of iocb->aio_reserved2.
Bug: 132803232
Test: initialize malloc() memory to non-zero pattern and see what breaks
Change-Id: I65a7e89e3a2c1ba79df1dc2d011d6c76c41afb81
(cherry picked from commit fe7eca7b8f)
This keyword was introduced to support restarting services on devices
using APEX and FDE. The current implementation is not a restart, but
rather a 'reset' followed by a 'start', because the real /data must be
mounted in-between those two actions. But we effectively want this to be
a restart, which means that we also want to start 'disabled' services
that were running at the time we called 'class_reset_post_data'.
To implement this, keep track of whether a service was running when its
class was reset at post-data, and start all those services.
Bug: 132592548
Test: manual testing on FDE Taimen
Change-Id: I1e81e2c8e0ab2782150073d74e50e4cd734af7b9
Permitted paths were empty for ASAN builds with the media namespace.
Bug: 131625115
Test: no dlopen failure on libflacextractor.so in aosp_cf_x86_pasan
Change-Id: I90050fc54820ba68d64931412572f3b0954e6616
Also, improve the logging in the cases where we do abort.
Bug: http://b/131867920
Test: treehugger
Change-Id: If8ec9f4614ce146e6dbd21cc77587ea81658199b
(cherry picked from commit 2916e148d9)
(cherry picked from commit 98a0128e44)
Regression from commit 77c28476f1
("Remove the mount points defined in skip_mount.cfg from
ReadDefaultFstab()") resulted in ReadFstabFromFile to report
errno ENOENT even upon success, preventing clear error propagation
for real failures (ReadFstabFromFile would _always_ report ENOENT).
The bad error propagation resulted in an adb remount failure.
Added immunization against future adjustments that may also
result in a similar regression in adb remount behaviors.
Test: adb-remount-test.sh
Bug: 132594161
Bug: 128961335
Change-Id: Icf5d48bbfc6d938d4b9657ca8004a6a6ddaab5a6
Replacing "ro.boot.vbmeta.devices_state" with
"ro.boot.vbmeta.device_state" to check if the device is locked.
Bug: 132224452
Test: tree hugger
Change-Id: If4f312730cc82ad5a5d5104a7aca8b9691cf6600
(cherry picked from commit 2badf73b99)
Children of processes that use SocketListener should not be able
to stop the SocketListener.
Test: builds, boots
Test: atest libsysutils_tests
Test: atest --test-mapping system/netd
Bug: 131268436
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I64898d9966f62004468b8e8a43b59be4a81a8cc4
Merged-In: I64898d9966f62004468b8e8a43b59be4a81a8cc4
(cherry picked from commit dae0195380)
The majority of libjsoncpp use is due to libprocessgroup. Static
linking reduces relocations required at runtime as well as compacts the
pages dirtied by relocations. On a 32-bit system, where this matters
the most, this reduces 8KB of dirty pages per libprocessgroup load.
Overall, the dirty page reduction on 32-bit cuttlefish is ~500KB.
Bug: 132275636
Test: Boot on cuttlefish. Calculate total amount of dirty memory used
for libprocessgroup and libjsoncpp.
Change-Id: I1135bb45a3764f96a4a3a47c98fbcdee3913c988
