summaryrefslogtreecommitdiff
path: root/update_status_utils.cc
AgeCommit message (Collapse)Author
2020-07-06Merge remote-tracking branch 'aosp/upstream-master' into mergeTianjie
It's a merge from chrome OS with some reverts. 1. the fd watcher change, because the libbrillo version isn't compatible in aosp. commit 6955bcc4ffe4cc9d62a88186b9a7e75d095a7897 commit 493fecb3f48c8478fd3ef244d631d857730dd14d 2. two libcurl unittest. Because the RunOnce() of the fake message loop seems to have different behavior in aosp. commit d3d84218cafbc1a95e7d6bbb775b495d1bebf4d2 Put preprocessor guards to use the old code in aosp. And we can switch to the new code in the other path after adopting the new libbrillo & libchrome. Test: unit tests pass, apply an OTA Change-Id: Id613599834b0f44f92841dbeae6303601db5490d
2020-05-20update_engine: Add powerwash flag to update statusMiriam Polzer
Add a powerwash flag to the update status which is set to true if and only if a powerwash takes place. This will ensure that the user is informed of a pending powerwash exactly when it is going to happen. BUG=chromium:1070563 TEST=FEATURES=test emerge-amd64-generic update_engine channel change and update on test device Cq-Depend: chromium:2187671 Change-Id: I58314ecc7c9c2e64c906ef5b31cb780948196296 Reviewed-on: https://chromium-review.googlesource.com/c/aosp/platform/system/update_engine/+/2187672 Reviewed-by: Jae Hoon Kim <kimjae@chromium.org> Reviewed-by: Amin Hassani <ahassani@chromium.org> Tested-by: Miriam Polzer <mpolzer@google.com> Commit-Queue: Miriam Polzer <mpolzer@google.com>
2020-03-05UpdateAttempterAndroid::Init initiates mergeYifan Hong
On update_engine starts, schedule CleanupPreviousUpdateAction that calls CleanupSuccessfulUpdate to do necessary cleanup as soon as possible. In the good case, update_engine initiates merge when sys.boot_completed, and clean up snapshots. If the update is rolled back or partitions are flashed, the following happens (on a Virtual A/B device): - UpdateAttempterAndroid::CleanupSuccessfulUpdate is called - DynamicPartitionControlAndroid::CleanupSuccessfulUpdate is called - SnapshotManager::InitiateMergeAndWait is called - SnapshotManager::RemoveAllUpdateState(before_cancel) is called - before_cancel is called, DeltaPerformer::ResetUpdateProgress is called - All update states in update_engine is reset. - SnapshotManager proceeds to delete snapshots - All update states in SnapshotManager is reset. Hence, on an VAB device, when an update is rolled back or partitions are flashed, the whole update needs to be re-applied (while in A/B, it skips writing and directly start verifying hashes of the target partitions because the update markers are still there). Bug: 147696014 Test: apply OTA then reboot, inspect logs and do `snapshotctl dump` Change-Id: I0fc5e7768dfb53e4fd474f2d8d85d2a1b615a88b
2020-01-24update_engine: post libchrome uprev clean-uphscham
BUG=chromium:909719 TEST=unit tests Change-Id: I9ec6c6d8cb23fbd49a86734648d95acc08b791e8 Reviewed-on: https://chromium-review.googlesource.com/c/aosp/platform/system/update_engine/+/2009957 Tested-by: Grace Cham <hscham@chromium.org> Reviewed-by: Amin Hassani <ahassani@chromium.org> Commit-Queue: Qijiang Fan <fqj@google.com>
2019-09-05update_engine: Pass is_enterprise_rollback in the StatusResultAmin Hassani
Currently Chrome uses some sort of version comparison to define whether an update is a rollback or not. But that is not very robust. The correct way is the return this value in the StatusResult. We already have this value as a placeholder in the update_engine.proto. So this is good to go. BUG=chromium:864672 TEST=FEATUERS=test emerge-reef update_engine Change-Id: I8bd3af0d94abd656dc00a9e67550ea6c6913de91 Reviewed-on: https://chromium-review.googlesource.com/c/aosp/platform/system/update_engine/+/1775116 Tested-by: Amin Hassani <ahassani@chromium.org> Commit-Queue: Amin Hassani <ahassani@chromium.org> Reviewed-by: Jae Hoon Kim <kimjae@chromium.org>
2019-08-05update_engine: Test update_engine printoutsJae Hoon Kim
These tests are added to enforce sensitive variables stay invariant with no room or future mistakes to occur again on breaking autotest and cros flash process. BUG=chromium:871340 TEST=FEATURES="test" emerge-$BOARD update_engine update_engine-client TEST=/usr/bin/update_engine_client --status TEST=cros flash $TEST_IP ../build/image/... # works Change-Id: Ibcce5c1dee56cf5bca201a86a143a87b033605bc Reviewed-on: https://chromium-review.googlesource.com/c/aosp/platform/system/update_engine/+/1732410 Tested-by: Jae Hoon Kim <kimjae@chromium.org> Auto-Submit: Jae Hoon Kim <kimjae@chromium.org> Reviewed-by: Amin Hassani <ahassani@chromium.org> Commit-Queue: Jae Hoon Kim <kimjae@chromium.org>
2019-08-01update_engine: Bug fix for UpdateEngineStatus printJae Hoon Kim
Exempt-From-Owner-Approval: The auto_updater.py depends on the status of update_engine from the printout of `--status`. It finds the key `CURRENT_OP`, but the CL in chromium:1715978 set that to `CURRENT_OPERAITON`. Is required for `cros flash` to work properly. Revert CURRENT_OPERATION to previous CURRENT_OP. Output now: [0801/095624.227871:INFO:update_engine_client.cc(490)] Querying Update Engine status... CURRENT_OP=UPDATE_STATUS_IDLE IS_INSTALL=false LAST_CHECKED_TIME=0 NEW_SIZE=0 NEW_VERSION=0.0.0.0 PROGRESS=0.0 BUG=chromium:871340 TEST=FEATURES="test" emerge-$B update_engine TEST=update_engine_client --status Change-Id: I23142dab51894adc2aeeb06f0459c74287b1639b
2019-07-30update_engine: Leverage install indication in StatusResult protobufJae Hoon Kim
Update engine will provide this install indication for signal listeners (specifically dlcservice) and status requesters to indicate whether update engine is in the process of installing or updating. With this, dlcservice will can be altered to not probe update engine for status during a DLC uninstall. The update engine client is also updated when getting the status from update engine by using KeyValueStore printouts now. Old output: [0725/202915.815630:INFO:update_engine_client.cc(501)] Querying Update Engine status... LAST_CHECKED_TIME=1564102396 PROGRESS=1.000000 CURRENT_OP=UPDATE_STATUS_IDLE NEW_VERSION=12354.0.2019_07_19_1136 NEW_SIZE=792 New output: [0726/173804.558077:INFO:update_engine_client.cc(490)] Querying Update Engine status... CURRENT_OPERATION=UPDATE_STATUS_IDLE IS_INSTALL=false LAST_CHECKED_TIME=1564187860 NEW_SIZE=792 NEW_VERSION=12369.0.2019_07_26_0904 PROGRESS=1.0 BUG=chromium:871340 TEST=FEATURES="test" emerge-$BOARD update_engine update_engine-client system_api TEST=/usr/bin/update_engine_client --status Cq-Depend: chromium:1717661 Change-Id: Iaacea27e0fc0711200ec81fdebb7fef45f94af43
2019-07-18update_engine: Use operation instead of current_operation from ↵Amin Hassani
update_engine.proto The current mechanism for interchaning the current operation of update_engine is quite old and very fragile to changes. Currently, each client defines its own set of operations, writes their own string to enum conversion logic, etc. We need to unify all these clients to use just one set of well defined operations. This CL uses the new enum Operation from the protobuf instead of transferring a string to identify the current operation of the update_engine. BUG=chromium:977320 TEST=precq Cq-Depend: chromium:1690424 Change-Id: I4d3a2a142c169cf6c972fe58d1d8d936d2349eed Reviewed-on: https://chromium-review.googlesource.com/1690683 Tested-by: Amin Hassani <ahassani@chromium.org> Commit-Ready: Amin Hassani <ahassani@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Xiaochu Liu <xiaochu@chromium.org> Reviewed-by: Sen Jiang <senj@chromium.org> Reviewed-by: Nicolas Norvez <norvez@chromium.org> Reviewed-by: Ben Chan <benchan@google.com>
2019-01-16update_engine: Run clang-format on ./ (root directory)Amin Hassani
BUG=none TEST=unittest Change-Id: Ibd075dc7ea9a18e798f612e35725f1c83c112809 Reviewed-on: https://chromium-review.googlesource.com/1409708 Commit-Ready: Amin Hassani <ahassani@chromium.org> Tested-by: Amin Hassani <ahassani@chromium.org> Reviewed-by: Sen Jiang <senj@chromium.org>
2018-03-19Reland update over cellular changesWeidong Guo
This merge cherrypicks two commits that was reverted in an AOSP git merge. 4b0d6032cbb86ce488c03b31936cda31283f97e3 Add functions to allow update over cellular (including tethered connection) 840703a4cc77228e2606f45665ae3a4bd75ff7dd Fix update over cellular network on guest account Handled multi-package response. Ran clang-format which fixed a lot of issues in those two CLs. BUG=chromium:815356 TEST=unittests, precq Change-Id: I54b6763c4c54755272531b558ed7628ceb0fc6c7 Reviewed-on: https://chromium-review.googlesource.com/965267 Commit-Ready: Amin Hassani <ahassani@chromium.org> Tested-by: Amin Hassani <ahassani@chromium.org> Reviewed-by: Ben Chan <benchan@chromium.org>
2017-06-06Revert "Add functions to allow update over cellular (including tethered ↵Tao Bao
connection)" This reverts commit 4b0d6032cbb86ce488c03b31936cda31283f97e3. Bug: 62366504 Test: GmsCore sees the old status code (i.e. UPDATED_NEED_REBOOT == 6). Change-Id: I9185614a41bd621ad85e7f773b0f96919b0f70d5
2017-05-31Add functions to allow update over cellular (including tethered connection)Weidong Guo
- 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>
2017-03-27Remove weave support from update_engine.Alex Deymo
This codepath is not used anymore. Bug: None Test: `make checkbuild`. Change-Id: I0f7f22d63cb2c3fbfabcda25763160e2470ef2c5
2016-01-06Implement update_engine weave commandsAlex Deymo
The new WeaveServiceInterface abstracs the registration and interaction with weave whenever present. The compilation and usage of weave is based on the BRILLO_USE_WEAVE flag. When enabled, update_engine registers the "_updater" component with methods to force-check for an update and change channels. Bug: 24386758 Bug: 24386768 Test: Deployed on edison, weave commands and state available online. Change-Id: Ic49111772e123b8a2b1971da92fe65785f186ccd
2015-10-05Add helper to convert strings to UpdateStatus valuesChristopher Wiley
This is useful for decyphering the statuses returned over the DBus interface. Bug: 24547247 Test: mmm system/update_engine; emerge-panther update_engine Change-Id: Ifce74450209a7e7cb632c2fee7b54364ffaf3ff5
2015-10-05Move UpdateStatus and helpers to dedicated filesChristopher Wiley
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
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-03 08:10:43 +0000