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
boot-debug.img is introduced to allow 'adb root' if the device is
unlocked, and it cannot be release signed. If /boot partition is chained
in AVB signing and boot-debug.img is used, avb_slot_verify() in
userspace will return AVB_SLOT_VERIFY_RESULT_ERROR_PUBLIC_KEY_REJECTED
and fs_mgr will refuse to boot. This CL treats the public key rejection
as non-fatal for chained vbmeta to continue booting, if the device is
unlocked.
Bug: 129508966
Test: can root with user load which /boot chained in AVB signing
Change-Id: Idfa8caffbb96f33702b1749afd2e2a59616ddba7
Merged-In: Idfa8caffbb96f33702b1749afd2e2a59616ddba7
(cherry picked from commit 705fd7f52c)
We used to start update_verifier after mounting userdata (post-fs-data),
as part of zygote-start. This leads to issues in practice for security
updates, where an A/B device falls back into the old slot (for any
reason, which unrelates to this change) but failing to boot due to
upgraded key blob. It essentially breaks the fallback capability offered
by A/B OTA.
This CL mitigates the issue by starting update_verifier early, before
mounting userdata. This avoids the device from falling back to the old
slot with an already-upgraded key blob. update_verifier loses the
opportunity of verifying _all_ the updated blocks based on the info
that's stored in userdata. Instead it will only trigger the minimal
read to finish the work of marking a successful boot. This is a
trade-off in P to avoid putting the device in a bad state after
fallback, which will be improved in Q by better handling the fallback
path in vold.
Bug: 131176531
Test: Flash and boot crosshatch. Check the start of update_verifier and
it marks a successful boot.
Change-Id: I3f4c4333ff38772a9a93c9d027d497db11de1d63
Josh Gao