Currently, we pass down visisble volumes for a user to zygote so that
it can set up appropriate bind mounts after forking. This method has
atleast a couple of race conditions, so instead make zygote just
look under /mnt/user/<userId>/package for volumes that need to be
handled for a particular user.
Bug: 126069494
Test: manual
Test: atest cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ExternalStorageHostTest.java
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: If996cde24d9fc158729fcc8a8bdb17ca952a518e
We need this to stay mounted at /storage.
Bug: 124466384
Test: manual
Test: atest cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ExternalStorageHostTest.java
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I0cc835471ced2822d83d7056bec53d62ddc682f0
Some of the pkg specific dirs could be created by zygote
and vold in parallel, so ignore any EEXIST errors while
creating these dirs.
Bug: 118185801
Test: manual
Change-Id: Ifaa9998131764304867ac027af335414dbfc291c
I'm not convinced this explains the full regression, but it's a
worthwhile fix anyway.
Bug: 124774357
Test: Booted in checkpoint mode and non checkpoint mode
Change-Id: I6e0e1e59e27bd127feac218fff7d88bb3570b530
When running a live GSI, userdata is a logical partition. If we don't
fix up the fstab we'll derive the underlying block device instead of
the device-mapper node for userdat_gsi, resulting in a corrupt data
partition for both images.
Bug: 123906417
Test: manual test
Change-Id: Ic0101f30504de26e725442da2da3888008c31b63
We've been dogfooding the isolated storage feature for many months
on various internal groups, and we're ready to enable it globally.
Bug: 112545973
Test: executed entire CTS suite using forrest
Change-Id: I612b6aba4f08dc0ac13f4f94b03c4bddd6de12df
Update vold to only create package sandboxes and not do any bind mounts.
After zygote forks, all the necessary bind mounts will be setup for
the process.
Bug: 124009234
Test: manual
Test: atest cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ExternalStorageHostTest.java
Test: atest DownloadProviderTests
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ia42209cb74cbc423bb09c1c51cb7a164f7c568da
This marks the slot as successful within commitChanges, increasing the
available roll back window significantly.
Test: When taking an update on a checkpoint enabled device, it
marks the slot as successful just before committing the
checkpoint. Visible in logs as call to vdc commitChanges,
followed by "Marked slot as booted succesfully."
Bug: 123260515
Change-Id: If71fcde57b3bdee2cfaabb590f123a2d00da3228
VoldUtils already has a pre-parsed fstab. Use it instead.
Test: Checkpoint functions continue to work
Change-Id: I96cbab467a7b809c92c4f6cdf7a06abca8c5aa5e