Normally sdcardfs takes care of setting up these directories on-demand,
for example when an app requests its private data directory to be
created. On devices without sdcardfs however, we ourselves need to make
sure to setup the UID/GID of these directories correctly.
Introduce a new PrepareAndroidDirs() function which sets the dirs up
correctly. On devices without sdcardfs, that means:
Path UID GID mode
/Android media_rw media_rw 771
/Android/data media_rw ext_data_rw 771
/Android/obb media_rw ext_obb_rw 771
Bug: 146419093
Test: wipe Android/, reboot, with and without sdcardfs, verify
contents
Change-Id: I3a879089422c7fc449b6a3e6f1c4b386b86687a4
In preparation of sdcardfs going away on devices launching with R,
conditionally use it.
Bug: 146419093
Test: cuttlefish with sdcardfs, cuttlefish without sdcardfs but with
FUSE
Change-Id: I2c1d4b428dcb43c3fd274dde84d5088984161993
The pass-through mount is used by MediaProvider to access external
storage. Previously, it was the raw filesystem (eg ext4/f2fs); the
problem with that is that the permissions on that filesystem don't allow
MediaProvider to access all the files it needs to - in particular
directories under Android/
To solve this problem, we can have the pass-through mount sit on top of
sdcardfs instead of the raw filesystem. This means we need to mount
sdcardfs even in case we're using FUSE, but we already needed to do this
anyway for other performance reasons.
Bug: 135341433
Test: atest AdoptableHostTest
Change-Id: I893d5e5076c5096d2d55212f643c9a857242e964
Long before scoped storage, FUSE was used to create several views of the
filesystem; this was later replaced by sdcardfs, yet the code still
references FUSE in variables and log messages. Fix those up to avoid
confusion with the "new FUSE".
Bug: 135341433
Test: atest AdoptableHostTest
Change-Id: I2966c5f95d6f38df36a20cdfdd0b95b3051f3f1e
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
This will be used for system internals to access
secondary volumes without having to bypass sdcardfs.
Bug: 121277410
Test: manual
Exempt-From-Owner-Approval: Got approval on internal master
Change-Id: I9b3e33f6c6e426e83469b8030b02d59c02183946
This moves fstrim, obb and appfuse commands over to the new Binder
interface. This change also separates creating/destroying and
mounting/unmounting of OBB volumes, which means they finally flow
nicely into the modern VolumeInfo/VolumeBase design.
We now generate unique identifiers for all OBB volumes, instead of
using a shady MD5 hash.
Change all "loop" and "dm" devices to tag the kernel resources with
a vold-specific prefix so that we can clean them up if vold crashes;
there are new destroyAll() methods that handle this cleanup.
Move appfuse mounting/unmounting into VolumeManager so it can be
shared. Move various model objects into a separate directory to
tidy things up.
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.storage.cts.StorageManagerTest
Bug: 13758960
Change-Id: I7294e32b3fb6efe07cb3b77bd20166e70b66958f
Martijn Coenen
Zim
Sudheer Shanka
Paul Crowley
Jeff Sharkey