tree 00b2b7b5e2548334f2d0035cdeae996660df7a6e
parent 88b591f24cb3f94f982d7024c2e8ed25c2cc26a2
author Gilad Arnold <garnold@chromium.org> 1405455886 -0700
committer chrome-internal-fetch <chrome-internal-fetch@google.com> 1409689533 +0000

update_engine: Ditch UpdateCheckScheduler, use UpdateCheckAllowed instead.

This change removes the update_check_scheduler module and replaces it
with async requests to the UpdateCheckAllowed policy, done by the
UpdateAttempter directly.

* A new UpdateAttempter::ScheduleUpdates() is used as a replacement for
  UpdateCheckScheduler::Run() and rescheduling of periodic checks inside
  UpdateCheckScheduler. The callback
  UpdateAttempter::OnUpdateScheduled() handles both periodic and
  interactive checks.

* The UpdateAttempter keeps track of whether or not an update check is
  being waited for (waiting_for_scheduled_check_) so that we can ensure
  liveness. This is a similar check to the one performed inside the
  UpdateCheckScheduler.

* Inference of the update target version prefix and channel (via device
  policy), as well as update disabled, are now performed by the
  UpdateManager policy. Also eliminating reference to the list of
  network types allowed by policy, which is not enforced anyway and will
  be superceded by another policy request (UpdateDownloadAllowed).

* Since update check scheduling is now performed relative to the last
  update check time (as recorded by the UpdateAttempter), we care to
  update this time as soon as the request is issued (in addition to when
  a response is received). This ensures that we won't be scheduling
  back-to-back update requests in the case where a response was not
  received.  Updating the last check time is delegated to a method call;
  we replace raw use of time(2) with the ClockInterface abstraction.

* Handling of forced update checks has been revised: the UpdateAttempter
  keeps track of the most recent app_version and omaha_url values that
  were received through DBus events; it notifies the UpdateManager not
  only of whether or not a forced (formerly, "interactive") update
  request is pending, but also whether or not it is indeed interactive
  or should be treated as a normal periodic one. The UpdateManager
  reflects this back to the updater via the result output of
  UpdateCheckAllowed, which tells the UpdateManager whether the custom
  app_version and omaha_url should be used (interactive) or not.

BUG=chromium:358269
TEST=Unit tests.

Change-Id: Ifa9857b98e58fdd974f91a0fec674fa4472e3a9d
Reviewed-on: https://chromium-review.googlesource.com/209101
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>