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>
2 files changed