am: 1b535e41fd -s ours
am skip reason: change_id I135099625f77344d1f8d2e8688735871c44ef2f5 with SHA1 9a6d1f73e5 is in history
Change-Id: Ibfc9efb88aaac867a710529631a30fe33ba570d3
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
Merged-In: I135099625f77344d1f8d2e8688735871c44ef2f5
am: ccc84dec96 -s ours
am skip reason: change_id I74077bf8f727dab726c25f512ed7406a74cbe0bf with SHA1 c8a3ef3f3c is in history
Change-Id: I25f74556643e36061dd82c9947e1c5bd23563d13
Bug: 140882488
Test: Booted twice, checked logs to ensure encryption
is different each time, adb created files in directory.
Cherry-Picked-From: c8a3ef3f3c
Merged-In: I74077bf8f727dab726c25f512ed7406a74cbe0bf
Change-Id: I74077bf8f727dab726c25f512ed7406a74cbe0bf
Link .clang-format to the standard .clang-format file (4-space-indent
version) from build/soong, rather than use a custom file.
Among other changes, the standard file has the "IncludeBlocks: Preserve"
setting, so include blocks stay in order.
Don't actually reformat all the code yet.
Test: Tried 'clang-format -i $(find . -name \*.cpp -o -name \*.h)'
and checked that the changes look sane.
Change-Id: I11ecbd03b31e44ba7b3e01175a6fc317f8173ab0
Bug: 140882488
Test: Booted twice, checked logs to ensure encryption
is different each time, adb created files in directory.
Change-Id: I74077bf8f727dab726c25f512ed7406a74cbe0bf
am: 5ccd3e3c39 -s ours
am skip reason: change_id I24f07ba89ba6e6dac8adc2a6bb654d75d2b73d3e with SHA1 e3b772e0f7 is in history
Change-Id: I5113813143261cd2779447fe8f30c8c30d0167a3
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
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
