The simulator skips executing the operations for dynamic partitions, and
will use the logical images under target_files/IMAGES directly. (Similar
to the targets without DAP enabled)
Bug: 131911365
Test: run update on cuttlefish, run simulator
Change-Id: Id318d97ece4560df9f20dc5cabeb8b2e261bdf9c
Prior to the change, SystemUpdaterSample was built as privileged app.
It must be installed along with the matching privapp-permissions
whitelist change (as noted in updater_sample/README.md), otherwise would
block device booting if installed unintentionally (e.g. with `mm` or
`mmma`).
This CL avoids putting the device in a bad state due to a sample app.
Fixes: 135703777
Test: `lunch aosp_taimen-userdebug && m -j installclean &&
mmma -j bootable/recovery && m -j`
Flash on device and boot successfully.
Test: Run the tests per instructions in updater_sample/README.md.
Change-Id: Ib8b587c77570f05f7db748fad84744fa45016aab
Factor out a new function from ApplyFromSdcard that installs a package
from a local path. Inside this function, we start the fuse and choose the
type of data provider depending on the path string. And similar to the
existing logic, we treat the package as a block map if the path starts
with a '@'.
This is part of the effort to install larger than 2GiB packages on ILP32
devices.
Bug: 127071893
Test: Build a 32 bit sailfish and create a 3GiB OTA package. Sideload
the package, uncrypt and install the package from sdcard.
Change-Id: I328ea34fa530731acbce7554bfc3059313ad6ece
libprocessgroup symbols are being moved into libcutils in order to
optimize linking/memory usage. libprocessgroup will no longer be
required in the future (however removing references to it will come
separately).
Since libcutils is used statically here, the dependencies of
libprocessgroup need to be explicitly listed.
Bug: 135145426
Test: boot
Change-Id: I91c082f0fa2f5f5c52751065cd5f50f5cb965b23
Therefore InstallPackage() doesn't need to worry about the details of a
given Package.
Bug: 127071893
Test: run update from /bin/recovery --update_package=@path, sideload a package
Change-Id: I0caa36785b43924f884ee398e7ea640d7472a92e
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>
Tao Bao
Treehugger Robot
Tianjie Xu
Android Build Merger (Role)
Zhijun He
Steven Moreland
Elliott Hughes
Zhang, GaofengX