tree 890f9414a70df347f467c9d47c53af36a01a8007
parent 67363ee8c3c542e8799983cc4dd375b77e8252e9
author Gilad Arnold <garnold@chromium.org> 1412021669 -0700
committer chrome-internal-fetch <chrome-internal-fetch@google.com> 1412192790 +0000

update_engine: Respond to forced update requests when updates are disabled.

With the new UpdateCheckAllowed policy, we stopped changing the reported
state of the updater when update is permanently disabled, for example
when running from a USB image. This caused a problem whereas client code
(e.g. OOBE) expected the state of the updater to change as an indicator
for the fact that the update request is being processed.

This change fixes that by doing the following:

- Adds a new state (disabled) that is being signaled from the
  UpdateAttempter through the system API to DBus clients. This state is
  being used when UpdateCheckAllowed indicates that updates are
  permanently disabled; the state is immediately set the idle again, so
  that subsequent requests can also witness the state change.

- The code that rescheduled checks when the updater state was switched
  back to idle was pulled out of that method and placed at the callsites
  instead. It is now safe to call SetStatusAndNotify() from the callback
  of ScheduleUpdate() without incurring an infinite call chain.

- When an update request is received via DBus, we now make sure to call
  ScheduleUpdate() prior to broadcasting the forced update pending
  status. This ensures that the policy will be called on each DBus
  request, even if updates were formerly disabled.

BUG=chromium:417751
TEST=Unit tests.
TEST=Booting from USB on link, OOBE passes as expected.
TEST=update_engine_client yields the correct sequence of status readings.
CQ-DEPEND=CL:220374

Change-Id: I71eee1674d60956e39f953d44df86b61effd7800
Reviewed-on: https://chromium-review.googlesource.com/220404
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Alex Deymo <deymo@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>