When entering recovery via rescue party, recovery does not call
FinishRecovery() to reset BCB. This causes the rescue party command to
stick, and device keeps rebooting into rescue party mode after entering
bootloader mode and reboot.
Test: enter rescue party, reboot bootloader, fastboot reboot
Bug: 332621855
Change-Id: I958a77ccb2433d76aecb44f8c6f8fedebe08bbe0
Only allow test-key OTA to be installed on test-key devices,
and only allow release-key OTA to be installed on release-key devices.
Test: sideload recovery OTA
Bug: 314013134
Change-Id: I6609923929247ab498d3a315637765ae2d1370b0
This would succeed eventually anyway: the first time round the connect() succeeds, returns 0, and we go around the loop again; the second time the connect() fails (because we're already connected), returns -1, and we set success to true and exit the loop. But this means that the intended retry functionality is broken.
Change-Id: If631d59e23b12e9aa952cdb528160b19b9a94b1c
am skip reason: Merged-In Ibe3499c903c861fddba60acddda2ff563654a2ba with SHA-1 b630ec9be6 is already in history
Original change: https://android-review.googlesource.com/c/platform/bootable/recovery/+/2989113
Change-Id: Ida517f271e58a0aab57efb106d4fbe3635920451
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
am skip reason: Merged-In Ibe3499c903c861fddba60acddda2ff563654a2ba with SHA-1 b630ec9be6 is already in history
Original change: https://android-review.googlesource.com/c/platform/bootable/recovery/+/2989113
Change-Id: Ia60194114e4e9c3ca8d20b998654954d4257b231
Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
Add a misctrl specific message with its first use.
Future platform flags can go here for any purpose,
without needing to add separate utilities.
Check if a device has ever been in 16KB before so that
we are able to tell if 16KB causes any issues.
Bug: 317262681
Test: boot, bugreport
Change-Id: I21299ded1520020768462950713cbe49ca3c438f
Generic binary for managing the /misc partition.
This CL only uses it to do a basic health check for the /misc
partition, but the idea is this is a single place that can manage
misc partition operations for the Android platform, rather than
having to write a new tool each time.
Bug: 317262681
Test: boot, check bugreport
Change-Id: I29a4189e2e9aee57cf66520207297d39d666f7a4
This reverts commit c89b4e4314.
Reason for revert: reland the feature with bug fixed
Bug: 293313353
Test: Enter recovery with data wipe command
Change-Id: I2e1cfb91966c1af0145aac43cf11629cef9380d2
Define a new struct in the misc partition for telling the bootloader to
set kcmdline flags for enabling experimental dogfood features in the
kernel.
Test: Verified that a custom bootloader is able to read the data
Bug: 278052745
Change-Id: I5f13a9bdff940517cb7b880815dfb8f396fc3844
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
recovery mode does not have key services, so formatting volumes in
recovery would result in an unencrypted image.
If init detects an unencrypted /data image, encrypt_inplace would be
called. We would like to avoid using `encrypt_inplace` in production.
So do not format /data in recovery for regular data wipes.
Test: th
Bug: 293313353
Change-Id: I401da2a876ed22b426872c80c231397c12ec0737
When the updater compresses the file after the apply patch, unexpected results are generated, resulting in the failure of incremental OTA upgrade
Test: make imgdiff updater
Change-Id: I0d7652dca46c5b027f22670b254332fb8a5d5c98
Signed-off-by: luoqiangwei1 <luoqiangwei1@xiaomi.com>
For 16K dev options, we might need to reformat /data partition as ext4
before enabling the feature. Add necessary support to recovery.
Test: Trigger reboot with --wipe_data --reformat_data=ext4, make sure
/data is reformatted with ext4 on next boot
Bug: 293313353
Change-Id: I3cb67a62635a2df578472cd48cf6d2f5e04b5f82
