This allows us to resume rolling back in the event of an unexpected
shutdown during the restore process. We save progress after we process
each log sector, and whenever restarting the current log sector would
result in invalid data.
Test: Run restore, interrupt it, and attempt to resume
Change-Id: I91cf0defb0d22fc5afdb9debc2963c956e9e171c
Restores the first n entries of a checkpoint. Allows automated testing
of interrupted restores.
Test: vdc checkpoint restoreCheckpoint [device] [n]
Change-Id: I47570e8eba0bc3c6549a04a33600df05d393990b
In preparation for restore code, we need to guarantee fsync happens.
Switch over to fd based operations to prepare for that.
Test: Successfully restores device over reboots
Change-Id: Ic9901779e8a4258bf8090d6a62fa9829e343fd39
Motivation:
Early processes launched before the runtime APEX - that hosts the bionic
libs - is activated can't use the bionic libs from the APEX, but from the
system partition (which we call the bootstrap bionic). Other processes
after the APEX activation should use the bionic libs from the APEX.
In order to let both types of processes to access the bionic libs via
the same standard paths /system/lib/{libc|libdl|libm}.so, some mount
namespace magic is used.
To be specific, when the device boots, the init initially bind-mounts
the bootstrap bionic libs to the standard paths with MS_PRIVATE. Early
processes are then executed with their own mount namespaces (via
unshare(CLONE_NEWNS)). After the runtime APEX is activated, init
bind-mounts the bionic libs in the APEX to the same standard paths.
Processes launched thereafter use the bionic libs from the APEX (which
can be updated.)
Important thing is that, since the propagation type of the mount points
(the standard paths) is 'private', the new bind-mount events for the
updated bionic libs should not affect the early processes. Otherwise,
they would experience sudden change of bionic libs at runtime. However,
other mount/unmounts events outside of the private mount points are
still shared across early/late processes as before. This is made possible
because the propagation type of / is 'shared' .
Problem:
vold uses the equality of the mount namespace to filter-out processes
that share the global mount namespace (the namespace of the init). However,
due to the aforementioned change, the early processes are not filtered
out because they have different mount namespaces. As a result,
umount2("/storage/") is executed on them and this unmount event
becomes visible to the global mount namespace (because as mentioned before /
is 'shared').
Solution:
Fiter-out the early processes by skipping a native (non-Java) process
whose UID is < AID_APP. The former condition is because all early
processes are native ones; i.e., zygote is started after the runtime
APEX is activated. The latter condition is to not filter-out native
processes created locally by apps.
Bug: 120266448
Test: m; device boots
Change-Id: I054deedc4af8421854cf35be84e14995523a259a
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
Jiyong Park
Treehugger Robot
Daniel Rosenberg
Sudheer Shanka
Paul Lawrence
Xin Li
David Anderson
Jeff Sharkey