By removing `recovery_available` property from "ueventd.rc" and
defining a dedicated recovery-specific module for "ueventd.rc".
`recovery_available` property should be used to allow the reverse
dependencies recovery modules to depend on the module, not to
install the module to the recovery partition.
Test: m soong_generated_recovery_filesystem_test
Bug: 381888358
Change-Id: I6921cae72a1757e065003efc9d77241625f645e9
By removing `recovery_available` property from "init_second_stage"
and defining a dedicated recovery-specific module for
"init_second_stage". `recovery_available` property should be used
to allow the reverse dependencies recovery modules to depend on
the module, not to install the module to the recovery partition.
Test: m soong_generated_recovery_filesystem_test
Bug: 381888358
Change-Id: Ie9b93b8453bc1e40f7a28e57f498313d3bc4cedb
By removing the "recovery_available" property from "reboot" and
"watchdogd" modules.
"recovery_available" property should be used to allow the reverse
dependencies recovery modules to depend on the module, not to
install the module to the recovery partition.
Test: m soong_generated_recovery_filesystem_test
Bug: 381888358
Change-Id: I48014774714957885f3ad648ac302cc3c13687ae
Cgroup v2 paths are owned by libprocessgroup. Those paths can change
based on build flags, so paths generated outside of libprocessgroup may
not always be correct.
Bug: 382693152
Test: adb shell debuggerd -b <pid>
Change-Id: I7e486ab6f4068d0fae1be033a91b9a307f54ed42
By removing `recovery_available` property from "toolbox" and defining a
dedicated recovery-specific module for "toolbox". `recovery_available`
property should be used to allow the reverse dependencies recovery
modules to depend on the module, not to install the module to the
recovery partition.
Test: m soong_generated_recovery_filesystem_test
Bug: 381888358
Change-Id: I8e1bbf56aaf5ba4a761d84e60afa420ba6f825b9
toybox no longer sets recovery_available
property, thus this make module is no longer generated. Thus,
replace the entry with the soong modules to prevent missing
dependencies make error.
This change also specifies `recovery` property in
shell_and_utilities_recovery to allow soong generated recovery partition
to correctly install the dependencies of the phony module.
Test: m nothing
Bug: 381888358
Change-Id: I314e8031d23a9f579101ca1d5499969af4e3a9d3
Context: to have better future updatability. The responsiblity of
managing mainline module storage files and a socket service for flag
overrides will be moved to the configinfra mainline module. Later,
aconfigd on /system will only be repsopnsbile for managing platform
partition storage files.
Bug: b/369810972
Test: m, launch avd and then inspect the logcat log to confirm the
service is launched.
Change-Id: I490e5aa432fa4afa236689ad0999e5602f7d297e
The HAL has been updated to V2, but the trusty prebuilt implementation
does not yet have that code. Update trusty secretkeeper build to use V1
specifically instead of latest until the prebuilt has those changes.
Bug: 372223451
Test: TH
Change-Id: Ic2e9b578b50685d71b5597d8d34ac7ee36b6ddc9
Currently, memfds are created with executable permissions, meaning that
one can load a binary into a memfd buffer and use fexecve() to run said
binary. This is not desirable for security reasons, and also does not
match with the behavior that the ashmem driver currently supports.
When the ashmem driver is in use, /dev/ashmem* does not have executable
permissions, so fexecve() cannot be used on those buffers. Linux kernels
6.3+ offer MFD_NOEXEC_SEAL as part of the memfd interface, which allows
one to create memfds with non-executable permissions. Furthermore, the
executable permissions cannot be changed on these memfds.
This matches the expected behavior that ashmem provided, so allow memfd
usage only if MFD_NOEXEC_SEAL is supported, and create memfds with
non-executable permissions by default.
Bug: 111903542
Change-Id: Ibb2c2be3c118ead44fc12bcd2b63dcf6f83c9b03
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
Adding signal handler to avoid abort() due to
broken pipe.
Test: ./gatekeeperd_service_fuzzer
Bug: 376201407
Change-Id: Ifca08860d11f56eb8e0d490c6b6956f8774cfa70
cc_binary aconfigd is replaced with rust_binary aconfigd-system. The
replacement is flag guarded and is already in TF full for more than a
week. Thus delete the flag and deprecate old cc_binary aconfigd.
Test: m
Change-Id: Ib128adc2ef8178e02222f77e6b89bcc7ac83c1da
event.logtags was moved from system/core/logcat to system/logging/logcat in Android 12 by aosp/1454058.
Change-Id: Ia3cedee549145eddb0484ec589a9599a156bea14
BUG: 168791309
Flag: DOCS_ONLY
Test: Local build
- Declare v4 HAL.
- Declare version 400 in Package Manager (when unfrozen).
- Link to current (V4 when unfrozen) versions of support libraries.
- Add `setAdditionalAttestationInfo()` method to HAL service.
- Add `SetAdditionalAttestationInfo()` method to implementation, using
the common message types.
- Add Trusty-specific message code for the
`SET_ADDITIONAL_ATTESTATION_INFO` message exchange.
Test: VtsAidlKeyMintTargetTest (new test fails until TA updated too)
Bug: 369375199
Change-Id: I4699aea3ab8a0723a5c2bc1493f7bbb69cdfd6df
1: Check the presence of the file 'prefetch_ready'. If it doesn't
exist then the device is booting for the first time after wipe.
Thus, we would just create the file and exit as we do not want
to initiate the record after data wipe primiarly because boot
after data wipe is long and the I/O pattern during first boot may not actually match
with subsequent boot.
2: If the file 'prefetch_ready' is present:
a: Compare the build-finger-print of the device with the one record format
is associated with by reading the file 'build_finger_print'. If they match,
start the prefetch_replay.
b: If they don't match, then the device was updated through OTA. Hence, start
a fresh record and delete the build-finger-print file. This should also cover
the case of device rollback.
c: If the build-finger-print file doesn't exist, then just restart the record
from scratch.
Bug: 362507272
Test: Prefetch record/replay
Change-Id: I90b861ba9381ddba6ab7dedb9930a735e55b0e5d
Signed-off-by: Akilesh Kailash <akailash@google.com>
