| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Test: manual
Bug: 139537581
Exempt-From-Owner-Approval: wear branch
Change-Id: I163ea0d5e716c9fad28fb2c64306ed24362c53c7
(cherry picked from commit c9c5fcf8d6c9a6be7a5e07bcf94a3f841eaaca25)
(cherry picked from commit 526bd581bca75f93778eb773674773de21fe8f54)
|
|
|
|
|
|
|
|
|
| |
After a reboot function call, we should always wait for it to finish
without executing other instructions.
Bug: 151110322
Test: build
Change-Id: I1dda291a0835ff96df7eaf42eba1a38267a3beeb
|
|
|
|
|
|
|
|
|
| |
Then we can override this function in the device specific recovery ui;
and allow customizing the help message.
Bug: 137965958
Test: Check the menu on sailfish
Change-Id: I09f23166f4205c5edf6c62eb42c8ada0fa710b26
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The following variables in recovery ui were protected by
key_queue_mutex. But the purpose of key_queue_mutex is to protect the
key_queue, which will be changed after we already have a key code. So
getting the key pressed should be orthogonal to the key queue. And
adding a mutex will help to avoid deadlocks in b/135078366.
Variables include:
char key_pressed[KEY_MAX + 1];
int key_last_down;
bool key_long_press;
int key_down_count;
bool enable_reboot;
Bug: 135078366
Test: boot into recovery and press keys
Change-Id: Ie2cfcf1f2fec49b53f8fac97aa9a2c60f15b84f9
|
|/
|
|
|
|
|
|
|
|
|
| |
It's a private member, and the last user has been removed in [1] in
2015.
[1] commit ec28340cf3af1029a00db1c83d78d14e8798e245,
https://android-review.googlesource.com/c/platform/bootable/recovery/+/146330
Test: mmma -j bootable/recovery
Change-Id: I65a2370cb20a7b296888425a44a42c8b90abc766
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Waitkey() is designed to obtain lock "key_queue_mutex" in
the very beginning of function.
int RecoveryUI::WaitKey() {
std::unique_lock<std::mutex> lk(key_queue_mutex);
...
}
However, there's case "key_queue_mutex" being applied again in
waitkey(), thus cause deadlock. There are two reproduce
scenario:
1.Executing "fastboot reboot recovery" in userspace
fastboot
2.Executing "adb reboot fastboot" in recovery os
When entering userspace fastboot/recovery, waitkey()
will wait there for user action. fastboot/adb commands
will trigger ui->interruptkey() to notify the thread
waitkey() in. In the next, waitkey() will move on and call
SetScreenSaveState(), which do LOG(ERROR) in fail case of
brightness set. LOG(ERROR) is designed to print log on
UI. Unfortunately, UI->print() applies lock "key_queue_mutex"
too, so deadlock happen.
Note:
Here is details how lock "key_queue_mutex" applied in
UI->print():
Function Print() call
Function PrintV() call
Function update_screen_locked() call
Function draw_screen_locked() call
Function draw_menu_and_test_buffer_locked() call
Function IsLongPress()
bool RecoveryUI::IsLongPress() {
std::lock_guard<std::mutex> lg(key_queue_mutex);
bool result = key_long_press;
return result;
}
Bug: 135078366
Test: no errors when running "fastboot reboot recovery" in userspace
fastboot & "adb reboot fastboot" in recovery os
Change-Id: Ida6b3c4ba9896a70021373f02a94954f0a60cf31
Signed-off-by: Zhang, GaofengX <gaofengx.zhang@intel.com>
Signed-off-by: Xihua Chen <xihua.chen@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
shutdown and reboot should have a corresponding sub-reason.
Adding:
"reboot,userrequested,fastboot"
"reboot,userrequested,recovery"
"reboot,userrequested,recovery,ui"
"shutdown,userrequested,fastboot"
"shutdown,userrequested,recovery"
"reboot,unknown#" (Can't happen, debug)
Test: manual, multiple targets, enter recovery, be able to exit recovery
Bug: 133326470
Change-Id: Ibfcb2a23158e8e99922e8053edd815fb592150f2
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 6f4e4db4f9e0911a07c6393d01e4380e844f7891.
Reason for revert: Booting out of recovery (choose `Reboot system now`)
on taimen is broken. Device keeps booting back into recovery.
Bug: 133326470
Test: Choose `Reboot system now` from recovery menu. Deivce attempts
normal boot.
Change-Id: I6e85fc248e18953a6fb94513c3abc7e7e0fb0477
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
shutdown and reboot should have a corresponding sub-reason.
Adding:
"reboot,fastboot_menu"
"reboot,recovery_menu"
"reboot,recovery_ui"
"shutdown,fastboot"
"shutdown,recovery"
"reboot,unknown#"
Test: none
Change-Id: Icf1ab0d462ec2de2272914a36994a095998d6186
|
|/
|
|
|
|
|
| |
Test: Choose `Reboot system now`, `Power off`, `Reboot to bootloader`
from recovery UI respectively.
Test: `adb reboot recovery` while under sideload mode.
Change-Id: I0f3d55b80b472178ea4f6970b29cd9df0778b639
|
|
This helps to expose librecovery_ui for device specific RecoveryUi.
Bug: 76436783
Test: mma, unit tests pass
Change-Id: Ic6c3d301d5833e4a592e6ea9d9d059bc4e4919be
(cherry picked from commit b5108c372c8b92671ea5ebb4eeff00757fcee187)
|