tree aa79f951ea4f50fcd33d613aa1991b6c30b00869
parent d6803aa21c1fcd2c8cce9b82fa73b5f9e3200b59
author Weidong Guo <weidongg@chromium.org> 1492448918 -0700
committer Sen Jiang <senj@google.com> 1496271362 -0700

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>