anonymous/android_bootable_recovery - Team Win Recovery Project (TWRP)

	Commit message (Collapse)	Author	Age	Files	Lines
*	Consolidate the wait in recovery's reboot	Tianjie Xu	2020-03-14	1	-3/+0
\| \| \| \| \| \| \| \| \|	After a reboot function call, we should always wait for it to finish without executing other instructions. Bug: 151110322 Test: build Change-Id: I1dda291a0835ff96df7eaf42eba1a38267a3beeb
*	Create a new function to return the help message for menu	Tianjie Xu	2019-07-25	1	-1/+1
\| \| \| \| \| \| \| \| \|	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
*	Merge "Add a new key_pressed_mutex"	Tianjie Xu	2019-07-10	1	-6/+6
\|\
\| *	Add a new key_pressed_mutex	Tianjie Xu	2019-07-10	1	-6/+6
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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
* \|	recovery_ui: Remove RecoveryUI::last_key.	Tao Bao	2019-07-09	1	-2/+0
\|/ \| \| \| \| \| \| \| \| \| \|	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
*	Merge "Avoid key_queue_mutex deadlock in waitkey()"	Treehugger Robot	2019-06-13	1	-3/+3
\|\
\| *	Avoid key_queue_mutex deadlock in waitkey()	Zhang, GaofengX	2019-06-12	1	-3/+3
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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>
* \|	recovery: report compliant reboot reason (Part Deux)	Mark Salyzyn	2019-05-23	1	-1/+1
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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
* \|	Revert "recovery: report compliant reboot reason"	Tao Bao	2019-05-22	1	-1/+1
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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
* \|	recovery: report compliant reboot reason	Mark Salyzyn	2019-05-20	1	-1/+1
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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
* \|	Consolidate the codes that handle reboot/shutdown.	Tao Bao	2019-04-29	1	-1/+1
\|/ \| \| \| \| \| \|	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
*	Move librecovery_ui to a sub-directory	Tianjie Xu	2019-03-21	1	-0/+597
	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)