History log of /system/update_engine/image_properties_chromeos.cc
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
558fe6ad38c6c419a135ce1ed1e3d1152f55ff7c 19-May-2017 Alex Deymo <deymo@google.com> Fix Chrome OS build of update_engine.

Fix a typo in image_properties_chromeos.cc, $ifdef out an unused
constant in Chrome OS and adds the bspatch library to the Chrome OS
build.

Bug: None
Test: FEATURES=test emerge-link update_engine
Change-Id: I483da4b43b5cbd8b7349b0ff42973f97d197ba8e
/system/update_engine/image_properties_chromeos.cc
ebf6e1228e6e42c19334bb8b3da62f4aef105dea 11-Mar-2017 Alex Deymo <deymo@google.com> Send the system image build fingerprint and bootloader versions.

In Android, we had STUBS for the bootloader (firmware) version, board,
and EC version. This patch populates those versions and strings based on
the system props using Android standard properties and includes the full
build.fingerprint in the request, which could be used to double-check
the request.

Bug: 35364971
Test: `update_engine_client --check_for_update` sends all this
information now.

(cherry picked from commit 094ce0bec1de7952e2ddc6c0f3c94dc3615b99c0)

Change-Id: I8265c5b8f4415f825160ea259c5b84b4b77372d7
/system/update_engine/image_properties_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/image_properties_chromeos.cc
5378f5e3d9420521a1afff935ed37b726d42ead6 11-Nov-2015 Alex Deymo <deymo@google.com> Initialize channel information on Init().

The channel information returned by dbus_service relies on the
OmahaRequestParams object being initialized, which didn't happen until
the first update check. This patch also fixes the store of the newly
selected channel.

Bug: chromium:551605,chromium:548486
TEST=deployed update_engine to a link device. Changed channels right after reboot.

Change-Id: I5070b3f8f09fc2ac5a74e2d40df9a2bea92df019
/system/update_engine/image_properties_chromeos.cc
3be05c82442b2fbab693b6399f64610e8542462b 23-Oct-2015 Alex Deymo <deymo@google.com> Fix use-after-free in unittest setup code.

When setting the root prefix in a unittest, we need to reset it after
so it isn't accidentally used by other tests.

Bug: chromium:547127
Test: USE="clang asan" FEATURES=test emerge-link update_engine

Change-Id: Ib84bbf265a380976407100a4fba4d2600d62dde6
/system/update_engine/image_properties_chromeos.cc
856166594771c61973856f563e622ccb7dd48aa1 16-Oct-2015 Alex Deymo <deymo@google.com> Read ProductId, ProductVersion and Channel setting in Brillo.

The ProductId, ProductVersion and current/target channels are specified
in a very different way in Brillo compared to Chrome OS. This patch
moves the logic to read and parse /etc/lsb-release in Chrome OS to a
new image_properties module and implements the equivalent module in
Brillo.

This new module replaces some of the logic previously in the
OmahaRequestParams class, both for parsing the read-only properties
from the rootfs and parsing and storing the target channel in the
stateful partition. The Chrome OS version of the new module keeps the
same behavior, except that it falls back to "stable-channel" if the
the current channel is missing in the rootfs (unlikely in Chrome OS).

On the other hand, the new Brillo implementation reads these settings
from the /etc/osrelease file and /etc/osrelease.d directory and doesn't
allow to override those setting during development. The persisted
target_channel and powerwash_allowed settings are stored in Prefs
as many other settings. Finally, since Brillo images don't contain
a channel name baked in the image, we store the channel name where we
got the image from at the time of the update. The first boot after
provisioning will default to "stable-channel".

Bug: 25013069
Test: unittest in Chrome OS; `mm` and tested on a Brillo device.

Change-Id: Icc114b8098af3edaaba715c9c2e3ebe9f417c876
/system/update_engine/image_properties_chromeos.cc