| d18829480c833dd9416a3778900cb4ddaad375b2 |
|
30-Jul-2016 |
Alex Deymo <deymo@google.com> |
Compile update_engine_sideload as a static recovery program.
This patch converts update_engine_sideload to a statically linked
program and installs it in the recovery image. The resulting program
uses a statically linked boot_control HAL instead of relying in
libhardware to dynamically load it.
The static library or libraries needed for the boot_control HAL need to
be specified by the product with the new make variable
PRODUCT_STATIC_BOOT_CONTROL_HAL. Otherwise, a stub implementation is
included and update_engine_sideload will fail at runtime.
Bug: 27178350
TEST=`make dist` builds a recovery image with update_engine_sideload in it.
(cherry picked from commit 44348e01c0c66e6baf1376f0b712ecae26fc5595)
Change-Id: I34fd1514eecbb2ddd89802891ea606418f28a60f
/system/update_engine/boot_control_android.cc
|
| a918f9daede277d043e5b3b8443d712c88c949da |
|
04-Jun-2016 |
Alex Deymo <deymo@google.com> |
Implement powerwash on Android.
Powerwash, the name for the equivalent of a factory reset or /data wipe,
can be triggered in Android by writing the desired command to the
recovery command file and rebooting into recovery.
This patch moves the powerwash scheduling/canceling logic to the
HardwareInterface and implements it on Android.
Bug: 28700985
TEST=Called update_engine_client passing POWERWASH=1, BCB is stored up
to offset 832.
(cherry picked from commit fb905d9b8d49f8fe41297c7aba2dd0942f1be311)
Change-Id: I66f9473c10fbe8f56e9000ce3e605b2bee345db8
/system/update_engine/boot_control_android.cc
|
| 12542ace0f43c5afaf1e7112556b71aea8454c79 |
|
04-Feb-2016 |
Alex Deymo <deymo@google.com> |
boot_control: Relax /misc partition name restriction.
Devices are not required to name the partition mounted on /misc
"misc". This patch relaxes this check to verify that the device is a
symlink, without forcing a particular name.
Bug: 25631949
TEST=Applied an update on a device with different partition name for /misc
Change-Id: I538657bce57f72387fdbe1c3b7f464ac98f29e99
/system/update_engine/boot_control_android.cc
|
| 1b03f9f983a22fabb8d53e036abf1b192e7d5811 |
|
09-Dec-2015 |
Alex Deymo <deymo@google.com> |
Move hardware and boot_control implementation to libupdate_engine.
The implementations of the BootControlInterface and HardwareInterface
are specific to the platform and use case. The delta_generator uses the
DeltaPerformer in the libpayload_consumer to apply a payload to a set
of partitions defined as local files, for example.
This patch move the platform implementations, not available when
building for the host back to the libupdate_engine.
Bug: 24619596
TEST=mma
Change-Id: I16ab06c2e53dfd046e693bdb7310ec26a2d69054
/system/update_engine/boot_control_android.cc
|
| 39910dcd1d68987ccee7c3031dc269233a8490bb |
|
10-Nov-2015 |
Alex Deymo <deymo@google.com> |
Split payload application code into a subdirectory.
This patch splits from the main libupdate_engine code the part that
is strictly used to download and apply a payload into a new static
library, moving the code to subdirectories. The new library is divided
in two subdirectories: common/ and payload_consumer/, and should not
depend on other update_engine files outside those two subdirectories.
The main difference between those two is that the common/ tools are more
generic and not tied to the payload consumer process, but otherwise they
are both compiled together.
There are still dependencies from the new libpayload_consumer library
into the main directory files and DBus generated files. Those will be
addressed in follow up CLs.
Bug: 25197634
Test: FEATURES=test emerge-link update_engine; `mm` on Brillo.
Change-Id: Id8d0204ea573627e6e26ca9ea17b9592ca95bc23
/system/update_engine/boot_control_android.cc
|
| 3f39d5cc753905874d8d93bef94f857b8808f19e |
|
13-Oct-2015 |
Alex Vakulenko <avakulenko@google.com> |
update_engine: Rename "chromeos" -> "brillo" in include paths and namespaces
libchromeos is transitioning to libbrillo and chromeos namespaces
and include directory is changing to brillo.
Bug: 24872993
Change-Id: I770659a95be380a50fe3b2ba9f91d65818f40945
/system/update_engine/boot_control_android.cc
|
| 31d95ac85d294b2b1bfa293835013e66c010fbcf |
|
17-Sep-2015 |
Alex Deymo <deymo@google.com> |
Mark the active slot from update_engine instead of /postinstall.
In Chrome OS, we were reliying on the /postinst script to generate the
verity hashes and mark the new kernel as bootable. This means that we
also need to run /postinst from the other (not verified) slot when
doing a user-initiated rollback. The update_engine already interacts
with the bootloader via the BootControlInterface to mark the other slot
as unbootable and check if there are other slots available for
rollback.
This patch moves the responsibility of marking the new slot as bootable
from the /postinst script to the update_engine, introducing a new
SetActiveBootSlot() method in the BootControlInterface. Chrome OS
builds will continue to mark the new slot as active from /postinstall
in order to be compatible with old builds, resulting in the new slot
marked as active twice during a successful normal update.
Bug: 23523562
Test: cros flash and image to the new daemon; rolled it back
Change-Id: I02502d7b8e85523a6eb9a7721053739e8381d266
/system/update_engine/boot_control_android.cc
|
| aa26f6240865d43f8cecc97bde7828f9b82bc17d |
|
17-Sep-2015 |
Alex Deymo <deymo@google.com> |
Move MarkBootSuccessful to BootControlInterface.
Updating the boot flags to mark the current boot as successful is
platform-specific and part of the BootControlInterface's job. This
patch moves this to a new async method in this interface.
Bug: 24077637
Test: FEATURES=test emerge-link update_engine; cros flash in Chrome OS; tested on a dragonboard.
Change-Id: I23c3ed915dd8d2588a90d84b212bb04977957975
/system/update_engine/boot_control_android.cc
|
| 753fadc8805f662e5af3a66f694207b04fbef8bb |
|
15-Sep-2015 |
David Zeuthen <zeuthen@google.com> |
BootControlAndroid: Implement using libhardware.
This simply calls into the a boot_control HAL implementation loaded with
libhardware. I've tested it with the implementation located in
system/extras/boot_control_copy.
The only non-trivial routine here is GetPartitionDevice() which I've
hand-tested on a device using the following snippet of code:
string names[] = {"boot", "system", "nope_enoent"};
for (string name : names) {
for (int slot = 0; slot <= 2; slot++) {
string device;
if (!GetPartitionDevice(name, slot, &device))
device = "NOTHERE";
LOG(INFO) << "slot:" << slot << " part:" << name << " -> " << device;
}
}
Change-Id: I1280325bd7cd4cf1cc9a33ef13c2f46f215da6e6
/system/update_engine/boot_control_android.cc
|
| b17327ce55e7132da1f64039040df93a8c260fef |
|
04-Sep-2015 |
Alex Deymo <deymo@google.com> |
New BootControlInterface implementation for Android.
This patch hides the platform-specific construction of a
BootControlInterface in a factory method shared by both Android and
Chromium OS. This also include a stub implementation for Android.
Bug: 23754584,23084776
TEST=emerge-link update_engine; `mma -i` builds these files without problem.
Change-Id: I43532e5cff1dc474453160f418ddd3c448f31938
/system/update_engine/boot_control_android.cc
|