On devices without metadata encryption, we use loop devices rather than
device-mapper + dm-linear + FIEMAP. Devices without metadata encryption
should not exist, since libfiemap was introduced with Android R, which
requires metadata encryption.
It is possible to retrofit an Android Q device with Virtual A/B, which
is what Pixel 4 did. However those devices can only upgrade to
Android T, and they had metadata encryption anyway.
If there are any Android Q devices that retrofitted Virtual A/B in R,
didn't have metadata encryption, and need to upgrade all the way to V,
then we can recommend they make WrapUserdataIfNeeded() unconditional.
Bug: N/A
Test: fiemap_image_test, vts_libsnapshot_test
Change-Id: I7be0507527b967166676c8b136b8758f5e69ba6b
Adding one command line parameter -B to allow tipc test to be run as benchmarks.
Bug: 314130383
Test: /data/nativetest64/vendor/tipc-test/tipc-test -t echo -r 1 -B 100
Change-Id: I5cdd643ce6e9e289033180cff433e45f77206729
This reverts commit 589c8d1e44.
Reason for revert: fuzzer crashes immediately on line 99 as vector is empty
Change-Id: I5e56a94671a43cd131c250d98f7cfae3c96f34ab
The FuzzerDefs.h APIs are internal to the fuzzer and aren't available
when the fuzzer is built with a custom private libc++, so remove the
ExtraCountersBegin/ExtraCountersEnd assertions and inline the array
clearing.
Bug: 175635923
Bug: 303175229
Bug: 315079422
Test: m libtrusty_fuzz_utils trusty_gatekeeper_fuzzer
Change-Id: I1ca9d9867026ff6f8e494ac6026fb1314caab7d1
Disabled by default; enable with `export SECRETKEEPER_ENABLED=y` before
building.
Also needs the Secretkeeper TA to be present in Trusty; if the TA is
absent, the HAL service will (repeatedly) fail to connect.
Test: build, VtsSecretkeeperTargetTest
Bug: 306364873
Change-Id: I529013395d0e3afbff4a24b663088adce2a23805
Remove temporary 'vendor_api_level_of' function from init and replace
the function with the same in libvendorsupport.
Bug: 312403948
Test: getprop ro.vendor.api_level
Change-Id: I095353e602397220571e131431e7cbd1b8511fa6
Merged-In: I095353e602397220571e131431e7cbd1b8511fa6
Right now we encode the per mountpoint scratch dir name like this:
/system -> /mnt/overlay/@system/
/product/app -> /mnt/overlay/@product@app/
This CL changes it to:
/system -> /mnt/overlay/system/
/product/app -> /mnt/overlay/product@app/
This makes it so that the encoded path for top-level mountpoints (like
/system, /vendor) would have the same encoded scratch dir as before
https://r.android.com/2795755 was introduced.
With this change old first-stage-init can handle top-level remounts
correctly. However for mountpoints with '/' in them, their remount
scratch dirs would be encoded with the new format, and old
first-stage-init would ignore and not setup these during boot.
This makes the remount mechanism to function partially when running on
an old ramdisk (first-stage-init) + new system combo.
Normally we expect the init_boot ramdisk to be upgraded alongside
system.img, so this change isn't strictly needed. However there are
cases where we might want to develop new OS features on old vendor
platform, thus this change.
Bug: 306124139
Bug: 243503963
Test: adb-remount-test
Change-Id: I9b43641bb338f11c6c83888880948e4b85af14e1
Some testcases assume that /dev/block/by-name/userdata is writable, but
mount_with_alternatives() will mark block device as RO if mount flag
includes MS_RDONLY. Fix it by marking the block device as RW again.
Test: th
Bug: 319156415
Change-Id: Ic04acd4b6175d3f0aeea88675da44309e8df15e8
Right now we assume all RW mounts (minus /data & special FS) are
remounted by us and we apply the remount/overlayfs related checks
on them unconditionally. This would generate false positives when
a partition was RW but not remounted by us.
The test should instead check mounts that were remounted by us
(transitioned from RO to RW after adb-remount), and ignore
partitions that were already RW before running adb-remount.
Bug: 313609600
Test: adb-remount-test
Change-Id: I94e8a35775271f557790a458781657eb3b24a6f5
Assign CPUSET_SP_BACKGROUND taskprofile to snapshot merge threads.
This will ensure that the threads will not run on big cores.
Additionally, reduce the flushing of data to 1MB after merging REPLACE ops.
No major regression observed on snashot merge time.
On Pixel 6 for incremental OTA of 500M, snapshot merge time increased
from 72 seconds to 76 seconds after this patch.
Bug: 311233916
Test: Full and incremental OTA on Pixel 6 - Verify merge threads not on big cores
Change-Id: I455afdac0b77227869d846d0c4472ea9eb34c41c
Signed-off-by: Akilesh Kailash <akailash@google.com>
Some rw /proc/mounts entries are FUSE.
Also, add some diagnostics for failures.
Bug: 318962836
Test: vts_fs_test on Pixel
Change-Id: I85dec8b37f1a061b1eca597aba3887b598b699f5
Before this patch, DeleteDeviceWithTimeout was checking that the dev
node (i.e. /dev/block/dm-XX) is deleted after the call to DeleteDevice
API. Since ueventd first deletes the symlinks that correspond to a
device and only then deletes this device node, this assertion introduced
a race condition (DeleteDevice API waits for the symlink to be deleted).
This patch changes the DeleteDeviceWithTimeout test to check that unique
path of the device has been deleted.
Bug: 318425605
Test: presubmit
Change-Id: I3fd9de507c75bcf6ac1350fa0b8adfdb5a2e89e8
The ABI checking rules for VNDK will be deleted from the main branch.
To keep monitoring the ABI, the check must be enabled explicitly.
Test: m libutils.vendor
Bug: 314010764
Change-Id: I762dec1ed7de014db653663d2917a19df5076fc8
