In order to store supplemental data for apps, we want to create a root
directory at location `/data/misc_ce/<user-id>/supplmental` and
`/data/misc_de/<user-id>supplemental`. These directories will then host
supplemental data for each app based on package name, e.g,
`/data/misc_ce/0/supplemental/<app-name>`.
Since these are sub-directories of misc directory, vold should prepare
them for consistency.
Bug: 217543371
Test: atest SupplementalProcessStorageHostTest
Test: see ag/16681989
Ignore-AOSP-First: Feature is being developed in internal branch
Change-Id: I66ef7a7241c9f82cecedaeb6c9a91f127668300a
Merged-In: I66ef7a7241c9f82cecedaeb6c9a91f127668300a
(cherry picked from commit 0cf90d7ca0)
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
This is in conjunction with enabling the project id for internal directories. The check whether project ids should be used or not, is done in installd process. If they cannot be used, then the installd process falls back to previous approaches.
Bug: b/215154615
Test: atest installd/StorageHostTest
Test: atest installd/installd_service_test.cpp
Change-Id: I2c6672640295ebbc5ec78075290fc8e8703384ef
The userdata will be formatted by VOLD during bootup when the userdata
is not completed file system(EXT4 or F2FS).
For EXT4 on userdata and quota feature is enabled. the parameter quota
is incorrect in ext4::Format(). Change the parameter from
quotatype=prjquota to quotatype=usrquota:grpquota:prjquota.
Bug: 199802158
Bug: 211847181
Test: run cts-on-gsi -m CtsAppSecurityHostTestCases -t
android.appsecurity.cts.StorageHostTest
Change-Id: Ibff10e8e67b4e6ffabea97f534ff6551aed91963
Merged-In: Ibff10e8e67b4e6ffabea97f534ff6551aed91963
(cherry picked from commit 3101ac01ac)
(cherry picked from commit 344cd3337903c3b5da35df3dc3f15d4badc253a4)
Vold was trusting system_server too much and allowed for pretty
much any path in mount()/bindMount() calls for incremental.
This CL adds validation to make sure it's only accessing own
directories. This includes enforcing no symlinks in the paths
Bug: 198657657
Bug: 216722132
Test: manual
Change-Id: I6035447f94ef44c4ae3294c3ae47de2d7210683a
Merged-In: I6035447f94ef44c4ae3294c3ae47de2d7210683a
Android should only abort fuse connections for fuse fs. It shouldn't
touch fuse connections for virtiofs.
Bug: 162284193
Test: manual - Restart zygote, no 'Transport endpoint is not connected' error.
Change-Id: Ie3536734531404e98ad1b6594ab3c52e919b22b7
Added interfaces required by smart idle maintenance service in
StorageManagerService, whose goal is to determine when to trigger
filesystem defragmentation while keeping the best user experience
as long as possible, and avoiding hurting UFS lifetime.
Test: check smart idle maintenance log every hour
Bug: 202283480
Bug: 181079477
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Change-Id: I012cfb9b01e5d21ec71700c3c52ac9c096cd1a90
We need to load the partition table before we can wait on the userdata
dm device because the kernel (as of [1] doesn't send the KOBJ_ADD uevent
until after the partition table is loaded. The new flow needs to be:
CreateDevice() -> ioctl(DM_DEV_CREATE)
LoadTableAndActivate() -> ioctl(DM_TABLE_LOAD)
WaitForDevice()
This patch updates create_crypto_blk_dev() to first call
LoadTableAndActivate() before WaitForDevice().
[1] https://lore.kernel.org/all/20210804094147.459763-8-hch@lst.de/
Fixes: 156d9d2293 ("Pre-create userdata metadata encryption device.")
Bug: 210737958
Test: manually test booting raven with android13-5.15
Change-Id: Iab2214a62d44ba7e53b57f2cf0f08ac06c77b4fd
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
