am: 69a1fd86d3 -s ours
am skip reason: change_id I24f07ba89ba6e6dac8adc2a6bb654d75d2b73d3e with SHA1 e3b772e0f7 is in history
Change-Id: If121600192dd236e9b868d579459c566eaddbd69
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I890b572d537d66ecb49effd8efc782279c52956e
On user unlock when persist.sys.fuse property is set,
StorageManagerService calls into vold to link the primary
volumes. Because this involves accessing a FUSE path that
has not been initialized, vold should offload this work
from the binder thread, otherwise it would wedge and the
system server would wedge causing a Watchdog trigger.
This fixes a bug where we 'link primary' twice and vold
gets wedged on system server restarts.
Bug: 140064376
Test: with the FUSE property set:
adb shell stop && adb shell start && adb shell ls /sdcard
Change-Id: I0eb86f8ba256c385c916e2a0389a4f7482fc3775
Also allow the state just before doMount() as a valid state for setting
fuse fd.
Test: manual
BUG:140173712
Change-Id: I012f8a83fef00e68f33010954fbc2ebc53cf8f1d
Since system_server cannot mount devices by itself,
add a binder interface to vold that system_server
can call to initiate this mount when required.
BUG: 135341433
Test: manual
Test: atest --test-mapping packages/providers/MediaProvider
Test: ExternalStorageHostTest DownloadProviderTests
Change-Id: If4fd02a1f1a8d921a3f96783d8c73e085c5b7ca1
Current behavior:
Assume not checkpointing
cp_startCheckpoint creates the file in metadata
cp_needsCheckpoint will now set isCheckpointing to true
cp_commitCheckpoint will now think there is a checkpoint, and try to
commit it. This will fail on ext4 and it will return false, leading to
bad things.
cp_startCheckpoint is called when staging an apex module for update.
After this point, several things could go wrong:
If a keystore key is deleted, it calls cp_needsCheckpoint to see if the
delete should be deferred until cp_commitCheckpoint. The delete will now
be deferred, meaning that this key will never be deleted, using up the
key sots in trustzone
If a trim is scheduled through idle maintenance, this also calls
cp_needsCheckpoint, so the trims will not occur.
If either of these happens before a system crash, the device will not
recover since the system calls commitCheckpoint which will now crash.
When the system then goes on to reboot, the checkpoint will not be
triggered, since the commitCheckpoint call will have deleted the
checkpoint flag file before crashing.
Bug: 138952436
Test: vdc checkpoint startCheckpoint 5
vdc checkpoint needsCheckpoint
vdc checkpoint commitChanges
stop;start
commitChanges fails, then device loops
After applying this test, commitChanges succeeds and device does
not loop
Change-Id: I135099625f77344d1f8d2e8688735871c44ef2f5
If cp_commitCheckpoint is called twice at the same time, the second call
to setBowState will fail.
Add lock to remove possibility, and protect all uses of isCheckpointing
Bug: 138952436
Test: Boots after flashing in checkpoint mode
Change-Id: I131298adc506c3c176774d15e642b13d5f991087
Don't make stale zero'ing IO in block device after unlink, since filesystem
can reuse the block addresses and issue some IOs. If block layer reordered
two IOs, filesystem will see zero data, which crashes filesystem consistency.
Bug: 136964285
Test: run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.CrossProfileAppsHostSideTest
Change-Id: I43c13622d094cecda1c53468adc240002111d605
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Xin Li
Steven Moreland
Treehugger Robot
Zimuzo Ezeozue
Nandana Dutt
Paul Lawrence
android-build-team Robot
Jaegeuk Kim
David Anderson