We want started users to be an ordered set; eg user 0 should always go
first. This is because volumes for users other than 0 depend on user 0
coming up first, because the volume for user 0 is the one mounting
sdcardfs.
Bug: 13789012
Test: atest AdoptableHostTest
Change-Id: Ic9119f0a24bd261e5362019836ac240b90c681c0
The path for emulated volumes is set to /storage/emulated,
not /storage/emulated/<userid> . When unmounting, we only
want to kill process with a reference to /<userid>; this prevents
killing processed needlessly.
Bug: 137890172
Test: atest AdoptableHostTest
Change-Id: I70e36e87077e87db9b3c7e07dc0e481ba06c2c14
For apps seeing the FUSE filesystem, we want to bind-mount the Android/
directory to the lower filesystem. The main reason for this is game
performance - Android/ contains both OBBs and app-private external data,
and both are heavily accessed during game startup. This is a pretty
straightforward bind-mount on top of /mnt/user.
Bug: 137890172
Test: Running the following:
df /storge/emulated/0 ==> /dev/fuse (FUSE)
df /storage/emulated/0/Android ==> /data/media (sdcardfs)
Test: atest AdoptableHostTest
Change-Id: Ic17a5751b5a94846ee565ff935644a078044ab06
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
LOG() can hang, because another vold thread may have been holding
a libc lock at the time we forked. Simply moving the log line to
before the fork().
Bug: 135341433
Test: atest AdoptableHostTest
Change-Id: I6063eb33f35c835a226bc1e56de97ace426747ff
This creates apexrollback directories under /data/misc_[de|ce]/<user>
which will hold snapshots of DE_n and CE_n apex data directories
(i.e. it will hold backups of data from /data/misc_[de|ce]/<user>/apexdata
for particular apexes).
See go/apex-data-directories for details.
Bug: 141148175
Test: Built and flashed, checked directory was created.
Change-Id: I468060b20dee0c50033b5f014ce8716582d5e6bc
It will be used during the userspace reboot to unmount all emulated
storages, which is a prerequisite to unmount+remount ext4 userdata into
checkpoint mode.
Test: adb shell /system/bin/vdc checkpoint startCheckpoint 1
Test: adb reboot userspace
Bug: 143970043
Bug: 135984674
Change-Id: I07491bc4be2f30debe21b764766c9def68548e16
We want to be sure we're not allocating memory, holding locks
or otherwise preventing the child process from making progress.
This is a temporary fix of limited scope. In the medium term, it
would be preferable to exec a binary that performs this work for us
as soon as we fork.
Test: manual
Bug: 141678467
Change-Id: I57dbd9b3c887aa27e2dd609abf0ad43c66f4ef2a
It's the responsibility of the StorageManagerService to send down
started users after a reset(); and with the latest multi-user FUSE
changes, the manual start is no longer necessary.
Bug: 135341433
Test: atest AdoptableHostTest
Change-Id: I3c9c1d7c25ad10787212d7902fa3f1878ee5f896
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
This creates an apexdata directory under /data/misc_de/<user> and
/data/misc_ce/<user>, and also creates a directory under that for
every APEX that is installed.
See go/apex-data-directories.
APEXes are discovered by scanning the /apex directory. It may be better
to delegate this process to a library, but it is proposed to defer that
change to a future CL.
Bug: 141148175
Test: Built and flashed, checked directories were created.
Change-Id: I95a060b4f42241c91da25a779e61a8f85ca1914c
The HidlizationEquivalenceTest was used to make sure the same key is
computed by the scrypt algorithm regardless of whether the old
(<= KM2 HAL pre treble) or the new (>= KM3.0 treble) HAL was used.
Since the treble is now the default, and old HAL don't even exist on
new devices, we should call the migration a success and drop this test
altogether.
Test: Removed obsolete Code
Bug: 68197448
Change-Id: If10c79bafac4d0c8268675cbb8e1c4b46974aab5
symlink(2) creates a symbolic link 'linkpath' containing a
string 'target'.
linkpath was misnamed as target in MountUserFuse. This cl
s/target/linkpath/ in Utils#MountUserFuse.
Test: m
Change-Id: I274823da16b87ffc124e2e8c4563b1d16546a6e7
Ifabaa12368e5a591fbcdce4ee71c83ff35fdac6b introduced individual
emulated volumes for each Android user. The change however didn't
create the volumes for the secondary users on user start in vold
without the persist.sys.fuse flag
Now we always create the volumes but only mount sdcardfs volumes
for user 0 because the sdcardfs mount paths do not change with for
different users unlike the FUSE mount paths.
Bug: 144473552
Test: atest AdoptableHostTest
Test: Start a guest user in Settings and launch chrome browser in that
user, verify that chrome does not crash
Change-Id: I89f3591d0197d86267f0e3934f496273e2f9fd7e
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
