History log of /system/update_engine/common/constants.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
0affc2c099fac47b999ba39f8f1bacb418e65a97 11-Feb-2017 Sen Jiang <senj@google.com> Parse multiple packages from Omaha response.

The multi-payload info are stored in OmahaResponse and InstallPlan, but
we still can only apply the first payload for now.

Bug: 36252799
Test: mma -j
Test: update_engine_unittests

Change-Id: I5ca63944ae9082670d0e67888409374f140d4245
(cherry picked from commit 2aba8a87d4fac245a2e2d238b3159f8eabce630f)
/system/update_engine/common/constants.h
5688d16057d34b770c070e2b4a27841092003a4e 06-Jun-2017 Tao Bao <tbao@google.com> Revert "Add functions to allow update over cellular (including tethered connection)"

This reverts commit 4b0d6032cbb86ce488c03b31936cda31283f97e3.

Bug: 62366504
Test: GmsCore sees the old status code (i.e. UPDATED_NEED_REBOOT == 6).
Change-Id: I9185614a41bd621ad85e7f773b0f96919b0f70d5
/system/update_engine/common/constants.h
4b0d6032cbb86ce488c03b31936cda31283f97e3 17-Apr-2017 Weidong Guo <weidongg@chromium.org> Add functions to allow update over cellular (including tethered connection)

- Add an update state NEED_PERMISSION_TO_UPDATE which is broadcasted along
with the update info (version and size) when |OmahaRequestAction| aborts
update due to cellular connection. So the state transition will be:
IDLE->CHECKING_FOR_UPDATE->NEED_PERMISSION_TO_UPDATE->REPORTING_ERROR_EVENT
->IDLE
(The Chrome UI prompts an alert window showing update size and asks user
whether to proceed upon receiving this state.)

- Add a dbus interface to set update over cellular target
(kPrefsUpdateOverCellularTargetVersion and kPrefsUpdateOverCellularTargetSize).
The target is the one received by Chrome UI in NEED_PERMISSION_TO_UPDATE
broadcast. By sending the target back with the dbus call, update engine can
double check the target with the server to make sure there's no new server
push after NEED_PERMISSION_TO_UPDATE is broadcasted to Chrome UI.
(This dbus call is invoked when the user chooses to proceed to update at the
alert window. The dbus call is followed by another dbus call |AttemptUpdate|)

- So, the the decision tree as to whether to allow update over cellular
connection has changed to:
IF (device policy DeviceUpdateAllowedConnectionTypes set)
follow device policy's decision
ELSE IF (kPrefsUpdateOverCellularPermission set to true)
allow update
ELSE IF (Either kPrefsUpdateOverCellularTargetVersion or
kPrefsUpdateOverCellularTargetSize is not set, or they are set but do not
match the version and size in |OmahaResponse| retrieved by
|OmahaRequestAction|)
disallow update, and broadcast NEED_PERMISSION_TO_UPDATE
ELSE
allow update
ENDIF

- This decision making happens at |OmahaRequestAction| after |OmahaResponse| is
retrieved. Since we want to separate the device policy check with the user
preferences check which depends on |OmahaResponse| during checking for update,
we modify ConnectionManager::IsUpdateAllowedOver by moving the user preferences
check to |OmahaRequestAction|. Thus, the function by default returns true for
cellular connection if device policy is not set.

- Corner case:
Adding kPrefsUpdateOverCellularPermission and
kPrefsUpdateOverCellularTargetSize seems to complicate the logic here. But
they could effectively solve a corner case where the target does not match
|OmahaResponse| due to new server push after broadcasting
NEED_PERMISSION_TO_UPDATE. In that case, we simply broadcast
NEED_PERMISSION_TO_UPDATE again along with new update info.

CQ-DEPEND=CL:481102
BUG=chromium:691108
TEST='FEATURES=test emerge-link update_engine'

(cherry picked from commit 70063d9f7e229db8c5b42443ca96ac23a971a6dd)
Cherry-pick updated to compile on Android.

Reviewed-on: https://chromium-review.googlesource.com/479467
Commit-Ready: Weidong Guo <weidongg@chromium.org>
Tested-by: Weidong Guo <weidongg@chromium.org>
Reviewed-by: Weidong Guo <weidongg@chromium.org>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Ben Chan <benchan@chromium.org>
/system/update_engine/common/constants.h
87792ea818a63f2d246bbba2b7429b85ee8d669f 26-Jul-2016 Alex Deymo <deymo@google.com> Allow to set the network used for an update attempt.

When triggering an update attempt in Android, we can force all the
traffic to go through a given network by passing a NETWORK_ID=<id>
in the extra key-value pair field.

Bug: 29921093
TEST=Called update_engine_client passing NETWORK_ID.

Change-Id: I13becdd133cccc912b542d48061fcfe9f566099a
/system/update_engine/common/constants.h
fb905d9b8d49f8fe41297c7aba2dd0942f1be311 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.

Change-Id: If737fd4b9b3e2ed9bce709b3b59f22e9f0a3dc9a
/system/update_engine/common/constants.h
b3fa53bf760bd0a6fd1ef9df28cb425586d733f6 19-Apr-2016 Alex Deymo <deymo@google.com> Parse and expose end-of-life flag.

Omaha update or noupdate response can include _key=value pairs with
arbitrary data. One of those key can be "_eol" with the one of the
values "supported", "security-only" or "eol" which notifies the device
the end-of-life status of the device with respect to updates. This
information is now exposed via GetEolStatus() to the client so it
can be properly displayed in the UI.

Bug: 27924505
TEST=Added unittest. Run `update_engine_client --eol_status` on link.

Change-Id: Icc15f25b4d0b19cc894f5afc52ac7c43c7818982
/system/update_engine/common/constants.h
fdd6dec9c4be2fbd667cf874c4cc6f4ffecaeef9 04-Mar-2016 Alex Deymo <deymo@google.com> Parse and use extra HTTP headers when downloading the payload.

Android OTA backend requires to pass an Authorization HTTP header in
order to download some payload. This patch allows to specify such
header when initiating a payload download from Android.

Bug: 27047110
TEST=Added unittests to check the headers sent.

Change-Id: Iece7e0ee252349bbaa9fb8545da2c34d2a76ae69
/system/update_engine/common/constants.h
390efedcb7e17587da765b6d682077cb7fa46ee1 18-Feb-2016 Alex Deymo <deymo@google.com> Parse postinstall parameters from the payload metadata.

Payload v2 includes a description of the post-install command it should
run, while in payload v1 we use the default values. This patch mounts
the partition on the new top-level directory called /postinstall that
should already be created.

Bug: 27177071
TEST=FEATURES=test emerge-link update_engine

Change-Id: Iaedf3b01e5e1ad57c68bd316b4b6e79cbab35bb6
/system/update_engine/common/constants.h
f25eb491ff60f21659a7e2b230ee1c83957034c7 26-Feb-2016 Alex Deymo <deymo@google.com> Fix resuming canceled updates.

Resuming an interrupted update was broken in several ways. First,
DeltaPerformer::CanResumeUpdate was checking for the number of
resume-failures to be more than the limit, not less. Then, the
resume logic didn't work for payload v2 when there was a
metadata signature included in the payload. Finally, resuming an
update after reading the payload signature (in payload v2) was not
updating the checkpoint, but storing the signature causing it to
attempt to parse it again and fail.

Bug: 27047026
Bug: chromium:590410
TEST=Manual procedure:
1. Start an update: update_engine_client --update ...
2. Cancel the update: update_engine_client --cancel
3. Re-start the same update: update_engine_client --update ...
-> The update should resume from the previous point.

Change-Id: I60134de155aa073a7ba91174cceea7297e5f8d17
/system/update_engine/common/constants.h
98e691cc6debda3ef671acba001bebd45da36377 05-Feb-2016 Alex Deymo <deymo@google.com> New "properties" sub-command to export payload properties.

The new brillo_update_payload sub-command "properties" dumps a list of
properties for a given signed or unsigned payload. These properties are
normally included in the Omaha response, and extracted from python in
chromite.

This new sub-command helps to encapsulate the properties used by the
server side wehn serving a payload and to let the Android application
pass these required properties.

The properties include the payload and metadata hash and size.

Bug: 26991255
TEST=FEATURES=test emerge-link update_engine
TEST=mmma system/update_engine
TEST=`brillo_update_payload properties` for signed and unsigned payloads.

Change-Id: I4602ea4b8dc269e4cc66df4293ef9765d8dd031d
/system/update_engine/common/constants.h
c1c17b4ed6a3896b6343e737fd89682fa0c8436b 23-Nov-2015 Alex Deymo <deymo@google.com> Report Enum metrics from CertificateChecker.

The certificate checker was reporting a "user action" whenever an
update check HTTPS connection or HTTPS payload download had an invalid
HTTPS certificate or a valid one that was changed since the last
connection to the same server.

This patch sends an Enum metric for every HTTPS connection to check for
and update or download the payload with one of the three options: an
invalid certificate, a valid one already seen or a valid but different
certificate.

This patch also moves these metrics to the metrics.{h,cc} module, where
all the other metrics are reported, using an observer pattern in the
CertificateChecker, needed to remove the dependency on the metrics
library from the libpayload_consumer.

Bug: 25818567
TEST=FEATURES=test emerge-link update_engine; mma;

Change-Id: Ia1b6eb799e13b439b520ba14549d8973e18bcbfa
/system/update_engine/common/constants.h
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/common/constants.h