Add Installer.UpdatesAbandonedCount metric

This patch adds a new metric Installer.UpdatesAbandonedCount to track
the number of update attempts that didn't complete because a newer
update was detected during the download. This is implemented by
counting the number of different responses seen since the last
successful update.

Updates are typically only abandoned if a device is suspended or
powered off while an update is happening. This can happen either
because the device was not turned on for a very long time or because
it had little or no connectivity to Omaha and/or the servers serving
the payload.

This metric will help show how many users run into this problem.

BUG=chromium:248800
TEST=New units tests + Unit tests pass + Manually tested

Change-Id: I524a380a931c2fb30916d033b7e5b0c700f57103
Reviewed-on: https://gerrit.chromium.org/gerrit/59098
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: David Zeuthen <zeuthen@chromium.org>
Commit-Queue: David Zeuthen <zeuthen@chromium.org>

Implement Rollback to previously booted partitions.

This CL implements rollback to whatever partition we ran from before.
We expose this functionality via dbus under AttemptRollback and expose
a new command-line option to update_engine_client that a developer can
use.

BUG=chromium:242665
TEST=Unittests, full update, update + rollback and verified.

Change-Id: Ie59f90b9a0b777dc1329592449090c70892236bf
Reviewed-on: https://gerrit.chromium.org/gerrit/58427
Commit-Queue: Chris Sosa <sosa@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: Chris Sosa <sosa@chromium.org>

Revert "Continue with an older update if update progress is 30% or more"

This reverts commit 249030ef688639585974d7fd2b4383f695551da0.

The problem with this patch is that if we decide to resume an older
update, we will already have overwritten the persistent data used by
PayloadState.

BUG=chromium:244538
TEST=None
Change-Id: Ifb19a399e0afb35e974670ae4171d24b5b1491a5
Reviewed-on: https://gerrit.chromium.org/gerrit/58937
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: David Zeuthen <zeuthen@chromium.org>
Tested-by: David Zeuthen <zeuthen@chromium.org>

Continue with an older update if update progress is 30% or more

This feature is desirable in cases where a device is used infrequently
on a network with little or no bandwidth to the update servers. In a
nutshell, the problem is that the device will start downloading an
update but it's so slow that it will see a new update before it's
done. This new update will cause the device to throw away the old
update (and thereby the resources it has already expended downloading
it) and then start over again. Which means downloading an update and
then get interrupted again. Rinse and repeat. With this change, we'll
at least converge against an update (albeit, perhaps an old one)
instead of starting over again and again.

To implement this feature, a new "update-state-overall-progress"
persistent variable (so-called "preference" according to the codebase)
is introduced so we can easily evaluate the progress without having to
parse the manifest again.

This feature is difficult to test with devserver since it's always
using the same URL, e.g.

 http://your-workstation.corp.company.net:8080/static/update.gz

meaning that it's not possible to actually continue an older update
server from deverser. What happens is that update_engine will happily
continue downloading and apply the update, but it will fail with
something like kErrorCodePayloadSizeMismatchError because it's getting
the new payload while expecting the old. This is not a problem per se,
it will just cause us to abandon the update attempt.

Fortunately, to verify that the patch works, it's sufficient to just
check the log files for these messages

 [0612/163553:INFO:delta_performer.cc(1144)] Abandoning current update (at 12% completion) because there is a newer update available.

 [0612/164451:INFO:delta_performer.cc(1139)] Resuming current update (at 51% completion) despite the fact that there's a newer update.

BUG=chromium:244538
TEST=Unit tests pass + Manually tested (see above)

Change-Id: Ibfb2fe10fe1883bfadf132f22b802ca3482c699e
Reviewed-on: https://gerrit.chromium.org/gerrit/58470
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: David Zeuthen <zeuthen@chromium.org>
Tested-by: David Zeuthen <zeuthen@chromium.org>

Add EC and Firmware Versions to the Omaha Response.

This CL adds 2 additional utils methods to get the version for both the
fw and ec versions. I've added a unittest to verify these work and piped
in the values into the omaha response.

BUG=chromium:219871
TEST=Unittests + on device

Change-Id: Iadf70fff858988f52797d94bcdb062bb2482bbf3
Reviewed-on: https://gerrit.chromium.org/gerrit/49713
Commit-Queue: Chris Sosa <sosa@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: Chris Sosa <sosa@chromium.org>

AU: removing unnecessary braces (cosmetic)

BUG=None
TEST=None

Change-Id: Ib07c7620057f90030000055166982ebac1c89d7a
Reviewed-on: https://gerrit.chromium.org/gerrit/56671
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>

Revert "Revert "AU: do not copy filesystem during full updates""

This reverts commit d1cd325c3135d88498483da811b594ba6b91ce42

The problem that caused all autotests to fail with the original CL has now been rectified; lab devservers were updated to send the correct delta flag in their omaha response.

Change-Id: I664afb33f72856572baaa658cbd473c07271af36
Reviewed-on: https://gerrit.chromium.org/gerrit/56600
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>

Revert "AU: do not copy filesystem during full updates"

This reverts commit 81c90628abb268c9e54f655c2493b4495b5cf91e

This broke all of the Canaries with NPO update tests. It may be because devserver changes require manual staging into the autotest framework.

An example test:

http://cautotest/afe/#tab_id=view_job&object_id=3064976

Test Logs:

https://storage.cloud.google.com/?arg=chromeos-autotest-results/3064976-chromeos-test/chromeos2-row5-rack1-host9/debug#chromeos-autotest-results%2F3064976-chromeos-test%2Fchromeos2-row5-rack1-host9%2Fautoupdate_EndToEndTest.npo_test_delta%2Fsysinfo%2Fvar%2Flog_diff%2Fupdate_engine

UE Logs:

[0522/183224:INFO:chrome_browser_proxy_resolver.cc(168)] dbus_g_proxy_call succeeded!
[0522/183224:INFO:libcurl_http_fetcher.cc(63)] Starting/Resuming transfer
[0522/183224:INFO:libcurl_http_fetcher.cc(74)] Using proxy: no
[0522/183224:INFO:libcurl_http_fetcher.cc(52)] We are connected via ethernet, Updates allowed: Yes
[0522/183224:INFO:libcurl_http_fetcher.cc(180)] Not setting http(s) curl options because we are in test mode or running a dev/test image
[0522/183224:INFO:libcurl_http_fetcher.cc(485)] Setting up timeout source: 1 seconds.
[0522/183224:INFO:delta_performer.cc(104)] Completed 0/? operations, 15677/681963 bytes downloaded (2%), overall progress 1%
[0522/183224:WARNING:delta_performer.cc(327)] Ignoring missing/incorrect metadata size (0) in Omaha response as validation is not mandatory. Trusting metadata size in payload = 1410
[0522/183224:INFO:utils.cc(824)] Sending error code 32 (kErrorCodeDownloadInvalidMetadataSize) to UMA metric: Installer.DevModeErrorCodes. Flags = TestOmahaUrl, TestImage
[0522/183224:WARNING:delta_performer.cc(791)] Cannot validate metadata as the signature is empty
[0522/183224:INFO:utils.cc(824)] Sending error code 39 (kErrorCodeDownloadMetadataSignatureMissingError) to UMA metric: Installer.DevModeErrorCodes. Flags = TestOmahaUrl, TestImage
[0522/183224:ERROR:delta_performer.cc(852)] Purported full payload contains old partition hash(es), aborting update
[0522/183224:ERROR:download_action.cc(102)] Error 6 in DeltaPerformer's Write method when processing the received payload -- Terminating processing
[0522/183224:INFO:delta_performer.cc(216)] Discarding 15677 unused downloaded bytes
[0522/183224:INFO:update_attempter.cc(724)] Download status: inactive
[0522/183224:INFO:multi_range_http_fetcher.cc(155)] Received transfer terminated.
[0522/183224:INFO:multi_range_http_fetcher.cc(107)] TransferEnded w/ code 200
[0522/183224:INFO:multi_range_http_fetcher.cc(109)] Terminating.
[0522/183224:INFO:prefs.cc(27)] delta-update-failures not present in /var/lib/update_engine/prefs
[0522/183224:INFO:action_processor.cc(68)] ActionProcessor::ActionComplete: DownloadAction action failed. Aborting processing.
[0522/183224:INFO:action_processor.cc(73)] ActionProcessor::ActionComplete: finished last action of type DownloadAction
[0522/183224:INFO:update_attempter.cc(578)] Processing Done.
[0522/183224:INFO:utils.cc(673)] Setting cgroup cpu shares to  1024
[0522/183224:INFO:update_attempter.cc(963)] CPU shares = 1024
[0522/183224:ERROR:update_attempter.cc(934)] Update failed.

Change-Id: I69d3b93711707d9429201865346fd50117338718
Reviewed-on: https://gerrit.chromium.org/gerrit/56351
Commit-Queue: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>

AU: gitignore update

This ignores temporary directories used for unit testing; apparently,
devs tend to run unit tests inside their source directory, e.g. using
./run_unittests, so this is annoying.

BUG=None
TEST=Directories ignored by git

Change-Id: I4ad67909605d899c78e8579b3981f39d8c8dd2fe
Reviewed-on: https://gerrit.chromium.org/gerrit/56298
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

AU: do not copy filesystem during full updates

The filesystem copying stage is redundant during full updates, where the
partition is being entirely overwritten regardless of its previous
content. It is also a very wasteful step, causing intensive I/O and
kernel buffer pressure, and known to (sometimes) cause jank and
otherwise have detrimental effects on our user experience.

This CL eliminates filesystem copying for full updates:

1) The decision is based on whether the Omaha response indicates that
   this is a full update.

2) To be safe, we also ensure that the payload manifest does not contain
   old partition hashes, which is indicative of a delta update.

Note that it is generally desirable to base the decision solely on #2
above (and ignore #1 altogether). However, this will require more
extensive re-engineering of the update flow, as filesystem copying
currently happens prior to the manifest being downloaded.

BUG=chromium:189855
TEST=Full and delta updates run correctly on x86-alex

Change-Id: Ic0dc6e32913cfb96019606624ec6b87c2e5b3ebb
Reviewed-on: https://gerrit.chromium.org/gerrit/43665
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Download via HTTP only if enterprise policy allows.

In order to rollout HTTP-downloads for AU to stable channel, we want to
be a bit more conservative to preseve the defense in depth we have now
with HTTPS. So, we're introduced a new enterprise policy which should be
explicitly enabled in order for the payloads to be downloaded via HTTP.

This CL adds the support for honoring such a policy in update engine.

BUG=chromium:235562
TEST=New unit tests added, existing ones updated and they all pass.
TEST=Tested on ZGB with and without policy and it works as expected.
Change-Id: I356efbe237b10031161a57c70cb851c521915a76
Reviewed-on: https://gerrit.chromium.org/gerrit/55805
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>

Change the default partition size to 2GiB if not specified.

BUG=chromium:242276
TEST=Built and tested against a R26 and non-R26 image.

Change-Id: I5d685ad62d444c044b971ba44574b8b55c7a96de
Reviewed-on: https://gerrit.chromium.org/gerrit/56091
Tested-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: Chris Sosa <sosa@chromium.org>

Fix size_t issue when the image size is > 2GiB.

BUG=chromium:241256
TEST=cros_generate_update_payload with PGO image.

Change-Id: I7220ddb61c7e0a6844d41378ee12f5fd0074bff4
Reviewed-on: https://gerrit.chromium.org/gerrit/55596
Tested-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: Chris Sosa <sosa@chromium.org>

Add human friendly payload information to the manifest.

This adds new strings to the payload manifest that describe what images
the payload updates from/to. These strings are passed in when delta_generator
is invoked, and are trusted implicitly.

BUG=chromium:226310
TEST=Built/Updated.

Change-Id: I278137c97cf8376d4e2fd8e82402cbb7d4f1a104
Reviewed-on: https://gerrit.chromium.org/gerrit/47347
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: Don Garrett <dgarrett@chromium.org>

AU: Don't use sparse holes as scratch space in the delta generator.

This patch fixes a number of bugs related to handling of sparse holes
in the context of scratch space in the delta diff generator and adds
appropriate unit tests. Most notably:

- Ignore sparse holes for the purposes of ExtentRanges. This prevents
  the generator from using sparse holes as scratch.

- Adds two unit tests to catch using sparse holes as scratch in a more
  deterministric way.

- Handle correctly sparse holes in
  GraphUtils::AppendBlockToExtents. For example, previously, if one
  adds block 0 to a single-block kSparseHole extent, the extent would
  have been simply extended.

BUG=chromium:238440
TEST=unit tests, trybots

Change-Id: I3fedcc93af319ee741821ad9d1a2a57b7a7d5de2
Reviewed-on: https://gerrit.chromium.org/gerrit/50448
Commit-Queue: Darin Petkov <petkov@chromium.org>
Reviewed-by: Darin Petkov <petkov@chromium.org>
Tested-by: Darin Petkov <petkov@chromium.org>

Add DownloadSourcesUsed and DownloadOverheadPercentage metrics.

DownloadSourcesUsed: This metric will tell us the various combinations of
the protocols and servers that were used in completing the download for
each successful update attempt.

DownloadOverheadPercentage: This metric will indicate how efficient our
download mechanisms are by calculating the overhead we incurred as a percentage
of the number of bytes that were actually needed to do the update
successfully.

BUG=chromium:225953
TEST=Unit Tests added, chrome://histograms shows new metrics correctly.

Change-Id: Ic1e9547a9a27e1aad53f7e30c70d822820d2c60f
Reviewed-on: https://gerrit.chromium.org/gerrit/48856
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

AU: Minor DeltaPerformer cleanup.

- Use DCHECK rather than DCHECK_EQ to avoid printing of non-readable
  characters on failure.

- Don't store the return-by-value result of StringPrintf as a
  reference.

BUG=chromium:196378
TEST=unit tests

Change-Id: Ibf912061627c56a9f5d82f6979b6fb8e3f7c6717
Reviewed-on: https://gerrit.chromium.org/gerrit/49879
Tested-by: Darin Petkov <petkov@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: Darin Petkov <petkov@chromium.org>

Allow callers to override the default partition size.

Callers should know the actual size of the image on the device. If they do,
use that and not our hard-coded constant.

BUG=chromium:234556
TEST=Running it on canary try jobs

Change-Id: I1f4e268d218d83d5499fd1561f8aacf8c4b0f7c2
Reviewed-on: https://gerrit.chromium.org/gerrit/48963
Commit-Queue: Chris Sosa <sosa@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: Chris Sosa <sosa@chromium.org>

Rename ActionExitCode to ErrorCode

Nowadays ActionExitCode is used throughout the codebase so use a more
generic name to reflect this.

BUG=chromium:216507
TEST=unit tests pass

Change-Id: I23d1d7e2676443251dbc42ed137fd018aadfa8a3
Reviewed-on: https://gerrit.chromium.org/gerrit/49512
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: David Zeuthen <zeuthen@chromium.org>
Tested-by: David Zeuthen <zeuthen@chromium.org>

AU: Handle moving of sparse block extents correctly in DeltaPerformer.

Rather than reading from sparse holes, just reset the buffer with zeros. Drop
writes to sparse holes (and DCHECK that the data to be written is all zeros).

This patch also adds the following tests:

- Move a file of zeros into a sparse file.
- Move a sparse file into a file of zeros.
- Move a partially sparse file.

BUG=chromium:196378
TEST=unit tests

Change-Id: Idab8d44b391fbe7714c7fd53f7f383c9bf81edc1
Reviewed-on: https://gerrit.chromium.org/gerrit/49172
Commit-Queue: Darin Petkov <petkov@chromium.org>
Reviewed-by: Darin Petkov <petkov@chromium.org>
Tested-by: Darin Petkov <petkov@chromium.org>

Add unit tests for duration metrics

As a side-effect, move utils::GetMonotonicTime() into the newly added
ClockInterface type.

BUG=None
TEST=Unit tests pass

Change-Id: I972a7e4ba37b63f96348fbeda901697b8ba2fc05
Reviewed-on: https://gerrit.chromium.org/gerrit/48814
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: David Zeuthen <zeuthen@chromium.org>
Commit-Queue: David Zeuthen <zeuthen@chromium.org>

AU: Optimize BzipExtentWriter's memory use.

This patch introduces the following two changes:

- Reduces the output buffer size from 1MiB to 16KiB.

- Avoids copying of the input data when there's no leftover data. This
  covers the current DeltaPerformer usage of the writer.

BUG=chromium:234578
TEST=unit tests; tested full update on device

Change-Id: I44f74b4fd8b05b082fde84d5ac06d9b1c1177b81
Reviewed-on: https://gerrit.chromium.org/gerrit/49047
Tested-by: Darin Petkov <petkov@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: Darin Petkov <petkov@chromium.org>

Use better histogram parameters for duration metrics

In the current code this is capped at 20 minutes which is not helpful
as we're interested in data for devices that take much longer to
update. Instead, use one year for UpdateDuration and one month for
UpdateDurationUptime. Also move the code that sends the metric into
PayloadState to better conform with newly added code.

Also rename the metrics to they have the suffix Minutes. E.g. the new
metric names are

 Installer.UpdateDurationMinutes
 Installer.UpdateDurationUptimeMinutes

Also add unit test for utils::FormatTimeDelta().

BUG=None
TEST=Unit tests, look at chrome://histogram

Change-Id: I8581ec111f9833bdd72f10888c9626f40779f8b9
Reviewed-on: https://gerrit.chromium.org/gerrit/48558
Commit-Queue: David Zeuthen <zeuthen@chromium.org>
Reviewed-by: David Zeuthen <zeuthen@chromium.org>
Tested-by: David Zeuthen <zeuthen@chromium.org>

Add update reboot metric to the update engine.

This change add the Installer.UpdateNumReboots metric.

This records the number of reboots that occurred while an update was being
attempted. It uses a marker file stored in tmp to discover whether or not
it's already recorded the reboot.

BUG=chromium:226766
TEST=Unittests | ran an update on a test machine and rebooted/resumed and
checked about:histograms to confirm numbers. Also restart update-engine to
verify it didn't double count that.

Change-Id: I5d2af9d5b62a9d974c7c6243a89cb3359051b650
Reviewed-on: https://gerrit.chromium.org/gerrit/47710
Tested-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: Chris Sosa <sosa@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>

Add metric to report number of URL switches per update attempt

BUG=chromium:226765
TEST=Existing unit tests modified to test feature, Unit tests pass

Change-Id: I5ee0816cac3fa4fa641949ed4872aef8074e3fcc
Reviewed-on: https://gerrit.chromium.org/gerrit/48537
Commit-Queue: David Zeuthen <zeuthen@chromium.org>
Reviewed-by: David Zeuthen <zeuthen@chromium.org>
Tested-by: David Zeuthen <zeuthen@chromium.org>

AU: Optionally limit the size of delta update operations.

Add a --chunk_size flag to delta_generator. If it's not -1, files will
be split into chunks of this size when generating delta payloads. This
effectively limits the size of each delta operation.

BUG=chromium:229797
TEST=unit tests; generated delta payloads and checked them through
paycheck.py.

Change-Id: I21502118088bfbac75aa8009eb144f6aaf23a83a
Reviewed-on: https://gerrit.chromium.org/gerrit/48357
Commit-Queue: Darin Petkov <petkov@chromium.org>
Reviewed-by: Darin Petkov <petkov@chromium.org>
Tested-by: Darin Petkov <petkov@chromium.org>

Add metrics to report the number of bytes downloaded per protocol.

This CL adds these two basic metrics:
1. The number of megabytes downloaded using each protocol (or source
in general, as we want to consider HTTP downloads from server and possibly
a peer in future as two different sources) for each successful update. The
totals across all protocols will equal the payload size exactly.
2. The total number of megabytes downloaded since the last update attempt.
If there are no errors, this should be same as above. Otherwise, this will
be larger and will help us to compute the update efficiency.

BUG=chromium:225953
TEST=Unit tests pass, new Unit tests added.
TEST=chrome://histograms shows metrics correctly.

Change-Id: Ic02e218f46568427df99a8a9df2011860aee84f3
Reviewed-on: https://gerrit.chromium.org/gerrit/48069
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Fix clang syntax checking.

This fixes serveral clang syntax checking. 1) unused functions.
2) confict of struct and class. 3) unused variables.

BUG=chromium:230663
TEST=clang syntax checking passed.
     trybot daisy-release passed
Change-Id: I8dbfb7dd5f21739831843bc3e7fa8ec7864824b9
Reviewed-on: https://gerrit.chromium.org/gerrit/47997
Reviewed-by: Han Shen <shenhan@chromium.org>
Commit-Queue: Yunlian Jiang <yunlian@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>

Measure and send update duration (and corresponding uptime) to UMA

This patch introduces two new metrics, Installer.UpdateDuration and
Installer.UpdateDurationUptime. The former is the timespan from when
the update was first discovered until it has been downloaded and
applied (including the time the device is suspended or powered
off). The latter is similar, but without taking into account time
spent in suspend or powered off.

For example, if the device is suspended (or powered off) for N seconds
while updating, the Installer.UpdateDuration metric will be N seconds
bigger than Installer.UpdateDurationUptime metric:

 Histogram: Installer.UpdateDuration recorded 1 samples, average = 313.0
 Histogram: Installer.UpdateDurationUptime recorded 1 samples, average = 251.0

Also remove the existing Installer.UpdateTime metric as this didn't
take process restarts into account and is now superseeded by the
Installer.UpdateDuration metric.

This is done by using the CLOCK_MONOTONIC_RAW clock (available in
Linux 2.6.28 and later) since this clock indeed does not advance when
the system is sleeping.

We use the PayloadState class to persist recorded data across
update_engine process restart (including device reboots).

Since clock_gettime(2) and CLOCK_MONOTONIC_RAW requires linking to the
librt library do this and also request the system header files to
expose the required symbols and defines, i.e. define _POSIX_C_SOURCE
>= 199309L.

Also remove _POSIX_C_SOURCE mangling from update_attempter.cc since
it's actually not needed there and generally it's better to make the
environment the same across all translation units (by putting whatever
is needed in e.g. CCFLAGS).

BUG=chromium:226763
TEST=unit tests, force update, examine chrome://histograms

Change-Id: I883668564b5fa78ff3e19156bd77496ff929ca58
Signed-off-by: David Zeuthen <zeuthen@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47928
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>

Remove the obsolete needsadmin attribute.

It seems that the needsadmin attribute hasn't been used for a long time, so
stop parsing it. We were parsing out the value, then ignoring it anyway.

BUG=chromium:199039
TEST=built, trybot mario-release

Change-Id: Ic0fbb8924af7c647fe1630cc60c260587431a0ff
Reviewed-on: https://gerrit.chromium.org/gerrit/47822
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Queue: Don Garrett <dgarrett@chromium.org>

Refactoring: Move prefs constants out to the constants.h/cc

Adding/removing the set of keys used by various parts of the Update Engine code
does not affect the implementation of the prefs module, hence separating them.

BUG=chromium:229090
TEST=Unit tests pass.

Change-Id: Id774b726a47b461e563e2e413527054e4da0c012
Reviewed-on: https://gerrit.chromium.org/gerrit/47593
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>

Fix the confict of declaration and definition between struct and class

This fixes the error when compiling with clang syntax checking
The error message was:
/update_engine/test_utils.h:188:1: error: 'ObjectFeederAction'
defined as a struct template here but previously declared as a
class template [-Werror,-Wmismatched-tags]

BUG=chromium:218781
TEST=USE="chrome_internal" CXXFLAGS="-clang -print-cmdline"
     CFLAGS="-clang -print-cmdline" emerge-x86-alex update_engine

Change-Id: Ieac9981c84c4e5779cbf876650f21a5d1b2acd72
Reviewed-on: https://gerrit.chromium.org/gerrit/47476
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
Commit-Queue: Yunlian Jiang <yunlian@chromium.org>

AU: Release bspatch memory as early as possible.

Release the memory as soon as the bspatch file is written out in order
to reduce overall peak memory usage.

BUG=chromium:220750
TEST=unit tests; trybots

Change-Id: I0d82976c207c6bb57287f6ea1a79e214db1f08c7
Reviewed-on: https://gerrit.chromium.org/gerrit/47232
Tested-by: Darin Petkov <petkov@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Commit-Queue: Darin Petkov <petkov@chromium.org>

Support changing from non-canary to canary channel in update engine.

Now that we have added support in lsb-release for both the board appid
and canary app id to be specified, we should use the appropriate appid
according to the channel from which we want to download the new payload.

This change in update engine will enable the change from non-canary to
canary channels. This feature when be lit up end to end when the UI for
this scenario is ready.

BUG=chromium:225866
TEST=Unit tests pass. Tested all channel changes on my ZGB.

Change-Id: Ia9c37c72f53f6c69436f0a96e35d2584d84653c8
Reviewed-on: https://gerrit.chromium.org/gerrit/47181
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Log the correct error when the rootfs hash/size mismatches on deltas.

BUG=None
TEST=Unittests

Change-Id: If2ca1eecaacfa23deedc08b52a4f8033e4d0359c
Reviewed-on: https://gerrit.chromium.org/gerrit/46906
Tested-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: Chris Masone <cmasone@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Queue: Chris Sosa <sosa@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>

Cancel the current download if user chooses a different channel.

In my earlier CL, to keep the implementation simple, we disallowed changing
a channel until the previous change completed in its entirety. Given that
the UI is not going to be updated for M27, such a restriction turned out
to be very confusing when playing around with channel changing. So, we
decided to implement a simple form of canceling the download if the
user selected a different channel while we're downloading the bits. This
implementation can easily be extended to support a general form of cancel
in the future, if required.

This CL also adds validation of libchromeos API calls when interpreting
the policy values. It also cleans up some bogus error messages that were
logged earlier when we abort a download.

BUG=chromium:222617
TEST=All scenarios pass on ZGB. Unit Tests pass.

Change-Id: I7cd691fe461d9ce47314299f6e2598944650ee33
Reviewed-on: https://gerrit.chromium.org/gerrit/46095
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

fix(chrome_browser_proxy_resolver): fix spelling errors

BUG=None
TEST=None

change dbug to dbus

Change-Id: I50c71c85dc48c3ef6defc8092003ab202c4783f3
Reviewed-on: https://gerrit.chromium.org/gerrit/46552
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Brandon Philips <brandon@ifup.co>
Tested-by: Brandon Philips <brandon@ifup.co>
Commit-Queue: Brandon Philips <brandon@ifup.co>

AU: improve/clarify signature padding

Reformatted and added comments that make it clear what exactly this
padding stands for.

BUG=None
TEST=Builds, unit tests

Change-Id: I7b0b57f6791c4706ede1fd957214236c7921f50e
Reviewed-on: https://gerrit.chromium.org/gerrit/45993
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>

AU: uprev the default BASE_VER value for local builds

We seem to be baking a default value in SConstruct, which became
outdated, hence this fix.

BUG=None
TEST=./build now works

Change-Id: I72de470de920582883f92f0fd8f4a195041456f3
Reviewed-on: https://gerrit.chromium.org/gerrit/45996
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>

Fix update_disabled flag to be set to false when there's no policy.

My previous check-in introduced an uninitialized variable which
may cause some random AU failures because of the update_disbled
flag being initialized to true based on the contents of the stack.

This CL fixes it by always setting it to false.

BUG=chromium:222161
TEST=Unit Tests Pass, work as expected on my ZGB.

Change-Id: I80fce1db566f6cea0ea80370c4a90dc538215316
Reviewed-on: https://gerrit.chromium.org/gerrit/45941
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Enhanced channel changing behavior

This CL adds a new DBUS API to UpdateEngine called SetTargetChannel to
change the current channel of the device with an option to indicate
whether to do eventually or immediately.

The API will be called with the option to do it immediately in a
subsequent CL in Chrome UI. For now the old API (set_track) has been
wired up to call the new API to produce the old behavior (i.e. change
eventually). The old API will be removed after Chrome UI code stops
using it.

It's the UI's responsibility to ask the user for confirmation for the
powerwash that may happen in some cases and call the API with the
appropriate value whether or not the powerwash should happen.

For now, we're restricting the changing of channels to only those
devices that are on canary-channel or running test builds. This
restriction will be lifted off once the UI work is ready to give
warning to the users about the powerwash that may happen when they move
to a more stable channel.

We also enforce ReleaseChannelDelegated and ReleaseChannel policies
correctly now as follows:

* If ReleaseChannelDelegated is false, SetTargetChannel will fail as we
need to honor (only) the ReleaseChannel value in this case.
* If ReleaseChannelDelegated is true, we'll allow the SetTargetChannel
call to specify. In this case, we'll ignore the value of ReleaseChannel,
if any.

BUG=chromium-os:39095
TEST=Tested on ZGB by going from canary to dev-channel with and without
powerwash.
TEST=Existing unit tests have been updated and they pass.
TEST=New unit tests have been added.

Change-Id: Ifbf806a06e1c30d2f318e94d73735d1812049abd
Reviewed-on: https://gerrit.chromium.org/gerrit/44619
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Rewrite comment as requested.

There was a poorly worded comment related to bsdiff blacklisting that caused
confusion. Rewording it to be clearer (I hope).

BUG=None
TEST=Built, visual inspection that it's a comment change only.

Change-Id: Ib69c3ab168ffbba79ee430e5baa0dc4eca1e90b2
Reviewed-on: https://gerrit.chromium.org/gerrit/45165
Reviewed-by: David Dorwin <ddorwin@chromium.org>
Commit-Queue: Don Garrett <dgarrett@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>

fix(udev_interface.h): remove return from voids

BUG=None
TEST=None

gcc is complaining about these returns, just remove them:

update_engine-0.0.1-r366: ../update_engine/udev_interface.h:190:27:
error: return-statement with a value, in function returning 'void'
[-fpermissive]

Change-Id: Iad34fa669e8cc5597f09058fdaa7c3bb3e3ec87b
Reviewed-on: https://gerrit.chromium.org/gerrit/44894
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: Brandon Philips <brandon@ifup.co>
Tested-by: Brandon Philips <brandon@ifup.co>

Update update engine to compile and use libchrome-180609.

Made the following fixes:
- base/eintr_wrapper.h -> base/posix/eintr_wrapper.h
- base/string_tokenizer.h -> base/strings/string_tokenizer.h
- Switched JSONReader->JsonToValue to use JSONReader->ReadToValue.

BUG=chromium-os:39847
TEST=unittests + run through image_to_live

Change-Id: Iffa0a3af4a065fac40460d8c1c2ed5c9b6e9ed07
Reviewed-on: https://gerrit.chromium.org/gerrit/44098
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: Chris Sosa <sosa@chromium.org>

AU: change 'userinitiated' into 'installsource'

- Renamed the flag so it is in line with the flag name and values used
  by Chrome to indicate different forms of an update. It will allow us
  to reuse existing Omaha dashboard facilities to monitor this flag.

- Also, per advise from Omaha, moved the said attribute to the <request>
  XML node.

BUG=chromium-os:26594
TEST=New flag name/values now appear

Change-Id: I46a158b3aef8a56813464d74fc6043ea5b1ec3c1
Reviewed-on: https://gerrit.chromium.org/gerrit/41951
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>

Make policy reloads explicit.

BUG=chromium-os:38541
TEST=unit tests pass
CQ-DEPEND=I20461078ca890c6ec2f81ad5383c06c4d75a64cd

Change-Id: I3f9ca593247816534d4f9f87e8a0c7db593b87b5
Reviewed-on: https://gerrit.chromium.org/gerrit/42540
Reviewed-by: Will Drewry <wad@chromium.org>
Commit-Queue: Julian Pastarmov <pastarmovj@chromium.org>
Tested-by: Julian Pastarmov <pastarmovj@chromium.org>

AU: recommend cgpt undo on update_engine_client -reset_status

While -reset_status will reset the update engine's internal state, as
well as remove the flag file that necessitates a reboot, it will not
undo the (potentially detrimental) effect of an update to a machine's
partition table. With this change, update_engine_client now prompts the
user to apply a one-liner shell command to reverse the impact of such
changes, ensuring that a subsequent reboot will load the current
kernel/rootfs (and not the updated ones).

Note that this command should work regardless of which physical device
is the boot device (e.g. /dev/sda, /dev/mmcblk0) and the partition
scheme used (rootfs is e.g. /dev/sda3, /dev/mmcblk0p3). It does,
however, assume that the number of the kernel partition is that of the
corresponding rootfs partition minus one.

BUG=None
TEST=Expected log message displayed

Change-Id: I4503c4377a9ddbfd597ac7e049fad72ba989a213
Reviewed-on: https://gerrit.chromium.org/gerrit/42022
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>

AU: improve progress logging during updates

We currently emit a log message for operations at fixed index increments
of 1000. This is fairly useful in keeping the number of log messages
small, but otherwise quite arbitrary and useless in giving an actual
sense of progress, throughput, etc for updates of varying number of
operations in them and subject to network latencies.  Further, this
progress report does not take into the account the download progress,
which appears to be the completion metric used toward the UI.

This CL proposes a simple mechanism for computing an "overall update
progress" and an adaptive method for emitting a progress log message in
reasonable intervals. The raw metrics currently used include (i) the
number of bytes downloaded out of the expected total; (ii) the number of
operations successfully applied out of the expected total.  These are
weighed into a single percentage counter based on a prefixed set of
weights.  Logging occurs based on either (i) completion of update
"chunks" of some predetermined number; or (ii) having enough time
elapsed since the last log message.  This guarantees that we'll see
enough progress messages at regular intervals, but not too many of them.

We're also similarly logging the relative position in a resumed update
right before we start applying from the point we left it.

Note that the max number of regular log intervals, as well as the
timeout to force a progress log, can be easily tweaked by changing
compile-time constants.  They are currently set to 10 (or every 10%) and
30 (for 30 seconds since the last progress log), respectively, which
appear to be a reasonable choices.

Here's an example from an actual update log:

[0118/145759:INFO:delta_performer.cc(451)] Starting to apply update payload operations
[0118/145821:INFO:delta_performer.cc(150)] Completed 100/1040 operations (9%), 38363576/319659860 bytes downloaded (12%), overall progress 10%
[0118/145835:INFO:delta_performer.cc(150)] Completed 213/1040 operations (20%), 63939000/319659860 bytes downloaded (20%), overall progress 20%
[0118/145857:INFO:delta_performer.cc(150)] Completed 298/1040 operations (28%), 102293944/319659860 bytes downloaded (32%), overall progress 30%
[0118/145912:INFO:delta_performer.cc(150)] Completed 421/1040 operations (40%), 127869368/319659860 bytes downloaded (40%), overall progress 40%
[0118/145935:INFO:delta_performer.cc(150)] Completed 507/1040 operations (48%), 166224312/319659860 bytes downloaded (52%), overall progress 50%

(update interrupted and resumed)

[0118/150058:INFO:delta_performer.cc(150)] Resuming after 582/1040 operations (55%), 195577374/319659860 bytes downloaded (61%), overall progress 57%
[0118/150058:INFO:delta_performer.cc(451)] Starting to apply update payload operations
...
[0118/150102:INFO:delta_performer.cc(150)] Completed 604/1040 operations (58%), 200934046/319659860 bytes downloaded (62%), overall progress 60%
[0118/150116:INFO:delta_performer.cc(150)] Completed 749/1040 operations (72%), 221543046/319659860 bytes downloaded (69%), overall progress 70%
[0118/150134:INFO:delta_performer.cc(150)] Completed 840/1040 operations (80%), 255736454/319659860 bytes downloaded (80%), overall progress 80%
[0118/150154:INFO:delta_performer.cc(150)] Completed 936/1040 operations (90%), 289225350/319659860 bytes downloaded (90%), overall progress 90%
[0118/150212:INFO:delta_performer.cc(150)] Completed 1040/1040 operations (100%), 319659860/319659860 bytes downloaded (100%), overall progress 100%

BUG=chromium-os:37910
TEST=Passes unit tests
TEST=Update works, progress logged as expected on x86-alex

Change-Id: I2ec5511fc20df05a264e59651528c65133209132
Reviewed-on: https://gerrit.chromium.org/gerrit/41301
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>

Change how update_engine_client handles DBus proxy failures.

Change GetProxy() to log failures with LOG(ERROR) and then
terminate, rather than use LOG(FATAL), as the latter unhelpfully
generates a core file.

BUG=chromium-os:37542
TEST=run update_engine_client with and without a working update_engine

Change-Id: Id84b56ff0b5ffa51cf4fda4cb7ad847f5bb617e5
Reviewed-on: https://gerrit.chromium.org/gerrit/41662
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: Richard Barnette <jrbarnette@chromium.org>

AU: move 'userinitiated' flag to the right place in an update check

The said flag, introduced in a recent change, should be an attribute of
the <updatecheck> node, now fixed. Also changed a couple of unit tests
to reflect this.

BUG=chromium-os:26594
TEST=Flag now appears in the right place

Change-Id: I4f024797da34376364d358631d1a606be8be639e
Reviewed-on: https://gerrit.chromium.org/gerrit/41628
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

AU: add missing include

Forgot to include gpio_handler.h in system_state.h.

BUG=None
TEST=Builds

Change-Id: I26d54487ad937deb24ea791fdd1fc332d0af021e
Reviewed-on: https://gerrit.chromium.org/gerrit/41224
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>

AU: coalesce interactive / user-initiated flags

The latter was introduced recently but turns out it just carries
a duplicate meaning to the former, so we're eliminating it. This also
makes the case of a simulated scheduled update check more accurate, as
all of the effects of a scheduled update are made.

BUG=None
TEST=Unit tests; interactive/scheduled update check behaves as expected.

Change-Id: I8971aefcfc15cb76733059860832507e88795883
Reviewed-on: https://gerrit.chromium.org/gerrit/41082
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

AU: add an interactive flag to Omaha requests

Such a flag can be used to distinguish between user-initiated
(interactive) checks and those that are due to background scheduling. In
the former case, we may want to suppress the probabilistic throttling
that's commonly used with latest releases. This CL piggybacks the new
functionality on top of an existing dataflow used for distinguishing
between interactive / scheduled checks, only it pushes it further so it
is evident in the Omaha request as well.

Comes with a unit test for ensuring that the Omaha flag is set as
expected.

BUG=chromium-os:26594
TEST=Dbus initiated checks correctly tainted

Change-Id: Ia2b3ff5ce3a866c64e453557028b8cbd92c1a258
Reviewed-on: https://gerrit.chromium.org/gerrit/41081
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Use IsDeltaPayload instead of IsDelta.

Trying to resurrect the IsDelta in an earlier CL to avoid pollution of
Omaha rules turned out to be a wrong choice because R14 and R15 code
strictly expects IsDelta to be true even for full payloads. So
preserving IsDelta's semantics as-is and introducing IsDeltaPayload to
really convey the intended semantics: True if it's delta payload, False
if it's full payload.

BUG=chromium-os:37801
TEST=Updated unit tests. Works fine on ZGB with Omaha devserver.

Change-Id: I899b56be4dcbdcf1981f72d356d40a1e99fdf725
Reviewed-on: https://gerrit.chromium.org/gerrit/41181
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Segregate UMA metrics for production scenarios from test scenarios.

Currently we separate the UMA metrics only by one category: whether the
device is in dev mode or not. In addition, we need to exclude the noise
from these two categories:
1. Most of our testing on MP-signed images which are performed
with autest.
2. All our hwlab tests run in non-dev mode but they use dev-signed images
with dev-firmware keys.

So this CL defines additional bit fields to represent these states and
if any of these three flags are set, the UMA metric is sent to a
DevModeErrorCodes bucket. Thus the NormalErrorCodes bucket will have only
the production errors and thus we can monitor more effectively.

BUG=chromium-os:37613
TEST=Updated unit tests, ran on ZGB for all scenarios.
Change-Id: Id9cce33f09d1cc50cb15e67c731f7548940cbc24
Reviewed-on: https://gerrit.chromium.org/gerrit/41103
Reviewed-by: Chris Sosa <sosa@chromium.org>
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

AU: fix bug in GPIO handler that caused failed discovery to be ignored

This solves two issues:

* The GPIO handler will attempt to use GPIO devices even when discovery
  via udev has failed. Not any more.

* GPIO discovery would return success even when it failed on a previous
  attempt. Now it'll reflect the actual result of the discovery attempt.

* Reporting of file descriptor open errors is obscured due to
  intermittent operations that reset errno, now fixed.

* Added test case to ensure that repeat GPIO discovery is not attempted,
  and that test mode check will automatically fail if a previous
  initialization/discovery had failed.

BUG=None
TEST=Passes unit tests
TEST=All symptoms gone on real update attempt w/ x86-alex

Change-Id: I01a7b1e316dbb5b94487a5aad1560d994feae9ff
Reviewed-on: https://gerrit.chromium.org/gerrit/40946
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

AU: replace sleep/usleep with g_usleep

Also deploying 'using base::TimeDelta' where it is useful.

BUG=chromium-os:33541
TEST=Passes unit tests; update runs on x86-alex

Change-Id: I9478d46d0796b13789878393e3a4086564124d33
Reviewed-on: https://gerrit.chromium.org/gerrit/40904
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

AU: disable GPIOs in production; some structural changes

Since we are not making use of the GPIO funcionality in UE for the
moment, it's been advised that it should be disabled. This CL does just
that, plus a few small changes:

* Adds a "no-op" GPIO implementation, which simply returns a constant
  value every time it's being asked whether test-mode was signaled (in
  this case, we set it to return false).

* The GPIO handler is embedded in SystemState. This makes sense from
  both the conceptual and usability standpoint.  The SystemState object
  can be parametrized to initialize either a real or a no-op GPIO
  handler.

BUG=chromium-os:32263
TEST=passes unit tests; does not engage GPIO protocol on x86-alex

Change-Id: I8121647baa7611041073dcf305beddab57c0e49c
Reviewed-on: https://gerrit.chromium.org/gerrit/40633
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Implement exponential backoff for throttling repeated AU downloads.

Today we retry the same payload over and over again every hour. Ideally,
we shouldn't require ever to re-download the same payload again. But
from experience we find that post-install or firmware updates may succeed
on a second attempt. So until we have code that can do such selective
retries of those steps, we currently re-download and re-apply the whole
payload. So instead of retrying over and over again, we backoff the
successive payload download attempts at 1 day, 2 days, 4 days, etc. with
an upper limit of 16 days.

Another subtle reason for which we depend on the payload retry mechanism
today is if we've failed downloading the payload via all the URLs that are
specified in the rule, we don't want to keep re-attempting the download.
This case is different from the case discussed above, because in this case
we haven't even downloaded a payload once completely. In this case also,
there's a need for throttling the amount of bytes we end up downloading
repeatedly for a particular operation that may fail. This is done by
treating the exhaustion of all URLs as equivalent to having downloaded
a full payload and subjecting it to the same backoff behavior.

We waive backoffs for dev/test images so as not to cause any delay in
our testing or development.

BUG=chromium-os:36806
TEST=Added new unit tests. Tested all scenarios on my ZGB.
Change-Id: I6bd0d3f296a3c0da0a8026fb71b24785d825e39c
Reviewed-on: https://gerrit.chromium.org/gerrit/40220
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Classify errors and advance URL index according to the error code.

In CL https://gerrit.chromium.org/gerrit/39638, we always incremented
the URL index irrespective of the error code. That would cause the first
URL to be given up too quickly in favor of the second one even for
transient errors such as when user closes a lid and reopens after some
time.

The right behavior in this case is to just count those failures towards
the URL and only after repeated failures with no progress should we
advance the URL index.

This CL implements this logic and completes the multiple URL-related
work items outlined in the design doc.

BUG=chromium-os:37206
TEST=Tested all uses cases on my ZGB. Added and updated unit tests.

Change-Id: Ida0cfbfeb9bfab732144049d1b27e3b8958bc252
Reviewed-on: https://gerrit.chromium.org/gerrit/39885
Commit-Queue: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Fix update_engine_unittests bug - properly setup singleton class member.

This fix sets up "CertificateChecker::system_state_" properly to avoid
using an earlier invalidated object instance.

Please note, the seg fault caused by above problems do not occur in
current build/testing circle, they are exposed when I am doing testing
on upgrading to binutils 2.22.

TEST=all tests passed
BUG=None

Change-Id: Ie258c3a518508a233bcc93de5462584e3ec0dd0e
Reviewed-on: https://gerrit.chromium.org/gerrit/39865
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Ready: Han Shen <shenhan@google.com>
Tested-by: Han Shen <shenhan@google.com>

Support for processing multiple URLs in update_engine.

Main changes:
1. Added a new PayloadState class which encapsulates all the persisted
state we use for multiple URLs, back-off (TBD), etc.
2. Added support for handling multiple URLs stored in the OmahaResponse in
OmahaRequestAction and OmahaResponseHandlerAction code.
3. Added support for picking the right URL in OmahaResponseHandlerAction
and putting it in the install_plan. This way, the rest of the code that
uses the install_plan is oblivious to the presence of multiple URLs :-)
4. Added support for advancing to next URL when an update fails. The full
error classification is a new work item (chromium-os:37206). Right now,
it's a basic round-robin on every error.
5. Updated the conditions for determining when hash checks are mandatory.
Previously since there was only one URL, if it was HTTPS, the checks were
waived. Now, even if there's one HTTP URL, we make hash checks mandatory
even if other HTTPS URLs are present.

6. Added new unit tests for PayloadState and the new logic added to other
places.

Noisy changes:
1. Instead of passing PrefsInterface to OmahaRequestAction and
OmahaResponseHandlerAction, we're now passing SystemState which will now
contain PrefsInterface and the newly added PayloadState object that these
actions need to do their work.
2. Renamed a bunch of setters/getters to set_x() and x() instead of SetX()
and GetX() methods - this was pending from Gilad's old CR. As I'm
adding new methods in the correct style, I went ahead and fixed it to
avoid the confusing styles.
3. Updated all existing unit tests to reflect these changes.

BUG=chromium-os:36807
TEST=All Single/Multiple URL scenarios work fine on my ZGB as expected.
TEST=Old and new unit tests run fine.

Change-Id: Id31f9ccb220471f3ec3a475f624dc03c16119144
Reviewed-on: https://gerrit.chromium.org/gerrit/39638
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Make hash checks mandatory for HTTP downloads.

Currently we've made all the checks for metadata size, metadata signature
and operation hashes as optional. While they are still optional if we use
HTTPS for downloading the payload, we want to make them mandatory in case
of HTTP, so as to support HTTP downloads.

In this CL, we make these checks mandatory if the Omaha response has a
HTTP URL. This will not affect any scenarios of our test team because they
always use HTTPS URLs for payload URLs. But this would break the dev tools
and our hardware test lab scenarios because they use HTTP URLs and do not
generate the required manifest signature yet. So we waive this requirement
for dev/test images even though they use HTTP.

This CL will not have any effect until we decide to add a HTTP rule in
Omaha, which serves as a safety knob till we are confident with our
testing.

BUG=chromium-os:36808
TEST=Existing unit tests pass. Added new unit tests for most new code.
TEST=Ran manual tests on ZGB for every type of hash failure for HTTP.
TEST=Tested image_to_live to make sure hash checks are waived as expected.

Change-Id: I8c4408e3052635ccf4bee0c848781733c1f8e984
Reviewed-on: https://gerrit.chromium.org/gerrit/39293
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Modify priority tweaking to use CGroups.

This modifies the behavior of setpriority and getpriority
to use CGroups rather than niceness levels.

I've removed the unittest comparing priorities as its not
really valid any more as we are just writing numbers to files.

I've also refactored references to priority to reference cpu
shares etc.

BUG=chromium-os:36229
TEST=Unittest + doing end to end test in bgnd
CQ-DEPEND=I6a0e56073e7281268e0550919c9ec9202b18db26

Change-Id: I48c8270c2065f1e0677e5e53df3557131577b97c
Reviewed-on: https://gerrit.chromium.org/gerrit/39147
Reviewed-by: Chris Sosa <sosa@chromium.org>
Tested-by: Chris Sosa <sosa@chromium.org>
Commit-Ready: Chris Sosa <sosa@chromium.org>

Set libcurl options based on protocol (HTTP or HTTPS)

Today update_engine only supports HTTPS protocol. So we lock down libcurl
to use only HTTPS, set options to validate the peer certificate,
set other SSL options, etc. Moving forward, we want to support payload
downloads via HTTP also. So, this CL sets the old options only if the URL
we're using is HTTPS. If it is HTTP, we just need to lock down the protocol
to HTTP.

BUG=chromium-os:36809
TEST=Existing unit tests pass.
TEST=Manually tested downloading using HTTP and HTTPS URLs on my ZGB.

Change-Id: I5948beb3bb84914dd3a3801f516c2eb15c857c6b
Reviewed-on: https://gerrit.chromium.org/gerrit/39142
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Pick last instead of first URL in v3 clients for now.

We have a design underway for trying out all the URLs in the Omaha rules.
But update_engine has already been modified to be v3 and pick the first
URL. What this means is that any bits released until the full design gets
implemented, in future, when we actually populate multiple URLs such as
HTTP and HTTPs, will pick HTTP and fail because it doesn't have the full
support to process HTTP URLs.

So we need to change that logic to always pick the last one. This is
based on the assumption that the last one will be more stable (e.g. HTTPS).

BUG=chromium-os:36724
TEST=Tested on ZGB with devserver by supplying multiple URLs.

Change-Id: I85291dae56c9be83eb83955d6e123cdb8e33f28a
Reviewed-on: https://gerrit.chromium.org/gerrit/38827
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Upgrade update_engine from Omaha v2 to v3 protocol.

Omaha had released the v3 protocol long back, but update_engine kept
using the v2 protocol as there was no immediate need to move. But now
that we need to support HTTP-based downloads, we need to supply multiple
URLs for each rule, one for HTTP, one for HTTPS fallback. Even for
HTTPs, it is also useful for scenarios such as specifying a Google
storage URL as the primary download point and keeping Lorry as a backup
URL. Multiple URL support is available only on Omaha v3 protocol.

So, this CL is to first upgrade of the client protocol from v2 to v3. It
does not add any new functionality and still supports only one URL. The
subsequent checkins will take advantage of the multiple URL support.

This CL also includes a sample xml file which illustrates how the new
response from the Omaha v3 server would look like, which should greatly
help in understand the changes.

As part of this change, I've also consolidated a few error codes which
had practically zero occurrence into one error code and reused those
error codes for the recently added errors (which haven't been shipped
anywhere yet). Since we're now publishing all the error codes in UMA, we
need to be conservative in defining distinct error codes in order to
reduce the memory usage of Chrome for UMA stats.

BUG=chromium-os:6594
TEST=Tested on ZGB with Omaha v3 server. Updated unit tests and they pass.
Change-Id: I187aa0500e39623684130ba9e3d1d948c0e60627
Reviewed-on: https://gerrit.chromium.org/gerrit/36758
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Ready: Chris Sosa <sosa@chromium.org>

Addressing review comments that came after merging previous CL.

Minor updates to naming conventions and comments.

BUG=chromium-os:34299
TEST=Retested on ZGB. Re-ran unit tests.
Change-Id: I7db665d4f69969a972ee801f0e0cea9cf33437a6
Reviewed-on: https://gerrit.chromium.org/gerrit/36531
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Send UMA Stats for update engine error codes.

With the latest addition of new optional security checks for the update
manifest and operations checked in, we now want to track the number of
failures, if any, over time to help us decide when it is safe to make
the new security checks mandatory. This CL adds the UMA metric for
reporting the new (as well as the old) error codes to UMA for the first
time.

There's no change to the existing errors that are being sent to Omaha.
Due to UMA restrictions, some Omaha codes will be aggregated when being
sent to UMA.

BUG=chromium-os:34299
TEST=Unit tests pass, tested on real ZGB, all stats show up in
     chrome://histograms correctly for both dev mode and normal mode.
Change-Id: I3ce4645636311cedbb33f601e775951966c0a545
Reviewed-on: https://gerrit.chromium.org/gerrit/36408
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Base64 decoding should handle lack of newlines in encoded string

If there are no new lines in the input string, it seems we have to set
the BIO_FLAGS_BASE64_NO_NL flag. Without this flag, BIO_read just
returns a decode string full of zeroes. So in this CL, we canonicalize
the input by stripping of all the newlines and then set this flag so
that decoding work for all cases.

Note: Currently the unit tests use a different library than what paygen
uses and happens to encode a string with newline (which is why the
previous code worked fine and we only found out this issue when paygen
code changes were done). Hence we canonicalize the input.

Work Item 34173 tracks adding a no-new-line variation to the unit tests
so that it tests both case.

BUG=chromium-os:35423
TEST=Unit Tests pass, tested end to end on ZGB.

Change-Id: Ieccb94c91feb5147ea19664e5a381e24cd5ff646
Reviewed-on: https://gerrit.chromium.org/gerrit/35857
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Keep main loop running until FilesystemCopierAction under test has stopped.

This CL fixes FilesystemCopierActionTest.RunAsRootTerminateEarlyTest
such that it does not prematurely terminate the glib main loop before
FilesystemCopierAction::AsyncReadReadyCallback is invoked upon the
cancellation of the action.

BUG=chromium-os:34448
TEST=Run unit tests repeatedly with glib 2.30 and 2.32.

Change-Id: I26c15811ee41d16df731c4acbe24ed48c8739dde
Reviewed-on: https://gerrit.chromium.org/gerrit/34976
Commit-Ready: Ben Chan <benchan@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>

Make unit tests less timing sensitive when unmounting busy loop devices.

This CL modifies utils::UnmountFilesystem() to retry when umount()
fails to unmount a busy loop device and replaces several unit tests to
use the modified utils::UnmountFilesystem() instead of calling
System("umount").

BUG=chromium-os:35112
TEST=Run unit tests repeatedly.

Change-Id: I42978f02b4797c68acbec6c351ea2663b9ec7b59
Reviewed-on: https://gerrit.chromium.org/gerrit/34862
Reviewed-by: Ben Chan <benchan@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>
Commit-Ready: Ben Chan <benchan@chromium.org>

Support needed for generating metadata signature in paygen

The metadata is the first portion of a payload that contains the following:
1. magic string ("CrOS")
2. version number
3. length of the manifest protobuf
4. manifest protobuf itself
<payload blobs begin here>
<payload signature as the last blob>

Currently we have a manifest signature which protects only #4 above. In
this CL we're extending the scope of manifest signature to include the rest
of the metadata (1-4). The reason we need to do this is to protect the
version value in HTTP as we're going to use it in future to have the
flexibility to change the protobuf format of the manifest.

Besides this change, this CL also contains:

1. Renaming of manifest_size and manifest_signature to metadata_size and
metadata_signature respectively to reflect the above change and keep
consistent terminology throughout. Also it renames protobuf_offset and
protobuf_length to manifest_offset and manifest_size to increase the
contextual semantics of the protobuf.

2. Addition of a new command-line option --out_metadata_hash_file in
delta_generator so that au_generate can use it in a subsequent CL to get
the SHA256 hash of the payload metadata in order to get it signed with
the signer.

3. Reusing LoadPayload in unit tests to get rid of some hardcoding. Also
updated delta_performer to localize such hardcoded constants within that
class and not have callers worry about those values.

BUG=chromium-os:33603
TEST=Tested on ZGB. Reran existing unit tests.
Change-Id: Iace5aebe8f7d054a0fa3a224a588ef52d85f510b
Reviewed-on: https://gerrit.chromium.org/gerrit/33726
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Generate and validate per-operation hashes

As part of securing the HTTP-based updates, we want to add a SHA256 hash
of the data blob for each operation so that they can't be tampered with
by a man in the middle. This CL adds support for generating and
including such hashes for each operation in the payload as well as
validating them in update_engine, if present.

BUG=chromium-os:34298
TEST=Tested on ZGB to make sure existing functionality works fine.
     Existing unit tests cover all the new code paths.
Change-Id: Ie42ed1930a66ceaf183f36ce3af0dea719e44237
Reviewed-on: https://gerrit.chromium.org/gerrit/33389
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Update manifest protobuf to include optional hash for operation blobs.

In order to support downloads over http for a number of reasons, we need
to secure http downloads. Among other things, we reduce the attack surface
by adding an extra hash for each operation that uses a blob. This CL
adds this extra field in the update_engine metadata protobuf. Checking this
first so that subsequent CLs that populate/consume this field in
delta diff generator and update_engine can be developed independently.

BUG=chromium-os:33602
TEST=Tested on ZGB to make sure existing functionality works fine.

Change-Id: I2aba79242aa515f1f288c93e9e778f4eb51ba962
Reviewed-on: https://gerrit.chromium.org/gerrit/33264
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>

Verify AU payload manifest signature if present.

In order to support downloads over http for a number of reasons, we need
to secure http downloads. The first step in this process is to
verify the signature of the manifest itself before parsing. This can be
done even for https-based downloads in order to provide defense-in-depth
against a SSL attack. This CL adds the required verification logic in
update_engine, if such a manifest signature is present in the Omaha
response.

Until the delta generator is modified in a subsequent check-in to update
the manifest and payload with the required signature, none of this new
code will have any effect.

The delta generator change to populate non-zero values for these new
fields will follow in subsequent CLs.

BUG=chromium-os:33602
TEST=Tested on ZGB to make sure existing functionality works fine.
     Added new unit tests.
Change-Id: I2d8b09c23faf87049893b1dee97a34e1f300aded
Reviewed-on: https://gerrit.chromium.org/gerrit/32844
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

run_unittests returns a proper exit status.

It'll now return 0, 1 or 2, corresponding to the number of test
invocations (either user or root privileged) that failed.

BUG=None
TEST=Script runs and returns correct status.

Change-Id: I0d5bd8436b1a9972337f34073321239d94565748
Reviewed-on: https://gerrit.chromium.org/gerrit/31006
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Support in update_engine for script for UI jank investigation.

We need to update image_to_live.sh to run in a loop to help investigate
the kernel behavior during AU. Since update_engine doesn't allow a
new update to be applied unless the device is rebooted after the previous
update, this CL adds an option to reset the state for testing purposes.

This CL does not cause any change in product code, since
update_engine_client will never be invoked with this option in product.

BUG=chromium-os:27954
TEST=Tested on ZGB.
Change-Id: I561e58893818a1b4990fdc131cd3bb64e473155e
Reviewed-on: https://gerrit.chromium.org/gerrit/29907
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Make sure waiting period in memory and persisted file are always in sync.

Sometimes the waiting period is 0 and there's no wall-clock-wait-period
prefs file created even though scattering is enabled. It happens because
the existing code doesn't maintain the invariants properly. So when a
user-initiated update check happens, the wall-clock-wait-period prefs
file is deleted but the in-memory variable
omaha_request_params_.waiting_period is not being updated.

This CL fixes these invariants by ensuring all the scattering artifacts
are removed completely when scattering is disabled and they're properly
recomputed when scattering is enabled.

BUG=chromium-os:32924
TEST=Updated unit tests, tested on ZGB.
Change-Id: Iabd2fd744f8c1a5099c00cf4d1f952757ec3e634
Reviewed-on: https://gerrit.chromium.org/gerrit/28348
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Minor changes to FilesystemCopierAction.RunAsRootSimpleTest.

- Fail the test if loop devices cannot be bound.

- More detailed logging.

BUG=chromium-os:31082
TEST=Builds and runs unit tests

Change-Id: Ic8adfe08a86a91e0d45275ec8ccc31af1b481737
Reviewed-on: https://gerrit.chromium.org/gerrit/28427
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Use a local UpdateFirstSeenAt timestamp instead of UpdatePublishedOn

The existing implementation that used the UpdatePublishedOn doesn't work
well with other AU enterprise policies such as stop AU, target version,
etc. This change will help all those scenarios to work and will make
the co-existence of policies more intuitive for the enterprise admin.

Basically, these scenarios bring out a flaw in the assumption I had
made earlier. i.e. we had assumed that if an update was pushed 5 months
ago, we never have to scatter that because most machines would have
been picked up the update by then. With the other AU policies like
stop AU or version pinning, this assumption is not true and scattering
is still relevant in these cases.

This new UpdateFirstSeenAt timestamp is the first time a Chrome device
hears of an update from Omaha that's eligble to be applied to the device
based on all policies except scattering. It'll use this timestamp instead
of the UpdatePublishedOn from the rule (which is no longer needed) and
everything else remains the same.  This UpdateFirstSeenAt value will
also be persisted so that the waiting period can be satisfied over reboots
when an update is not ready to be applied yet.

This timestamp will be cleared (only) after an update has been successfully
applied and the device is waiting to be rebooted.

Also contains a minor fix for avoiding the crash mentioned in 32797.

BUG=chromium-os:32280
TEST=Added new unit tests, tested on ZGB.
Change-Id: I1d7845a11f7eb7fc0a019018c8c4b9a3c68ee2cd
Reviewed-on: https://gerrit.chromium.org/gerrit/28100
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Fixes to utility / unit test related code.

* Eliminated bugs related to reading content from pipes/files, including
  general cleanup/refactoring of these code pieces and API.

* Eliminated bugs related binding/unbinding of loopback devices, which
  are used in unit testing.

BUG=chromium-os:31082
TEST=Builds and runs unit tests

CQ-DEPEND=Ib7b3552e98ca40b6141688e2dea5a1407db12b2a

Change-Id: Ifaab8697602a35ce7d7fb9384fdcb1ca64b72515
Reviewed-on: https://gerrit.chromium.org/gerrit/27911
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>

Modify a FilesystemCopierAction unit test.

* Reverse previous changes, which proved impotent in solving an
  intermittent test failure.

* Disabled the failing test.

BUG=chromium-os:31082
TEST=Builds and runs unit tests

Change-Id: Ib7b3552e98ca40b6141688e2dea5a1407db12b2a
Reviewed-on: https://gerrit.chromium.org/gerrit/27910
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Enable test mode updates.

* Uses the GPIO module to deduce whether a current update session needs
  to be treated as a controlled test, which allows a few relaxations.

* LibcurlHttpFetcher is extended to relax some of its security lock down
  provisions.

* Fix: a test mode flag remains persistent throughout an update attempt,
  so that it can be delegated to the various HttpFetcher instances used
  in the same attempt.

BUG=chromium-os:25397
TEST=Builds and unittests; automated test script works w/ servo
connected Alex

Change-Id: I8a29d1a21a0632912c10f01f69a26d9c659472fd
Reviewed-on: https://gerrit.chromium.org/gerrit/25128
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>

Diagnose/eliminate FilesystemCopierAction unit test failure.

* Added a retry count for failed write operations: for the particular
  failure at hand (an EIO return value on the last write call), we would
  attempt to "rewrite" the buffer up to a given number of times. This
  will tell us whether the error we're getting is transient or
  persistent. This mechanism will try to reposition the output stream to
  where it last succeeded, and re-mark buffer as full. The retry count
  is zero for all instances of FilesystemCopierAction with the exception
  of the instance used in RunAsRootSimpleTest (where it's set to 3).

  Note, however, that we will keep failing to operation to ensure that
  the unit tests are failing (and logs can be inspected). If this proves
  to be a transient error that can be worked around via retry, we'll
  probably leave this mechanism in place (but will stop failing the
  action).

* Added a debug message that prints the number of bytes we're trying to
  write when we attempt to write the residual (i.e. last piece of) data.
  This is just to be sure that we're passing the correct number.

* Removed the random selection of data to be copied during
  RunAsRootSimpleTest. It is obvious by now that only the sizes that are
  not divisible by the (unknown but likely a reasonably large exponent
  of two) fragment size are failing.

BUG=chromium-os:31082
TEST=Builds and runs unit tests

Change-Id: I3367eee638333686ab24997297d868cee416ff96
Reviewed-on: https://gerrit.chromium.org/gerrit/27094
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>

Fixed incorrect test cleanup that causes update_engine unit tests to hang

The PythonHttpServer class has to be cleaned up always. This was not
happening properly in one test (ServerDiesTest). This was causing the
succeeding test (which always happened to be SimpleRedirectTest) to use the
wrong server sometimes or hang forever.

Adding a bunch of instrumentation in unit test code helped to figure out
what's going, so leaving them in.

BUG=chromium-os:32096
TEST=update engine unit tests run fine.
Change-Id: Ide9a31eb411c8687ca39d78d8ebff97fe6305dbe
Reviewed-on: https://gerrit.chromium.org/gerrit/27325
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Instrument pwrite() failure.

This will shed more light on the circumstances in which
DeltaPerformerTest.RunAsRootSmallImageTest is failing.

BUG=chromium-os:31077
TEST=Builds and passes unit tests

Change-Id: I9b97191b62ef6cf3b39bdb68fa40d758b0632283
Reviewed-on: https://gerrit.chromium.org/gerrit/27185
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Support in update_engine for the crosh autest "-scheduled" option.

This is needed to enable manual testing of scattering feature on
MP-signed images.

BUG=chromium-os:32289
TEST=update_engine_client works as expected on zgb when passing
     autest and autest-scatter to omaha_url.
Change-Id: Ib3d3e70f2e87632b6a61c7e5cd45791210c12c99
Reviewed-on: https://gerrit.chromium.org/gerrit/27005
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>

Reflect return status of each invocation of a set of tests.

BUG=None
TEST=Unit tests invoked and status reported properly.

Change-Id: I55dfa306ffea607bd56ed6e461bc8c3f4df30863
Reviewed-on: https://gerrit.chromium.org/gerrit/26725
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Fixed gcc-4.7 building problem for update_engine (again).

TEST=Built using gcc-4.7 for lumpy.
BUG=None

Change-Id: Ic5dc527044d75549d7a125c64990bbee4d2dfa21
Reviewed-on: https://gerrit.chromium.org/gerrit/26138
Reviewed-by: Yunlian Jiang <yunlian@chromium.org>
Commit-Ready: Han Shen <shenhan@chromium.org>
Tested-by: Han Shen <shenhan@chromium.org>

Bidirectional test mode signaling over GPIO

* Implements a bidirectional synchronous handshake protocol over
  dut_flaga/b GPIOs. This protocol is designed to return true (test
  mode) only if the DUT is connected to a servo board which implements
  the remote end.

* Includes unit tests for the test mode signaling routine, complete with
  mock/fake implementation of the remote end.

Note that we still do not deploy GpioHandler in actual update
processing, which will be done later.

BUG=chromium-os:25397,chromium-os:27109,chromium-os:27672
TEST=Builds and passes unit tests (including new ones)

Change-Id: I265407ed735c3e1354e10782ac30566b16caeb20
Reviewed-on: https://gerrit.chromium.org/gerrit/23330
Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Gilad Arnold <garnold@chromium.org>

UpdateEngine-side changes to allow updates over 3G based on device policy.

Some enterprise chromebooks have only 3G and hence they need the ability
to update over 3G if the enterprise policy allows that. This CL adds
the support in update_engine to enable that.

BUG=chromium-os:31099
TEST=Tested E2E on 3G, added unit tests and did regression testing.
CQ-DEPEND=I1a55a392f3dc0f12d917eb45dcf0456b57735514
Change-Id: I121bda35e54fa6c35e002a76db198d13b72b650e
Reviewed-on: https://gerrit.chromium.org/gerrit/25470
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Install dev-util/lcov again.

Since the dependency problem was resolved, we can now install it and use
it for generating coverage reports.

BUG=None
TEST=Builds dev-util/lcov

Change-Id: I02cc1aa8cedea3da1b985732f6fbb2d2ba58cf89
Reviewed-on: https://gerrit.chromium.org/gerrit/25544
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Add -O1 to local build script by default.

This is the ordinary optimization level we use when locally building,
testing and doing coverage analysis on update_engine, so we might as
well etch it into the build script. It's a useful compromise between the
production/ebuild level (-O2 and other flags) and something that's still
debugable with (say) gdb.  It should eliminate some of the discrepancies
between the two builds, e.g. by making gcc optimize away const static
members declared and assigned in header files...

BUG=None
TEST=Builds project successfully

Change-Id: I0fa4a3fdc3fba5a556143061cbc56006676f754d
Reviewed-on: https://gerrit.chromium.org/gerrit/25389
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Fix update_engine scons building.

To build update_engine without an emerge, you need to run setup_dev_packages
to get the needed packages into the chroot, and then "scons" to do the
actual build.

However, setup_dev_packages has a broken dependancy. That dependancy is needed
to generate the test coverage reports, but not otherwise. Also, the SConstruct
file listed a "BASE_VER" for libchrome dependancies that was outdated and
overridden in the ebuild file.

This change removes the broken package depedancy, and updates the BASE_VER
so that it's relatively easy to build the update engine directly without doing
an emerge. That breaks the script to measure how much unittest coverage we
have, but that script is already broken.

Also, Gilad was right about static int's in one of Jay's previous CLs (and I
was wrong). How he was declaring some constants is causing problems for
commanline compiles, but doesn't for ebuild builds. So, this CL fixes that.

BUG=None
TEST=scons compelted.

Change-Id: I134f83528d8ad6fe3e504d98efb3d1030bfa3865
Reviewed-on: https://gerrit.chromium.org/gerrit/25252
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Don Garrett <dgarrett@chromium.org>

Fix FilesystemCopierAction unit tests.

This will add an explicit failure if either the read source/target
content fails to compare against the original. This way we can be sure
whichever has caused a failure when one is exhibited.

BUG=chromium-os:29841
TEST=Builds and passes unit tests

Change-Id: I685ddf9a383c0bddfea22369a128c7d8c56b0295
Reviewed-on: https://gerrit.chromium.org/gerrit/25127
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Gilad Arnold <garnold@chromium.org>
Tested-by: Gilad Arnold <garnold@chromium.org>

Don't scatter during OOBE or user-initiated update checks.

We need to add logic to disable scattering of downloads if we are in OOBE
or if we're doing a manual update check.

Scheduled checks are already disabled during OOBE, but this extra check
will ensure that any scattering policy (there's a pending work item to get
policy during OOBE) during OOBE will have no effect on the update.

Similarly manual (i.e user-initiated) update checks through
update_engine_client or through Chrome UI should not honor scattering.
That way, this can serve as a simple user-friendly workaround in case
there's any bug in scattering logic that bricks the system by any chance.

BUG=chromeos-31563: Don't scatter during OOBE or manual update checks.
TEST=Updated unit tests. Tested all code paths manually on ZGB and Kaen.
Change-Id: Ib631e560c1f620ca53db79ee59dc66efb27ea83c
Reviewed-on: https://gerrit.chromium.org/gerrit/24564
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Add resiliency in UE against interrupted HTTP downloads.

Currently when there's an interruption in the HTTP transfer, update_engine
attempts to resume the transfer only 3 times. After that it gives up.
For reasons yet to be investigated (31019), this happens quite consistently
on ARM and hence we need to fix update_engine to be more resilient in such
cases.

The fix is to increase the retry count to 20 for post-OOBE case. We'll
still maintain the original limit of 3 retries for OOBE case so as to not
stall OOBE forever.

BUG=chromeos-31511:Add resiliency in UE against interrupted HTTP downloads
TEST=Existing unit tests hit all new code paths and pass. Manually tested
     on ZGB and Kaen.
Change-Id: I4e47761dc9b859701023b749c902ec2b1c649b6f
Reviewed-on: https://gerrit.chromium.org/gerrit/24416
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>

Enable auto-update over WiMAX connections.

BUG=chrome-os-partner:9585
TEST=Build and run unit tests.

Change-Id: I66273c4559bb121cb823793ff309a9dc40ee7184
Reviewed-on: https://gerrit.chromium.org/gerrit/24400
Reviewed-by: Darin Petkov <petkov@chromium.org>
Tested-by: Ben Chan <benchan@chromium.org>
Commit-Ready: Ben Chan <benchan@chromium.org>

Scatter downloads to reduce bandwidth spikes.

Support in update_engine to honor the enterprise policy to scatter the
downloading of ChromeOS automatic updates so that we reduce bandwidth
spikes caused due to simultaneous downloads of updates by a large number
of enterprise devices.

This has no effect on consumer devices.

BUG=chromeos-29615: Implement scattering of downloads in UpdateEngine
TEST=Manually tested all scenarios, Unit tests added for all new code.
CQ-DEPEND=I1f56b5516970d5988eebb2cf8f93f6905823801d
Change-Id: I4a8f4974467a064d723ab13cbd78b1ca3ceff420
Reviewed-on: https://gerrit.chromium.org/gerrit/21574
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>