GPIO test signal safe fallback + refactoring.
This addresses the problem of spurious GPIO signals indicating a test
scenario whereas in fact this isn't one, which may lead to hosts unable
to get an update (ZGB, Lumpy). This is also a partial fix to a problem
with Stumpy, where such spurious signals are inherent to the board
implementation.
* Safe fallback: a GPIO-signaled test scenario will be ignored other
than on the first time, in both places it is being checked
(UpdateAttempter::Update() and UpdateCheckScheduler::StaticCheck()).
This will ensure that we do not (a) override EULA/OOBE-complete flag
more than once; and (b) we do not attempt to update against a local
test server more than once. This generally covers against spurious
GPIO, as long as a user cannot trigger an update check on
a non-OOBE-complete system (appears to be a safe assumption).
* The retry timeout after failing an update with the test server is
shortened to 1 minute (compared to the default 45 minute). This
substantially increases the chances for a system exhibiting spurious
GPIO signals to get updates.
* Moved the GPIO functionality into a separate module/class. This makes
more sense now that it is being used by more than one class
(UpdateAttempter and UpdateCheckScheduler). The implementation of
GpioHandler has no instance data members and so behaves like
a singleton, but otherwise looks and feels like a normal class.
* Also changing the private test server URL to use an unregistered TCP
port (further reduces the chances of anything responding on the LAN).
* Some minor fixes.
BUG=chromium-os:27077, chromium-os:27109, chromium-os:25397,
chromium-os:27157
TEST=Unittests passed; GPIO reading + fallback work on x86-alex.
Change-Id: Ide1a60a690f1263efd47872360470347e56eeb45
Reviewed-on: https://gerrit.chromium.org/gerrit/17344
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
12 files changed