Consolidate command handling for commands that take a buffer ID as
their first argument. Further use ParseUint instead of atoi(), since
atoi("bad string") returns `0` is the same as LOG_ID_MAIN.
Test: these commands are handled property
Test: `echo -n 'getLogSize ignoreme!\0' | nc -U /dev/socket/logd`
returns an error
Change-Id: I3e84a6157e16f4c110681da453e1ae1a920da7c4
To support "override" services, we need to scan partitions from least
speicific to most specific.
Bug: 163021585
Test: m
Change-Id: I26a6de4f7fb571c60038e803137a4b1c237792fd
On non-VAB devices, fake super image creation may fail because it
may not support f2fs file pinning.
Also changes global setup to a testing::Environment object because it is
the recommended way in gtest's guide. SnapshotTestEnvironement::TearDown
is automatically executed before RUN_ALL_TEST returns.
Test: vts_libsnapshot_test
Test: make IsVirtualAbEnabled() return false, then all tests are
skipped.
Bug: 162557082
Change-Id: I1382f9a4ddec146fa2d8cfb21ac66ca22a2e110f
When checking IsUnreliablePinningAllowed, the existing code calls
IsTestDir on a value starts with "/data", but IsTestDir expects
metadata_dir_. Fix it.
Also, make subdir checks more robust and add test cases for IsSubdir.
Fixes: 162557082
Test: vts_libsnapshot_test
Test: fiemap_image_test
Change-Id: I495cfae3da11d1e0800b8abf520df10dd9a29dce
liblog exposed __android_logger_get_buffer_size() which queries log
size properties, but that should not be a generic library function.
Logd should be the only process that queries these properties and
other processes should query the actual used log sizes from logd via
the android_logger_get_log_*_size() functions.
Also, always use 1MB for log buffer tests, instead of just on host and
various other clean up related to improper types.
Test: log buffers are correctly sized
Merged-In: I9b7c86bf58e569618737afe9097cf1c4d4e61d95
Change-Id: I9b7c86bf58e569618737afe9097cf1c4d4e61d95
The set of linked binaries was making it difficult to run
the test over a native bridge. Since init won't usually
run over a native bridge, the test can be skipped.
Bug: 161081809, 142324733, 162288553
Test: Arm build of CtsInitTestCases skips rammus-arc-r Chromebook.
Change-Id: Icdd8b03111d0f3fd6658ee6d9a97fca27181db45
(cherry picked from commit 9cecf8422a)
This makefile is not included before, so it was never built. Also do
the following changes to make sure it works:
- Remove non-existing libhealthd_internal dep
- Add necessary libhealthd_charger dep because it tests AnimationParser
- Since it tests AnimationParser, change its name to
libhealthd_charger_test
Test: run it
Change-Id: If7f91de4b910024f27d09a25ca801e67b98221db
The test fails because TEST_STRING, a char[], is silently
converted to a std::string, passed to remove_prefix, then
the string is destroyed, but a pointer to the string is
returned.
Fix it by changing the signature of remove_prefix to use
std::string_view to be more robust in handling raw char*.
Test: run it
Change-Id: I553c066907f09cf330c8b7a4659db5a1fee82cac
There is a possibility of data loss if an interrupt occurs in the
middle of these write() calls.
Test: logcat -g/-S/-B work correctly
Change-Id: I2dd4ec10771714fc49b61538d3028983516e106c
There is an existing API, android_logger_get_log_readable_size() which
historically reported the consumed amount of data for the chatty log
buffer, since consumed and readable are synonymous with that buffer
type.
With log compression, readable and consumed are not synonymous, since
the readable log size is the uncompressed log size whereas the
consumed log size is the compressed log size.
This change adds android_logger_get_log_consumed_size() which returns
the consumed log size and makes android_logger_get_log_readable_size()
return the readable log size. Note that these values are identical if
compression is not used.
It adds both statistics to logcat:
main: ring buffer is 1 MiB (429 KiB consumed, 817 KiB readable)
radio: ring buffer is 1 MiB (339 KiB consumed, 715 KiB readable)
...
Test: logcat prints the right values with compression and chatty
Change-Id: I8b9688a987736204e2e6026e8635fbd1a5e68bb7
Add a 2s timeout for logd command socket operations:
android_logger_clear
android_logger_get_log_readable_size
android_logger_get_log_size
android_logger_set_log_size
android_logger_get_statistics
android_logger_get_prune_list
android_logger_set_prune_list
That correspond to:
logcat -c
logcat -g
logcat -G
logcat -S
logcat -p
logcat -P
These operations should return immediately in typical circumstances,
but if logd is stuck, they would otherwise block indefinitely. This
allows the commands to gracefully timeout instead.
Test: kill -s STOP `pidof logd`; logcat -g (and other options)
times out appropriately
Test: logcat -g (and other options) work successfully otherwise
Change-Id: I6c4671a9b3daa4a454c0a14ae7d0b7d3b08be77a
The fuzzer was creating individual maps that overlapped with other maps.
Since this is not possible in the real world unless the kernel is broken,
do not let the fuzzer do this. This resulted in memory leaks, because some
parts of the code have this assumption baked in.
Bug: 160895854
Test: Ran fuzzer test case that leaked memory and verified it no longer does.
Change-Id: I9f3c1e28781093b041b747e1566fb51d40d2bf71
This reverts commit 72abd7b246
(change Ia39af3340c0e241f62557b7c2cc8b800443342f9).
When vold enables either FDE or metadata encryption, it encrypts the
filesystem in-place. Unfortunately, due to a bug, for ext4 filesystems
it hasn't been encrypting the backup superblocks.
Also, in read_ext4_superblock(), the check for
StartsWith(blk_device, "/dev/block/dm-") can return true even if the
encryption mapping hasn't been added yet, since when a GSI image is
booted the userdata block device is a logical volume using dm-linear.
The result is that read_ext4_superblock() can recognize a backup
superblock when the encryption mapping hasn't been added yet, causing
e2fsck to run without the encryption mapping and corrupt the filesystem.
https://android-review.googlesource.com/c/platform/system/vold/+/1385029
will fix this for new or factory-reset devices. However, there probably
are many existing devices that already have their backup superblocks
unencrypted. Therefore, the EncryptInPlace fix isn't enough and we have
to revert the change that started using the backup superblocks too.
Bug: 161871210
Bug: 162479411
Change-Id: I279f84c072bc6c8d3e251a5e95c78f8d6c0d50ba
