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/client_library/include/update_engine/update_status.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/client_library/include/update_engine/update_status.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/client_library/include/update_engine/update_status.h
|
cc8ce0e3b11ac76412c26c687d11140cbe18ad91 |
|
02-Oct-2015 |
Christopher Wiley <wiley@google.com> |
Move UpdateStatus and helpers to dedicated files This allows us to easily share it between the update_engine proper and a forthcoming client library. Bug: 24547247 Test: mmm system/update_engine; emerge-panther update_engine Change-Id: I8c0db7a0f95dd6368bfc886f1b0d1a9d2efb461f
/system/update_engine/client_library/include/update_engine/update_status.h
|