History log of /system/update_engine/common/error_code.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
5ed4f4c5b198066feefc4fd49107affa89dc559a 29-Jun-2017 Sen Jiang <senj@google.com> Add maximum timestamp to the payload.

Added a new field max_timestamp in the protobuf, from now on
update_engine will reject any payload without this field.
If the OS build timestamp is newer than the max_timestamp, the payload
will also be rejected to prevent downgrade.

Bug: 36232423
Test: update_engine_unittests

Merged-In: Ib20f5f35aaf41165013bada02bc8720917358237
Change-Id: Ib20f5f35aaf41165013bada02bc8720917358237
(cherry picked from commit 5011df680621eb477cad8b34f03fba5b542cc2f9)
(cherry picked from commit ccb01b2a3beb94094388de806bc15b210ebe8b11)
/system/update_engine/common/error_code.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/error_code.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/error_code.h
2494e28b88a819618c6325a5b081ef7de28549ee 30-Mar-2016 Kevin Cernekee <cernekee@google.com> Skip non-critical updates during OOBE update check

If the system has not yet completed OOBE, and Omaha returns a response
with an empty deadline field, avoid initiating a background update
because doing so may violate an enterprise policy that gets pushed
down post-enrollment.

Bug: None
BUG=chromium:587101
TEST=`FEATURES=test emerge-link chromeos-base/update_engine`
TEST=powerwash, install lsb-release file from an old stable build,
repeat OOBE, verify that download is skipped via logs, then verify
that update proceeds after logging into a standard gmail account

Change-Id: I6e6fae02c609b2763abc6e9960bf6d87dd3534e2
/system/update_engine/common/error_code.h
1f19dccb115cf608104b1cb0d192a53ae32f238f 03-Feb-2016 Alex Deymo <deymo@google.com> Add ErrorCode::kUserCanceled.

To accomodate the posibility of canceling an ongoing update, this patch
adds a new ErrorCode signaling a user canceling the update.

This patch also removes the now useless unittests that checks if you
added a new error code since the compiler fails if you don't add the
error code to the method mentioned in the test.

Bug: None
TEST=FEATURES=test emerge-link update_engine
TEST=`mmma system/update_engine` on edison-eng and aosp_arm-eng

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