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
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
Copy the existing mount options when remounting f2fs for checkpointing
mode.
Bug: 123376509
Test: Boot with checkpointing, and ensure entries match fstab
Change-Id: If022d9872a44657b550ab892259230805716dc77
This returns true if any entries in the fstab have checkpoint=
set.
Test: Call vdc checkpoint supportsCheckpoint. Should return 1
iff an fstab entry has checkpoint=fs or checkpoint=block set
Bug: 111020314
Change-Id: Ic79bc96ded4da6605f73992dcff542e7cb50d705
We have a char buffer on the stack, which we then cast to a
struct, and then proceed to access elements in the struct.
This is not safe across all platforms, as some platforms
may require a certain alignment for members of the struct.
We fix this by assuring an appropriate alignment for our
char buffer.
We also use C++ casting, and rename our buffer to differenciate
it from the other 'buffer' variable in this function.
Test: TreeHugger
Change-Id: I8254cb6b8124e394bd805afd1ccca0faedb27ffa
We set a property when we commit a chackpoint to signal
to anyone who wants to do post commit cleanup.
Test: Boot to homescreen and check getprop for vold.checkpoint_committed
Bug: 111020314
Change-Id: Idf35e3abf9d24eb40c6926a30a8403064c05e10a
Only trys to commit if necessary, and reports errors
if commiting fails. RemoveFileIfExists returns true on
success.
Test: vdc checkpoint startCheckpoint, reboot, and then
vdc checkpoint commitChanges
Bug: 111020314
Change-Id: Ie1b3e49beb3ca04f2881fcc595882c607368b477
This switches the checkpoint calls that don't need to return a value
to return 0 on success, and an error on failure. This will be transalted
to exceptions for java binder users. needsCheckpoint and needsRollback
still return a boolean value.
Test: vdc setCheckpoint 2 then reboot 3 times checking state
Bug: 112901762
Change-Id: Idd3b5e6036631562a86d5123f533b86cf3bd6032
Merged-In: Idd3b5e6036631562a86d5123f533b86cf3bd6032
This adds implicit rollback support during A/B style updates.
If you explicitly start a checkpoint with -1, needsRollback will
trigger if the update fails, and should be used if any additional
cleanup is needed that is not covered by A/B itself.
Test: All Checkpoint tests pass
Bug: 111020314
Change-Id: I88b4a1098c6bac4dc1438a54c8a8f59577a6c17b
Checkpointing uses a combination of files on the meta partition
and the checkpoint= fs_mgr flag. Checkpointed partitions will
revert to their starting state on reboot unless checkpoint commit
is called.
Test: Run vdc commands, check file on metadata
Merged-In: Icba16578608a6cbf922472e9d4ae5b8cf5f016c6
Change-Id: Icba16578608a6cbf922472e9d4ae5b8cf5f016c6