The Android Emulator isn't the only virtual device the virtio-block
detection code is useful for, and those platforms might not set any
discriminating properties to indicate that they are virtual.
Rework the virtio-block major detection to use /proc/devices instead
of hardcoding the assumption that any virtual platform can have
virtio-block at any experimental major; the new code permits only the
exact experimental major assigned to virtio-block.
The new code runs everywhere, but it will only run once and could be
expanded later to detect dynamic or experimental majors.
Bug: 156286088
Change-Id: Ieae805d08fddd0124a397636f04d99194a9ef7e5
This reverts commit ab7c958cc5.
Reason for revert: ARC is migrating to ARCVM on R, which doesn't use AppFuse any more.
Bug: 110379912
Test: m
Change-Id: Icc827c59530274421e4c94789d96fd3d287e591e
This reverts commit dcbd4fcad2.
Reason for revert: ARC is migrating to ARCVM on R, which doesn't use AppFuse any more.
Change-Id: Ifd0bf92a79c0ff25d782bea44dd593f9502f1959
So Android/data and Android/obb won't be accessing fuse anymore,
and apps should not see other packages as well as it's sandboxed
the tmpfs.
Bug: 155462341
Test: atest AppDataIsolationTests pass after feature flag is on
Change-Id: I5658440772e669c1235d318f708a3d336523754f
fs_mgr supports 'nofail' flag, which is used if we do not want to
error-out incase the mounting/setup fails for a partition tagged with
nofail flag in fstab.
Recently added code in vold misses this handling, i.e. it aborts even
for a nofail partition upon encountering an expected failure.
Test: Add a non-existing logical partition fstab entry with 'nofail'
flag. Init's first stage mount acks this and doesn't crash.
Vold aborts (as it doesn't handle it), and device doesn't boot.
With this change, device boots up.
Change-Id: I2b1904a9c648c31bcc05b2e7e77480db236ff66e
When we're mounting a private volume, we create stacked emulated volumes
on top of it. Due to the ordering there, we would broadcast the emulated
volumes being created *before* the "mounted" status update. This in turn
could cause us to try and mount these emulated volumes before the
underlying private volume is really mounted. This is problematic in
particular on devices that support a filesystem keyring, where we need
to do some additional setup before the devices can be used.
While we could modify StorageManagerService to delay the mount, a safer
fix at this stage of the release is to just fix the ordering of these
events. To achieve that, add a simple postMount() helper, that is called
after a succesful mount. This allows us to setup the volume properly
before trying to mount any stacked volumes.
Bug: 151079464
Test: atest AdoptableHostTest
Change-Id: I2cc4113d4d71d89aa629bb9c0fa9be441355c079
This patch fixes missing entry in the below commit.
Fixes: c52f6724ed ("vold: clean up configuration set")
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: Ia39a427d4747b29a7af42633f34daab63204bbf9
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
am skip reason: Change-Id I562df49deffdccdb2cfd657130fc05b24d40a6a6 with SHA-1 78f806198f is in history
Change-Id: I8cdb012f5976e3c964e16dff9da9541831442734
am skip reason: Change-Id I562df49deffdccdb2cfd657130fc05b24d40a6a6 with SHA-1 78f806198f is in history
Change-Id: Ib183a53d8b49427ddf243d22db5df1f4b2b9815e
