Noticed while looking at riscv64. Looks like a bug, but actually nothing
we can do about it now or for the foreseeable future.
Bug: https://github.com/google/android-riscv64/issues/45
Test: treehugger
Change-Id: I2be81b2fd7095df40958a1f641d7b89cf5a8e41d
Improve the comment, and increase the "minimum maximum" to 24 --- we
only support 64-bit, and 64-bit never has less than 24 bits.
Bug: https://github.com/google/android-riscv64/issues/1
Test: treehugger
Change-Id: I478c7649aa19258352c908a449cabe12da94952c
Updating comments to match current format. Scratch space exists in
between header and operation
Test: th
Change-Id: I2f86e9dc4078f03370cdc38918136c894c6ca484
this is going to replace the current version of CowOperation and will
work with writer v2 and parser v2. This will be the on disk format of
the cow, while CowOperation will be updated to be the in memory format
of 15 bytes (implicitly will be the v3 version).
Test: m libsnapshot
Test: m libsnapshot
Change-Id: Ibd00ef014a9fc11cdf2bad97c52462db8eef9502
This is to support when partition sizes are greater than 2GB (2^31)
on 32-bit userspace.
Bug: 300178204
Test: OTA on device with 32-bit userspace + product partition > 2GB
Change-Id: I7074682352d8388ed410c684cb7cb0fa346ba24c
Signed-off-by: Akilesh Kailash <akailash@google.com>
Adding block sz to compressor classes to prepare for variable block size
compression
Test: m libsnapshot
Change-Id: I84db20c80c0f95188f79ccc73b5c30678bd75e78
A clang update enabled -Wreorder-init-list by default. Since it doesn't
provide any benefit to the debuggerd code, disable the warning.
Test: Builds without warnings.
Change-Id: I75cfe064ba92c74312ba33f329b1364258eba06c
The fstab provided by the user/caller might not be the default fstab,
which might not include the /cache mount entry. We should just use the
procfs mount info to determine if /cache is currently mounted.
Bug: 300036012
Test: adb_remount test
Change-Id: I4643d0a21ae21f3513f715de424f0be1fe64ff9e
Two new API's have been added:
1: BootFromSnapshotsWithoutSlotSwitch: This will create a new marker
which indicates first-stage init to mount the partitions off snapshots.
We need this marker as during boot, there are couple of places during
mounting snapshots wherein the marker is used. However, there is no
change in the existing I/O path related to OTA.
2: PrepareDeviceToBootWithoutSnapshot: This will delete the marker so
that subsequent reboot will not have the partitions mounted without the
snapshots.
VTS tests covers both these API's. Additionally, when these
markers are present, new OTA's cannot be installed. All these
are covered in VTS tests.
===========================================================
snapshotctl: General flow to apply and revert pre-created snapshots
1: To install the pre-created snapshots:
$snapshotctl map-snapshots <directory path containing snapshots patches>
Now the device is ready to boot from snapshots.
2: After device reboots, partitions are mounted off the snapshots. There
is no snapshot-merge.
3: In order to go back to previous build:
$snapshotctl revert-snapshots
Now the device is ready to boot from base build.
4: After device reboots back to previous build, all the snapshot states
and COW images are removed.
============================================
Additional commands:
To delete the pre-created snapshots:
$snapshotctl delete-snapshots
======================================
Tested it on Pixel 6 Pro between two builds which are ~24 hours apart.
1: Creating snapshots on a linux-host - ~4-6 seconds
2: Applying pre-created snapshots - ~10-15 seconds (includes intermediate
transfer of patches to the device). This depends on the size of snapshot patches.
3: Device reboot - ~12-14 seconds.
Bug: 299011882
Test: 1: Apply pre-created snapshots
2: Reboot device: Verify new build
3: Apply OTA when partitions are mounted of snapshots and verify OTA
fails.
3: Revert-snapshot and reboot.
4: Verify device goes back to base build.
Full OTA on Pixel. vts_libsnapshot_test
Change-Id: I36a72d973d8f70ae49773ebd45dd996fac22a4e3
Signed-off-by: Akilesh Kailash <akailash@google.com>
This method was preserved under assumption it would be baked into many
prebuilts, but since it's inline, there should be no linkage to libutils
- thus, should be safe to remove anyway.
Bug: 35363681
Bug: 295394788
Test: treehugger
Change-Id: I59964935600e9e786424136177bfc8a70bebec67
