Since Android R, the FUSE prop is always on and FUSE-off is no longer
supported
Test: m
Bug: 160159282
Change-Id: Ic4414b850511fe3b4fc6df3f8b736d21335db820
This is needed so "adb remount" can avoid writing to /data during a
checkpoint.
Bug: 157540389
Test: manual test
Change-Id: I33a691da3b99343acfc1e8ddf68a14504c3bfbe1
This can be done through binder as well as vdc, using 'vdc volume
abort_fuse'.
Bug: 153411204
Test: adb shell vdc volume abort_fuse
Change-Id: I93e46dc1cd361729cc1162c63520cf73152ea409
Vold needs to pass / accept IncFs control via Binder, so it
neeeds to get and put its internal FDs in and out. Using the new
release() function it works without extra fd duping
Bug: 153704006
Test: builds & boots
Change-Id: I64bc5b1ca9f2c69e34c3a860ed3edbe58bd9ea29
Vold now does not check caller's permission, but only accepts
transactions from system_server. And it's up to system server to do the
right thing and check permissions/appops.
Bug: b/152633648
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest
Test: adb shell appops set 1000 GET_USAGE_STATS deny
Change-Id: Id56c1673b135b72b3ec86e572aa4bcca3afc19ab
+ Get rid of an extra string copy in path validation function
Bug: 152349257
Test: atest vold_tests
Change-Id: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
Merged-In: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
+ Get rid of an extra string copy in path validation function
Bug: 152349257
Test: atest vold_tests
Change-Id: I03a8cab0dd6abd7d5c9dcbbc2acb651e818e6cd8
CL is a part of multi-repository topic and will be merged
to AOSP
Bug: 146080380
Test: manual
Change-Id: I09b33a34ff1ac7f6e415b7bd090c22e7df24d72d
Merged-In: I09b33a34ff1ac7f6e415b7bd090c22e7df24d72d
Also, use the pids provided by system server to remount all existing
processes, so we don't need to do the heavy and unreliable scanning in
/proc anymore.
Bug: 149548518
Test: atest AdoptableHostTest
Change-Id: Ifb5b79a3bc5438f36e0d61ec8aec96bdbc60ca13
AIDL generates optional<T> for nullable T types for C++, which is more
efficient and idomatic and easy to use.
Bug: 144773267
Test: build/flash/boot
Merged-In: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
Change-Id: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
(cherry picked from commit 3ce0ee5363)
Exempt-From-Owner-Approval: CP from master
AIDL generates optional<T> for nullable T types for C++, which is more
efficient and idomatic and easy to use.
Bug: 144773267
Test: build/flash/boot
Merged-In: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
Change-Id: I98549c8614c9152d5d45e2f1f33f2f3c31a9bbbf
(cherry picked from commit 0568fd287cfc0affc8e985f21da3793cdda286a3)
This can be used to fixup application directories in case they have been
created by some other entity besides vold; the main use case for this
API right now is OBB directories, which can be created by installers
outside of vold; on devices without sdcardfs, such directories and the
files contained therein are not setup correctly. This API will make sure
everything is setup the way it needs to be setup.
Bug: 146419093
Test: inspect OBB dir after install
Change-Id: I2e35b7ac2992dbb21cc950e53651ffc07cfca907
StubVolume is a volume type for ARC++ external storage. Named StubVolume
because it is managed from outside Android (not through Android kernel).
Previously, StubVolume is a diskless volume. However, as mentioned in
jsharkey@ email, a disk is needed for StubVolume to hold "kInternal"
(external storage type that is "external" from Android perspective,
but is "internal" to the device. For example shared directory from
ChromeOS to Android) and "kIndexable" (whether or not a disk should be
indexed by MediaStore).
The addition of disk means we could expose the createStubVolume API to
add a disk flags, which is also introduced in this CL.
Both kInternal and kIndexable will be introduced in separate CL.
Bug: 132796154
Test: Mount/unmount ARC++ removable device in ChromeOS.
Change-Id: I8b77fa1cf50ab38a2892272154dafdb78f079378
Move most of it into cryptfs.cpp, and include cryptfs.h in fewer files.
Bug: 147814592
Test: Treehugger
Change-Id: Ia3592d73e7abc1f07a60538e0978a3033bdea7de
CE keys were cached in vold to support untrusted reset
by a device admin, this is now supported by Locksettingservice
using synthetic password. This change requires a secret to be
provided to retrieve the CE key and re-wrap without the secret
when user removes the credential.
Test: Set credential, remove credential, swipe to none
and vice-versa.
Bug: 26948053
Merged-In: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
Change-Id: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
CE keys were cached in vold to support untrusted reset
by a device admin, this is now supported by Locksettingservice
using synthetic password. This change requires a secret to be
provided to retrieve the CE key and re-wrap without the secret
when user removes the credential.
Test: Set credential, remove credential, swipe to none
and vice-versa.
Bug: 26948053
Change-Id: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
vold historically offerred functionality to create directories on behalf
of others. This functionality was purely used to create app-specific
data/obb/media dirs. Make this more explicit by renaming the method to
indicate this.
Additionally, in the past, we never needed to care about the UID set on
these directories, because sdcardfs would take care of that for us
automatically. But with sdcardfs going away, we need to make sure the
UID of the app-specific directories is set correctly. Allow the caller
to pass this in as an argument.
Bug: 146419093
Test: atest FuseDaemonHostTest
Change-Id: Ibeb5fdc91b40d53583bc0960ee11c4d640549c34
Mounting a FUSE path needs two steps:
1. Mounting the filesystem
2. Starting the FUSE session in the FUSE daemon
The second part requires retriving an fd from (1) and the mount paths
and passing it to the FUSE daemon.
Previously, we'd return from the Vold mount call and mark the volume
as mounted while we scramble to do (2). This means there's a time
period where the Volume is marked as MOUNTED but not actually ready
and any IO access on the paths will hang forever. This could also be
misleading when interpreting bug reports.
Now, we block the Vold mount call until the FUSE session is started
Test: atest AdoptableHostTest
Bug: 144275217
Change-Id: I45238a31df71286f67ef1c65c711d0085d72e97f
Up until now, the FUSE mount logic has made two assumptions:
1. The primary external volume is an emulated volume on /data/media
2. Only the primary user is running, as user zero
These assumptions are fixed by the following changes
creating an EmulatedVolume per Android user and changing the
VolumeBase id format to append the user to the id, so
s/emulated/emulated-0/. This allows us mount separate volumes per user
Some additional refactorings to re-use/clean up code.
Test: adb shell sm set-virtual-disk and partition disk operations work
even after setting up a work profile
Bug: 135341433
Change-Id: Ifabaa12368e5a591fbcdce4ee71c83ff35fdac6b
A little bit more self-explanatory name that explicitly says that root
is also allowed.
Test: builds
Change-Id: Ice20ffcba2a0994c599dbebace252138ffd827de
Merged-In: Ice20ffcba2a0994c599dbebace252138ffd827de
A little bit more self-explanatory name that explicitly says that root
is also allowed.
Test: builds
Change-Id: Ice20ffcba2a0994c599dbebace252138ffd827de
It will be used by userspace reboot to reset checkpoint state, to make
sure that when /data is remounted, it will be remounted in checkpointing
if a checkpoint was requested beforee userspace reboot.
Test: /system/bin/vdc startCheckpoint 1
/system/bin/vdc needsCheckpoint (returns 0)
/system/bin/vdc resetCheckpoint
/system/bin/vdc needsCheckpoint (returns 1)
Bug: 135984674
Change-Id: Ia29238686289b4eed93e2fb936a8b3d894b94dc9
Bug: 140882488
Test: Booted twice, checked logs to ensure encryption
is different each time, adb created files in directory.
Change-Id: I74077bf8f727dab726c25f512ed7406a74cbe0bf
Also allow the state just before doMount() as a valid state for setting
fuse fd.
Test: manual
BUG:140173712
Change-Id: I012f8a83fef00e68f33010954fbc2ebc53cf8f1d
Since system_server cannot mount devices by itself,
add a binder interface to vold that system_server
can call to initiate this mount when required.
BUG: 135341433
Test: manual
Test: atest --test-mapping packages/providers/MediaProvider
Test: ExternalStorageHostTest DownloadProviderTests
Change-Id: If4fd02a1f1a8d921a3f96783d8c73e085c5b7ca1
When both ext4 user data checkpoints and metadata encryption are
enabled, we are creating two stacked dm devices. This had not been
properly thought through or debugged.
Test: Enable metadata encryption on taimen (add
keydirectory=/metadata/vold/metadata_encryption to flags for userdata in
fstab.hardware)
Unfortunately metadata is not wiped by fastboot -w, so it is
necessary to rm metadata/vold -rf whenever you wipe data.
fastboot flashall -w works
fastboot reboot -w works
A normal boot works
Disable checkpoint commits with
setprop persist.vold.dont_commit_checkpoint 1
vdc checkpoint startCheckpoint 10
adb reboot
wait for device to fully boot then
adb reboot
Wait for device to fully boot then
adb logcat -d | grep Checkpoint shows the rollback in the logs
This tests encryption on top of checkpoints with commit, encryption
without checkpoints, and rollback, which seems to be the key cases.
Bug: 135905679
Change-Id: I8365a40298b752af4bb10d00d9ff58ce04beab1f
abortChanges will attempt to pass a reboot message, and will only reboot
if the device is currently checkpointing. Additionally, it can opt to
attempt to prevent future attempts. This only works for non-bootloader
controlled updates. Failures are ignored, as it will always reboot the
device. In the unlikely event of such a failure, the device will
continue to retry as though you did not ask to prevent future attempts.
Test: vdc checkpoint abortChanges abort_retry_test 1
vdc checkpoint abortChanges abort_noretry_test 0
Change-Id: I7b6214765a1faaf4fd193c73331696b53ae572d2
