dm-user block device will be the snapshot device; thus, no
more explicit call to MapSnapshot(). Additionally, block device
name for dm-user will be the snapshot name so that mount works
seamlessly.
API's to query the snapshot status, merge progress has been
integrated. Since daemon requires base device for merge, we pass
additional parameter during initialization.
Add a new virtual a/b property flag to enable/disable
user-snapshots feature. Propagate this flag to init layer
for first stage mount during boot process.
Some minor cleanup and renaming of variables.
Bug: 193863443
Test: 1: Full OTA on CF and pixel and verify the merge completion.
Tested merge-resume path by rebooting device during merge.
2: Incremental OTA on CF and pixel
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I5088f40a55807946cd044b3987678ead3696d996
ReadFstabFromFp() have two callers right now, ReadFstabFromFile() and
ReadFstabFromDt(). ReadFstabFromFile() opens a FILE* and pass it to
ReadFstabFromFp(), and ReadFstabFromDt() wraps a std::string::c_str()
buffer in a FILE* adaptor with fmemopen().
There's no need for such adaptor, just change ReadFstabFromFp() to
accept std::string and we're good.
Bug: 206740783
Bug: 204056804
Test: atest CtsFsMgrTestCases
Test: m libfstab_fuzzer
Change-Id: I3f56a83ec5baf7b0d97a618a2c2bb6e31b67b5d9
android::base::Tokenize() is like android::base::Split() but ignores
empty tokens. Think strtok_r() and strsep().
C++-ify parsing code by replacing strtok_r() with Tokenize(), which
results in more concise and readable code.
Bug: 204056804
Test: atest CtsFsMgrTestCases
(cherry picked from commit 3c1b581fd5)
Change-Id: Icce8c1b5ad074421052f68fa138d90adb85cca27
Revert "Demonstrate multi-installed APEXes."
Revert "Adds a new prop context for choosing between multi-insta..."
Revert "Adds multi_install_skip_symbol_files field (default fals..."
Revert submission 1869814-vapex-multi-config
Bug: 206551398
Reason for revert: DroidMonitor-triggered revert due to breakage https://android-build.googleplex.com/builds/tests/view?invocationId=I55600009996329947&testResultId=TR93527797572038984, bug b/206551398
Reverted Changes:
I0cd9d748d:Adds multi_install_skip_symbol_files field (defaul...
I5912a18e3:Demonstrate multi-installed APEXes.
I0e6881e3a:Load persist props before starting apexd.
I932442ade:Adds a new prop context for choosing between multi...
I754ecc3f7:Allow users to choose between multi-installed vend...
Change-Id: I27a4985061b112af7d0e9b95b6d42ccd9b846471
ReadFstabFromFp() have two callers right now, ReadFstabFromFile() and
ReadFstabFromDt(). ReadFstabFromFile() opens a FILE* and pass it to
ReadFstabFromFp(), and ReadFstabFromDt() wraps a std::string::c_str()
buffer in a FILE* adaptor with fmemopen().
There's no need for such adaptor, just change ReadFstabFromFp() to
accept std::string and we're good.
Bug: 204056804
Test: atest CtsFsMgrTestCases
Test: m libfstab_fuzzer
Change-Id: I71190c7356a354aa06d1be3fdc4ca76611b3896d
Unfortunately, some recovery fstabs still specify the FDE options, where
they never really did anything anyway. Allow them for now, since it
seems preferable to restrict any breakage to the case that really
matters (devices actually configured to use FDE in their main fstab).
Bug: 191796797
Bug: 206025578
Change-Id: I85e35af8f42d2aef91f08816a67a71bbf756b211
There are some fstab files that specify "encryptable=footer" for
adoptable storage volumes, which contradicts the documentation which
says that it should be "encryptable=userdata". However, the argument
was previously being ignored anyway. To avoid unnecessarily breaking
such devices, ignore the argument to "encryptable".
Note that we continue to only allow "encryptable" in combination with
"voldmanaged". So, fstabs that use "encryptable" for FDE (rather than
for adoptable storage) should continue to be rejected.
Bug: 191796797
Change-Id: Idc4d5f9c01098f997e12be0022bea992439cec9c
android::base::Tokenize() is like android::base::Split() but ignores
empty tokens. Think strtok_r() and strsep().
C++-ify parsing code by replacing strtok_r() with Tokenize(), which
results in more concise and readable code.
Bug: 204056804
Test: atest CtsFsMgrTestCases
Change-Id: Ic1dd0eb97ef9ce6786dc2bf65cdee22a40d813e7
- Use "likelihood" instead of "probability" since that has connotations
of being less precise, and our probability ordering isn't very precise
anyway.
- Hide the fault address with SEGV_MTEAERR because it is not available.
- Pad the fault address with leading zeroes to make it clearer which
bits of the top byte (and any following bytes such as PAC signature
bits) are set.
Bug: 206015287
Change-Id: I5e1e99b7f3e967c44781d8550bbd7158eb421b64
Remove the class_start_post_data and class_reset_post_data commands,
since they aren't used anymore. They were only used on devices that
used FDE (Full Disk Encryption), via actions in rootdir/init.rc. These
actions have been removed, since support for FDE has been removed.
There is no use case for these commands in vendor init scripts either.
Keep the mark_post_data command, since DoUserspaceReboot() uses the
post-data service flag even on non-FDE devices.
Bug: 191796797
Change-Id: Ibcd97543daa724feb610546b5fc2a0dd7f1e62e7
apexd now reads persist props to select between multi-installed APEXes
for debug builds.
Bug: 199290365
Test: see https://r.android.com/1872018
Change-Id: I0e6881e3a5a3775560b580556a7de2e2da043d34
FDE is no longer supported, so there's no longer any need to ever
reserve a crypto footer.
Bug: 191796797
Change-Id: I79121188b0bcb7b00c16fda03b68b20c40c1e240
Since Android 10, new devices have been required to use FBE instead of
FDE. Therefore, the FDE code is no longer needed.
Bug: 191796797
Change-Id: I2f29ce5fa61c67325d6eb6cf6693787f8fa8a011
Since Android 10, new devices have been required to use FBE instead of
FDE. Therefore, the FDE code is no longer needed.
Make fs_mgr reject fstabs where FDE is enabled.
Unfortunately, there is a quirk where the "encryptable" flag (which was
originally meant just for FDE) was overloaded to identify adoptable
storage volumes. It appears that we have to keep supporting this use
case. Therefore, don't reject the "encryptable" flag completely.
Instead, just reject "encryptable" when it appears without
"voldmanaged", or without "userdata" as its argument.
Here are some references for how "encryptable=userdata" is being used to
identify adoptable storage volumes:
* https://source.android.com/devices/storage/config#adoptable_storage
* f26c7e9b12:system/vold/main.cpp;l=269
* f26c7e9b12:device/google/cuttlefish/shared/config/fstab.f2fs;l=17
* f26c7e9b12:device/generic/goldfish/fstab.ranchu;l=7
[ebiggers@: modified from a WIP CL by paulcrowley@]
Bug: 191796797
Change-Id: I3c4bbbe549cc6e24607f230fad27ea0d4d35ce09
Add new CgroupGetControllerFromPath function to retrieve the name of the
cgroup using a file path. If the file does not belong to any cgroup, the
function returns false.
Bug: 191283136
Test: build and boot
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ic17a474cb25a80a3339b33ed8bc27b07af053abb
