| Age | Commit message (Collapse) | Author |
|---|
|
Everything in FsCrypt.cpp seems to run under VolumeManager::mCryptLock,
except for fscrypt_destroy_volume_keys() which uses mLock instead.
This was sort of okay because fscrypt_destroy_volume_keys() didn't
operate on any in-memory data structures. However, that is going to be
changed. Therefore, rework VoldNativeService::forgetPartition() to call
fscrypt_destroy_volume_keys() under mCryptLock.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: Ia27a61faf2fdd546cdbddb2a3985c7c6696f6aa6
Merged-In: Ia27a61faf2fdd546cdbddb2a3985c7c6696f6aa6
(cherry picked from commit ce86e24d233a26b68ae3655ebc3f5730322d78a4)
|
|
|
|
Public SdCard Volumes are mounted only for user 0
(foreground user). This gives ENONT if the cloned
user tries to access the files in SdCard with
paths like "/storage/AB02-G212/DCIM/"
This change adds SdCard Volume mnt under
/mnt/usr/<cloned-user>/ which allows cloned apps
access to SdCard via direct file paths.
Bug: 203395175
Test: Manual by building and flashing device.
Change-Id: I091c40d3cb19915145cd5af40d1e79d5a9ecfa02
|
|
We no longer support ro.apex.updatable=false case. Hence no need to read
it.
Bug: 297460439
Test: device boots
Change-Id: I9b71ea96052741073f092ca6abcfbe92a927128a
|
|
StorageStatsManager.getTotalBytes currently takes the size of /data and
rounds up to known probable sizes to guess the size of internal storage.
This is not always correct.
Instead, find the device /data is on and get the size of that device.
This should give a more accurate answer.
Bug: 295358118
Test: vdc volume getStorageSize returns storage size
Change-Id: I907892041b1ce2cd72092a9877ac34c12bf3f254
|
|
With the way the FUSE mount point are currently setup for emulated
volumes, there can be multiple paths that serve the same files on the
lower filesystem; eg
* /mnt/user/0/emulated/0/Android
* /mnt/user/10/emulated/0/Android
both refer to the same file on the lower filesystem:
* /data/media/0/Android
this is normally not a problem, because cross-user file access is not
allowed, and so the FUSE daemon won't serve files for other users.
With clone profiles this is no longer true however, as their volumes
are accessible by each other.
So, it can happen that an app running in clone profile 10 accesses
"/mnt/user/10/emulated/0/Android", which would be served by the FUSE
daemon for the user 10 filesystem.
At the same time, an app running in the owner profile 0 accesses
"mnt/user/0/emulated/0/Android", which would be served by the FUSE
daemon for the user 0 filesystem.
This can cause page cache inconsistencies, because multiple FUSE daemons
can be running on top of the same entries in the lower filesystem.
To prevent this, use bind mounts to make sure that cross-profile
accesses actually end up in the FUSE daemon to which the volume
belongs: "/mnt/user/10/emulated/0" is bind-mounted to
"/mnt/user/0/emulated/0", and vice-versa.
Bug: 228271997
Test: manual
Change-Id: Iefcbc813670628b329a1a5d408b6126b84991e09
|
|
Now that emulated FBE is no longer supported, there is no longer any
distinction between native FBE and emulated FBE. There is just FBE.
Referring to FBE as "fscrypt" is also poor practice, as fscrypt (the
Linux kernel support for filesystem-level encryption) is just one part
of FBE, the Android feature.
Therefore, rename fscrypt_is_native() to IsFbeEnabled().
Bug: 232458753
Change-Id: Idf4cb25d37bc3e81836fcc5a1d96f79ccfa443b7
|
|
This fixes a bug in Android T where MediaProvider leaked FUSE fds in
it's process preveventing it from dying after being killed. This
resulted in the MP in a zombie state.
Even though, this bug was more prevalent in Android T due to a change
in the Parcel lifecycle (see b/233216232), this bug could have always
occurred in theory.
This fix should be harmless since after volume reset, all FUSE volumes
should be unmounted and aborting the FUSE connections will either
no-op or actually prevent the FUSE daemon from getting wedged in a
zombie state.
Test: Manually trigger a FUSE fd leak in the MediaProvider, kill it
and verify that it is restarted without zombie.
Bug: 233216232
Bug: 231792374
Bug: 230445008
Change-Id: I9e559a48b9a72e6ecbc3a277a09ea5d34c9ec499
|
|
This is a useful warning, so remove two unused variables and stop
disabling this warning.
Change-Id: I3efe0b300ea139ea11d645dec6fb2613acc0e51b
|
|
Mounting encrypted OBB files has never worked reliably across devices,
partly due to its reliance on Twofish encryption support in the kernel.
This is because Twofish support (CONFIG_CRYPTO_TWOFISH) has never been
required or even recommended for Android. It has never been enabled in
GKI, but even before GKI it wasn't required or recommended. Moreover,
this is now the only Android feature that still uses dm-crypt
(CONFIG_DM_CRYPT), and some devices don't have that enabled either.
Therefore, it appears that this feature is unused. That's perhaps not
surprising, considering that the documentation for OBBs
(https://developer.android.com/google/play/expansion-files) says that
they are deprecated, and also it explains OBBs as being app files that
are opaque to the platform; the ability of the platform to mount OBBs
that happen to be in a particular format is never mentioned. That means
that OBB mounting is probably rarely used even with unencrypted OBBs.
Finally, the usefulness of OBBs having their own encryption layer (in
addition to what the platform already provides via FBE) is not clear
either, especially with such an unusual choice of cipher.
To avoid the confusion that is being caused by having the broken code
for mounting encrypted OBBs still sitting around, let's remove it.
Test: atest StorageManagerTest # on Cuttlefish
Test: atest StorageManagerIntegrationTest # on Cuttlefish
Bug: 216475849
Change-Id: Iaef32cce90f95ea745ba2b143f89e66f533f3479
|
|
StubVolumes are managed from outside Android (e.g. from Chrome OS). So,
their disk recreation on vold reset events should also be handled from
outside by 1) listening to reset events, and 2) calling
createStubVolume() for existing StubVolumes on reset events.
Bug: 175281783
Test: m
Test: (Tested in R) Manually induce a vold reset event, and confirm that
Test: 1) vold does not crash, and 2) existing volumes are successfully
Test: mounted again (by calling createStubVolume() for StubVolumes).
Change-Id: I4628eabf809037a547aeef43faedf4dfa57529a6
|
|
IVold.MOUNT_FLAG_VISIBLE is split into MOUNT_FLAG_VISIBLE_FOR_READ and
MOUNT_FLAG_VISIBLE_FOR_WRITE.
Accordingly, VolumeBase::MountFlags::kVisible is split into
kVisibleForRead and kVisibleForWrite.
Bug: 206019156
Test: m
Change-Id: Ia55673400d9f713f221650e1335a46ba11f6f027
Merged-In: Ia55673400d9f713f221650e1335a46ba11f6f027
|
|
Since every APEX requires at least one loop device, now most of the
block devices on a device are not managed by vold. This change removes
some log statements around block devices that vold is not aware of.
Test: device boots
Test: adb logcat
Change-Id: I8efa22023c1f888e75f40178fac464af4457df3c
|
|
Also, add REMOUNT_MODE_ANDROID_WRITABLE to return "/mnt/runtime/write".
Bug: 148454884
Test: builds
Change-Id: I5a38c88f46034c494604bb001cf4d4c400c8f73e
|
|
So we can ensure Android/ dir is created,
otherwise EnsureDirExists may return false if Android/ doesn't exist
Bug: 177281374
Test: Able to boot without errors
Change-Id: I02e816b60530ac9d3d3b978a7c9028d2c0e34bad
|
|
|
|
|
|
This new method will be used in new sm command.
Tests can use this so data and obb dirs are unmounted, and won't
be killed when volume is unmounted.
Bug: 148049767
Test: New sm command able to unmount app's data and obb dirs
Change-Id: Ifbc661ca510e996abd4b7ce1fb195aaa7afc37ad
|
|
The new flag is used to indicate that a stub volume (external storage
volume shared with Chrome OS) is visible to Android apps.
Bug: 123377807
Bug: 142684760
Bug: 132796154
Test: Check logcat logs for StorageManagerService.mount() when the
Test: visibility setting of a removable device is toggled in Chrome OS.
Test: Confirm that the visibility setting is properly set.
Test: (Tested in R)
Change-Id: Ica69110d5667837a72a5c8693ff3bccc0f09a82d
|
|
Since Android R, the FUSE prop is always on and FUSE-off is no longer
supported
Test: m
Bug: 160159282
Merged-In: Ic4414b850511fe3b4fc6df3f8b736d21335db820
Change-Id: I5a7643f9ca2f37cd7f264331df76b42df31988d5
|
|
Otherwise, zygote can't find those dirs and bind mount them.
Bug: 176959830
Test: atest AdoptableHostTest
Change-Id: Ib8a7616f8e248fed244d4f23d3ae36b1419a732d
|
|
As storage is not mounted in system server, we use vold
to check if storage app data and obb directories exist instead.
We add a method in vold so it only creates app data and obb dirs
if dirs do not exist to speed up app starting time.
Bug: 160336374
Test: Data and obb directories are created when a new app is started
Change-Id: I1bd784d9c9e05463f71433fc782ac4e0c831cbf1
|
|
Since /storage/emulated/userId isn't accessible for users != userId,
and vold should anyway try to avoid accessing the FUSE filesystem itself.
Bug: 172078780
Test: atest StorageManagerTest --user-type secondary_user
Change-Id: I98222bf844a6b7d8ec0d9873eddc71f61aa68c90
|
|
NetlinkManager::stop() and VolumeManager::stop() are never called, so
remove them.
Change-Id: I868aa2ad24066d2830816984afcc10000cbabad1
|
|
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
|
|
This allows devices that have sdcardfs enabled in the kernel to not use
it. When external_storage.sdcardfs.enabled=0, sdcardfs will not be
mounted. This is treated as default true to not affect upgrading
devices. It does not use the old ro.sys.sdcardfs as that has been
repurposed over time and no longer can be relied on to turn off
sdcardfs. This is included within emulated_storage.mk
Bug: 155222498
Test: mount|grep "type sdcardfs" should find nothing after boot complete
if external_storage.sdcardfs.enabled=0
Change-Id: I23d75fb1225aeabbcb1a035ad62fd042b6b3c7b5
|
|
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
|
|
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
|
|
rvc-dev
|
|
To improvement performance, and also making them able to list
the dirs.
This should also be fine under b/151055432, as the whole obb
directory is mounted, renameTo() from installer to apps should be
a move not copy.
Bug: 153422990
Bug: 153540919
Test: atest AdoptableHostTest
Change-Id: Ia18fd4393db14a0f11d6e5b947dd716515bdeeef
|
|
While looking at some emulator logs, I noticed that we fail to create
dirs like /Android/data/com.foo/cache on public volumes, because we try
to chmod it; public volumes go completely through FUSE, even for
Android/, and so these operations will fail, because the underlying
UID/GID is not setup correctly.
Really the only thing we really have to do on public volumes is create
the dirs, like we used to do.
Bug: 152618535
Test: manually verify cache dirs can be created successfully
Change-Id: I66e5d0873f1198123787943b17b468eadf0a853d
|
|
Test: Manually verified ownership of /storage/emulated/0/Android/data on cf_x86_phone-userdebug after enabling feature
Bug: 151455752
Change-Id: I75a1e3b769476e56094e41d82e7f8e1a72827ded
|
|
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
|
|
We should mount Android/data also, not only Android/obb.
Test: After flag is enabled, AdoptableHostTest still pass.
Bug: 148049767
Bug: 150584566
Change-Id: I26dc3756aa5843b85565495e9c2698130113f49a
Merged-In: I26dc3756aa5843b85565495e9c2698130113f49a
(cherry picked from commit d88e090098d4a95112aecb135d1bcba96150bdd1)
|
|
|
|
- Remove bind mounting Android/ code as we want to bind mount obb dir
for each process instead.
- Set property "vold.vold.fuse_running_users" as an array of user id
for which fuse is ready to use.
- After fuse is ready for a user, fork a background process in vold
to bind mount all direct boot apps for that user so its direct boot
apps obb dir will be mounted to lower fs for imporoved performance.
Bug: 148049767
Bug: 137890172
Test: After flag is enabled, AdoptableHostTest still pass.
Change-Id: I90079fbeed1c91f9780ca71e37b0012884680b7c
|
|
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
|
|
|
|
Initially, we were thinking to pass kInternal for non usb drive/sd card
drive (for local external storage like directory shared from ChromeOS).
Fortunately, the DocumentsUI logic apparently has TYPE_LOCAL with
R.drawable.ic_root_smartphone (that is overlayable) for external storage
other than TYPE_USB and TYPE_SD.
Therefore, instead of creating a kInternal flags, we can just passed kUsb
and kSd and not passing anything for "internal external storage" - which
will render ic_root_usb, ic_root_sd, and ic_root_smartphone as icons
accordingly. And since ic_root_smartphone is already overlayable, we
could overlayed in /vendor - which effectively is what we initially
wanted when thinking of introducing kInternal flag.
Bug: 132796154
Test: Customize flags in /vendor for different devices and DocumentsUI
shows the ic_root_smartphone (which can be overlayed) when kUsb is not
passed, and USB icon when kUsb is passed.
Change-Id: I55f13e214bbb2aeed96b6950bcf391121174c354
|
|
|
|
This was hard to read and understand. Instead, fall back to explicit
string operations with more comments on what we're doing and what we're
allowing.
This also fixes an issue where apps were asking us to create dirs on
their behalf that our more than 2 levels deep, eg
com.foo/files/downloads ; I thought such paths weren't allowed, but
apparently they are (and there's no good reason for us to not set them
up correctly).
Bug: 149407572
Test: launch opera
Change-Id: I7c64831032b66e90960b96e41ee42c7d616a759c
|
|
This is no longer needed, because vold can deduce this itself now.
Bug: 146419093
Test: builds
Change-Id: Ib4f4a4109919af683722a63b305b343ef5fe972d
|
|
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
|
|
A regex allows us to be more specific in what kind of directories we
accept here, which in turn makes it easier to correctly create them.
Bug: 146419093
Test: atest FuseDaemonHostTest
Change-Id: Icb8911f6516eab81b9bbd567c7287be9f605e8b0
|
|
ebbabdc8fb
Change-Id: If8c533aa196969adf38dcbf85673cebb39a79024
|
|
Move most of it into cryptfs.cpp, and include cryptfs.h in fewer files.
Bug: 147814592
Test: Treehugger
Change-Id: Ia3592d73e7abc1f07a60538e0978a3033bdea7de
|
|
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
|
|
When we're asked to create an app directory, find the corresponding
volume, and use the raw path of that volume to create the directory.
This ensures this will continue working on devices that don't have
sdcardfs.
Bug: 146419093
Test: manual test on cuttlefish
Change-Id: I91d735c1adbcca171e5af73aca0abd7ef396d0b7
|
|
This is a slave bind mount of /mnt/user, created before we create the
two mount namespaces. Unmounting it here prevents us from re-creating it
in the right way, so leave it alone.
Bug: 134706060
Test: verify mount is still there after vold starts
Change-Id: Iaac91953cbb9abfef0aaac60f74b99b16c943f87
|
|
* changes:
Conditionally use sdcardfs.
Also delay creating found disks until user 0 is started.
|
