History log of /system/update_engine/boot_control_chromeos.cc
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
a3cf75a1d01aeb03d2341600ebff3db0a8316200 20-Jan-2016 Alex Vakulenko <avakulenko@google.com> update_engine: Update libchrome APIs to r369476

The new libchrome has been ported from Chromium and some APIs have
changed. Make necessary changes at call sites.

(cherry picked from commit 0103c36caa2e38e034e0d22185736b9ccfb35c58)

Change-Id: I3dedd8b3f6e92ce8d3eeef99a76ad876c29db304
/system/update_engine/boot_control_chromeos.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_chromeos.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_chromeos.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_chromeos.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_chromeos.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_chromeos.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_chromeos.cc
763e7dbaac735da0ae802933a1015b6b7874bce2 28-Aug-2015 Alex Deymo <deymo@google.com> update_engine: New BootControlInterface class.

The new BootControlInterface class is a platform-independent
abstraction to control the bootloader. It provides methods for setting
what partition slots are available for booting and getting the
bootloader status about the available slots.

The Chrome OS specific implementation of the bootloader was moved to
the BootControlChromeOS which now depends on the vboot_host
implementation used in Chrome OS. Follow up CL will implement the
equivalent class for Brillo.

BUG=b:23010637
TEST=unittests; cros flash from the new image and rolled back from it.

Change-Id: I0a03aeeb8c21d8c99e1866b625e6e8c96628215b
/system/update_engine/boot_control_chromeos.cc