Make it possible to build a custom UI which uses EthernetRecoveryUI.
Since EthernetRecoveryUI must be used with EthernetDevice, but the
make_device() function is the only place a custom UI can be specified,
we need to move the common EthernetDevice to the recovery_ui core and
make a new "default_ethernet_device" which looks like the other
default device library stubs, for backwards compatibility.
This makes it possible to use EthernetRecoveryUI on cuttlefish.
Bug: 172693524
Change-Id: I6a66bb949ef97d06f532adb286d2db4c002d2924
The current fastbootd only supports USB protocol. But some Android TV
devices are built without USB port. The fastbootd cannot be used on
those ATV devices due to it. aosp/1295566 enables fastbootd over
ethernet.
This change adds an EthernetDevice to manage ethernet connection and set
fastbootd protcol property fastbootd.protocol to enable fastbootd over
ethernet in recovery mode. It uses IPv6 link-local address to not expose
the devices out of the network segment. The devices who want to use this
EthernetDevice should add
“TARGET_RECOVERY_UI_LIB := librecovery_ui_ethernet” into BoardConfig.mk.
BUG: 152544169
Test: Enter and exit fastboot mode and check eth0 IPv6 link-local address
on screen UI.
Change-Id: I73fe44be3790bdba5a6059fbba3f7264b21eed99
Recovery and fastbootd hardening.
With GKI we find in certain situations the timing of the drivers
loading is delayed as compared to a monolithic kernel. This
exasperates an existing race where during second stage init, the
graphics driver might not have completely instantiated by the time
fastboot or recovery menu ui is being set up.
To address this, we call gr_init() every 10ms until either 5 seconds
timeout or success. If we timeout, there will be no TUI (minui), but
this is better than if we just tried once and dropped the TUI and was
effectively running headless. 5 seconds timeout is arbitrary, based
on the default in init for wait for file; but makes sense as any
longer will impact flashstation and fastboot flashall enough to be
a cause for consternation.
It should be noted that both recovery and fastbootd can still service
adb or fastboot gadgets headless. For instance if the device tree is
misconfigured as a permanent issue that would head for the timeout.
Prefering to give up after a timeout so that device can be flashed by
fastbootd, or rebooted by recovery adbd, over the protocol is
advantageous for tool stability.
Architectural Concern:
The graphics driver, if not well written, may panic the kernel if we
try to access it too soon while it is probing. On such devices it
will be necessary to hold off in 'on init' or 'on early-init' phases
until the graphics drivers have completely probed. Or better yet,
fix the driver. This problem would happen in any case occasionally
even without this adjustments, but could conceivably be amplified by
the loop trying to open the graphics device.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 151950334
Test: make sure user space fastbootd comes up reliably for a GKI kernel
Change-Id: I1ce31a01544a58cdf7b9d657c1146bee77894e46
Virtual platforms may not have USB, but they can still use the SDCard
method. Allow the USB connection status to be faked so the 120s timeout
is not applied.
Bug: 155222461
Change-Id: I67f32c2b5b0941d5e3c0675dad23fe7121e5af86
After a reboot function call, we should always wait for it to finish
without executing other instructions.
Bug: 151110322
Test: build
Change-Id: I1dda291a0835ff96df7eaf42eba1a38267a3beeb
When display screen size is too small, some images in recovery
resource cannot caculate the right display position. So the
image cannot show in the screen.
Limit the calculated position to avoid such issue.
Change-Id: Iebebfe0dfbc568ee3a6b6a31b81d060b3ce5f940
Signed-off-by: zhang sanshan <sanshan.zhang@nxp.com>
Bug: 144974129
Test: Manual - Testing OTA and Factory Reset
1) Tested with matching device name ({devicename}00000.png)
2) Tested with no matching device name (uses loop00000.png default)
3) Tested with empty string device name (uses loop00000.png default)
Change-Id: I4c73af82ab8826d1a43fe193a7616bc219d536e4
Additionally kill the global variable: reason, stage; move them to a
separate BootState class instead. Vendor specific recovery code will
need to call getters from Device() class to access these variables.
Bug: 137705917
Test: unit tests pass, boot sailfish into recovery, code search and no
code includes common.h in vendor specific recovery.
Change-Id: Ia50a5ea951212c25548562f29cc9cf78505b5e34
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
The ShowMenu in StubRecoveryUI used to return initial selection
immediately. This leads to an immediate reboot if we enter recovery
with a stub UI and wait for user's input. This cl changes the behavior
of stub UI's ShowMenu so that it waits keys in loop, and only returns in
the case of interruption or time out.
Bug: 130535924
Test: start recovery with a stub UI, wait for the timeout
Change-Id: I96ad8aad8930756b09101bb98ba5fbe7b53bcb37
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 6f4e4db4f9.
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
bootloader will set `boot-rescue` in BCB command field to indicate
booting into rescue mode. This CL adds the matching parsing code.
This CL changes the on-screen UI to display the default image while
waiting for each sideload / rescue command.
It also changes the minadbd reboot handlers to use REBOOT_ instead of
the previous ENTER_ actions. This ensures a reboot going through
bootloader, which may load a newly installed bootloader/recovery.
Bug: 128505466
Test: Boot into rescue mode. Run `adb rescue getprop` and `adb rescue
install`. Check the UI. Then run `adb reboot rescue`.
Change-Id: I5b7de9dfd898ed8e14bea0d4ad7385a9bae26e94
We used to show the image for the last locale or an empty image, if
the localized image is missing for a specific locale. As the default
english one is more meaningful to users, we should just error out and
fall back to use the default locale when the image loading fails.
Bug: 128934634
Test: run graphic test, locale test
Change-Id: Iafd3e8466aec63b4952d1959b2a3d37e358677d4
This used to be a helper function that allows printing message to UI.
We no longer have any active user in bootable/recovery. Device-specific
code can achieve the same functionality by calling GetUI()->Print()
instead.
Test: mmma -j bootable/recovery
Change-Id: If584fc8a51d1af466f1d94d8ea5faa262603a784
This helps to expose librecovery_ui for device specific RecoveryUi.
Bug: 76436783
Test: mma, unit tests pass
Change-Id: Ic6c3d301d5833e4a592e6ea9d9d059bc4e4919be
(cherry picked from commit b5108c372c)
