| c1c17b4ed6a3896b6343e737fd89682fa0c8436b |
|
23-Nov-2015 |
Alex Deymo <deymo@google.com> |
Report Enum metrics from CertificateChecker.
The certificate checker was reporting a "user action" whenever an
update check HTTPS connection or HTTPS payload download had an invalid
HTTPS certificate or a valid one that was changed since the last
connection to the same server.
This patch sends an Enum metric for every HTTPS connection to check for
and update or download the payload with one of the three options: an
invalid certificate, a valid one already seen or a valid but different
certificate.
This patch also moves these metrics to the metrics.{h,cc} module, where
all the other metrics are reported, using an observer pattern in the
CertificateChecker, needed to remove the dependency on the metrics
library from the libpayload_consumer.
Bug: 25818567
TEST=FEATURES=test emerge-link update_engine; mma;
Change-Id: Ia1b6eb799e13b439b520ba14549d8973e18bcbfa
/system/update_engine/omaha_request_action.h
|
| 39910dcd1d68987ccee7c3031dc269233a8490bb |
|
10-Nov-2015 |
Alex Deymo <deymo@google.com> |
Split payload application code into a subdirectory.
This patch splits from the main libupdate_engine code the part that
is strictly used to download and apply a payload into a new static
library, moving the code to subdirectories. The new library is divided
in two subdirectories: common/ and payload_consumer/, and should not
depend on other update_engine files outside those two subdirectories.
The main difference between those two is that the common/ tools are more
generic and not tied to the payload consumer process, but otherwise they
are both compiled together.
There are still dependencies from the new libpayload_consumer library
into the main directory files and DBus generated files. Those will be
addressed in follow up CLs.
Bug: 25197634
Test: FEATURES=test emerge-link update_engine; `mm` on Brillo.
Change-Id: Id8d0204ea573627e6e26ca9ea17b9592ca95bc23
/system/update_engine/omaha_request_action.h
|
| 9fded1eee295295d33da477f00d9c9a240623e91 |
|
05-Nov-2015 |
Alex Deymo <deymo@google.com> |
Send Omaha event_type 54 after reboot to new update.
When rebooting to a new version, we were sending an Omaha event_type 3
to flag a "success reboot". Nevertheless, the server expect us to send
only one event_type 3 for every <updatecheck> response with a payload
but we were sending one event_type 3 upon payload application and
another one after reboot.
This patch changes the event_type sent after reboot to 54, a value
reserved from Chromium OS clients.
Bug: None
Test: Added unittest.
Change-Id: I199a2b00c702175762f2c154ca2f45b3f6ad768c
/system/update_engine/omaha_request_action.h
|
| 3f39d5cc753905874d8d93bef94f857b8808f19e |
|
13-Oct-2015 |
Alex Vakulenko <avakulenko@google.com> |
update_engine: Rename "chromeos" -> "brillo" in include paths and namespaces
libchromeos is transitioning to libbrillo and chromeos namespaces
and include directory is changing to brillo.
Bug: 24872993
Change-Id: I770659a95be380a50fe3b2ba9f91d65818f40945
/system/update_engine/omaha_request_action.h
|
| aea4c1cea20dda7ae7e85fc8924a2d784f70d806 |
|
20-Aug-2015 |
Alex Deymo <deymo@google.com> |
Re-license update_engine to Apache2
This patch automatically replaced the license on all text files from
Chromium OS (BSD style) to AOSP (Apache2), keeping the original year as
a reference.
The license header was added to .gyp and .gypi files, the NOTICE was
replaced with a copy of the Apache2 license and MODULE_LICENSE_* file
was updated.
BUG=b/23084294
TEST=grep 'Chromium OS Authors' doesn't find anything.
Change-Id: Ie5083750755f5180a8a785b24fe67dbf9195cd10
/system/update_engine/omaha_request_action.h
|
| b0d74eb91183eef5955974c515e40c994098372f |
|
31-Mar-2015 |
Alex Deymo <deymo@chromium.org> |
update_engine: Check XmlEncode() input strings.
XmlEncode() only supports valid UTF-8 string. Incomplete UTF-8 strings
would make it crash.
This patch limits the input string to ASCII-7 and falls back to a
default string value whenever an invalid one is found. Some of these
values come from the stateful partition, which would make the
update_engine fail forever.
BUG=chromium:471925
TEST=Added unittests.
Change-Id: I01c5da1b44462a0fe1eb703106a9d0dd3051100b
Reviewed-on: https://chromium-review.googlesource.com/263154
Reviewed-by: Alex Deymo <deymo@chromium.org>
Commit-Queue: Alex Deymo <deymo@chromium.org>
Tested-by: Alex Deymo <deymo@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 8e18f931f634d7c3b3a5fcbfc057e79fa9d6fb80 |
|
28-Mar-2015 |
Alex Deymo <deymo@chromium.org> |
update_engine: Add Cohort, CohortName, CohortHint to Omaha protocol.
This patch persists and sends back to omaha the cohort, cohorthint and
cohortname arguments in the <app> tag. To avoid problems, these strings
are limited to 1024 chars.
BUG=chromium:448995
TEST=unittest added.
Change-Id: I05e7677ee43ab795b670b274d3984803cb6b9522
Reviewed-on: https://chromium-review.googlesource.com/262967
Trybot-Ready: Alex Deymo <deymo@chromium.org>
Tested-by: Alex Deymo <deymo@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: Alex Deymo <deymo@chromium.org>
/system/update_engine/omaha_request_action.h
|
| f68bbbc952aa9a71898e4939b5f36187fa564a50 |
|
09-Feb-2015 |
Alex Vakulenko <avakulenko@chromium.org> |
update_engine: replace std::vector<char> with chromeos::Blob
To make update engine consistent with the rest of platform2 code
replaced std::vector<char> as the container of binary data with
chromeos::Blob.
BUG=None
TEST=`FEATURES=test emerge-link update_engine`
Change-Id: I6385fd2257d15aa24bfa74ac35512c2a06c33012
Reviewed-on: https://chromium-review.googlesource.com/247793
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Alex Deymo <deymo@chromium.org>
Tested-by: Alex Vakulenko <avakulenko@chromium.org>
Commit-Queue: Alex Vakulenko <avakulenko@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 610277efc6f7e5239158dfa4bb3b1021804326e0 |
|
12-Nov-2014 |
Alex Deymo <deymo@chromium.org> |
update_engine: Add override when possible.
Google Style Guide requires to include the "override" keyword
when overriding a method on a derived class, so the compiler will
catch errors if the method is not overriding a member of the base
class.
This patch introduces the "override" keyword when possible.
BUG=None
TEST=FEATURES=test emerge-link update_engine
Change-Id: Ie83d115c5730f3b35b3d95859a54bc1a48e0be7b
Reviewed-on: https://chromium-review.googlesource.com/228928
Tested-by: Alex Deymo <deymo@chromium.org>
Reviewed-by: Alex Vakulenko <avakulenko@chromium.org>
Commit-Queue: Alex Deymo <deymo@chromium.org>
/system/update_engine/omaha_request_action.h
|
| ebbe7ef75279183ba3cf055158dbbb3b3b605e0e |
|
30-Oct-2014 |
Alex Deymo <deymo@chromium.org> |
update_engine: Don't sent <ping a=-1 r=-1> once the device was powerwashed.
When a device is first activated, a <ping a=-1 r=-1> is sent to Omaha
indicating this is a new device activation. After that point, the
active days count will be positive since Omaha sends back the daystart
tag which will be used in the future to compute the non-negative
"a=" and "r=" values.
Nevertheless, when a device is powerwashed, the daystart data is lost
and the first login will trigger a "new device" activation, counting
the same device as two activations in the Omaha side.
This patch uses the powerwash_count file stored in stateful partition
to detect if the new device activation is performed on a device that
was powerwashed at some point and thus doesn't send the a=-1 and r=-1
ping to Omaha. The powerwash_count is generated or incremented
whenever a "safe" powerwash is performed (such as the one that
update_engine triggers on some channel changes). Going to dev mode
and back, going through recovery with an USB key or doing a
"factory" powerwash (done in the factory) *will* wipe this powerwash
count and send the device back to a factory state.
BUG=chromium:428792
TEST=Manual test.
Manual test procude:
1. Run recovery. Check /mnt/stateful_partition/unencrypted/preserve/powerwash_count
is not present.
2. Login for the first time.
3. Check /var/log/update_engine.log shows a '<ping' with 'a="-1" r="-1"' being sent.
4. Powerwash ( echo "safe fast keepimg" > /mnt/stateful_partition/factory_install_reset )
5. Reboot
6. Login for the first time again.
7. Check /var/log/update_engine.log shows doesn't show a '<ping' with 'a="-1" r="-1"'
Change-Id: I1a823040d2da43b93f14241bc521087ce2a2d4f2
Reviewed-on: https://chromium-review.googlesource.com/226716
Reviewed-by: Gilad Arnold <garnold@chromium.org>
Commit-Queue: Alex Deymo <deymo@chromium.org>
Tested-by: Alex Deymo <deymo@chromium.org>
/system/update_engine/omaha_request_action.h
|
| e1e3afe30a214b3661a36474c1448f520662f33c |
|
30-Oct-2014 |
Alex Deymo <deymo@chromium.org> |
update_engine: Cleanup omaha_request_action_unittest.cc.
This patch is a cleanup of the omaha_request_action_unittest. First
it moves members common to all test from the global scope to the
OmahaRequestActionTest class, including the global scope
FakeSystemState instance used on all tests. This fake_system_state
is initialized with a default OmahaRequestParams that is used by many
tests not caring about that parameter. It also sets the default prefs
to a FakePrefs instance, removing the need to create a temp directory
and initialize it in every test. Some tests still replace it with a
MockPrefs when they need to test that some prefs are checked by the
code (testing interaction), but most of them just want to provide a
working Prefs class.
With this change, also the test helper functions were moved to the
OmahaRequestActionTest class, removing the need to pass the optional
classes such as PrefsIterface, PayloadStateInterface, P2PManager and
ConnectionManager which in most tests were passed as nullptr meaning
that the default is used. Instead, with this change, tests that
require a different P2PManager instance for example just create it
and replace it on the fake_system_state_.
This change removes a lot of redundant default code that was hard to
maintain. Now a test requiring to manipulate other classes in the
FakeSystemState class, such as mocking out the HardwareInterface, can
just replace that without adding another parameter to the helper
functions.
BUG=chromium:428792
TEST=Unittest still pass.
Change-Id: Ia3306b11af867d2a1a09be8efae66f6b0326f030
Reviewed-on: https://chromium-review.googlesource.com/226715
Reviewed-by: Alex Deymo <deymo@chromium.org>
Commit-Queue: Alex Deymo <deymo@chromium.org>
Tested-by: Alex Deymo <deymo@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 02f7c1dee242f490143791dbb73fa23fa3007cfa |
|
19-Oct-2014 |
Ben Chan <benchan@chromium.org> |
update_engine: Replace scoped_ptr with std::unique_ptr.
BUG=None
TEST=`FEATURES=test emerge-$BOARD update_engine`
TEST=`USE='clang asan' FEATURES=test emerge-$BOARD update_engine`
Change-Id: I55a2f7f53675faaac20ba25f72ed52cf938d7744
Reviewed-on: https://chromium-review.googlesource.com/224189
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Alex Deymo <deymo@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 88b591f24cb3f94f982d7024c2e8ed25c2cc26a2 |
|
29-Aug-2014 |
Alex Vakulenko <avakulenko@chromium.org> |
update_engine: Replace NULL with nullptr
Replaced the usage of NULL with nullptr. This also makes it possible to
use standard gtest macros to compare pointers in Update Manager's unit tests.
So, there is no need in custom UMTEST_... macros which are replaced with the
gtest macros (see change in update_engine/update_manager/umtest_utils.h):
UMTEST_ASSERT_NULL(p) => ASSERT_EQ(nullptr, p)
UMTEST_ASSERT_NOT_NULL(p) => ASSERT_NE(nullptr, p)
UMTEST_EXPECT_NULL(p) => EXPECT_EQ(nullptr, p)
UMTEST_EXPECT_NOT_NULL(p) => EXPECT_NE(nullptr, p)
BUG=None
TEST=FEATURES=test emerge-link update_engine
USE="clang asan" FEATURES=test emerge-link update_engine
Change-Id: I77a42a1e9ce992bb2f9f263db5cf75fe6110a4ec
Reviewed-on: https://chromium-review.googlesource.com/215136
Tested-by: Alex Vakulenko <avakulenko@chromium.org>
Reviewed-by: Alex Deymo <deymo@chromium.org>
Commit-Queue: Alex Vakulenko <avakulenko@chromium.org>
/system/update_engine/omaha_request_action.h
|
| e8ed86367d92d1f30f340ad28e841846ae58bc61 |
|
24-Jul-2014 |
David Zeuthen <zeuthen@chromium.org> |
update_engine: port from libxml2 to expat.
This allows us to remove libxml2 from the OS and thereby save a couple
of MB of disk space.
BUG=chromium:293137
TEST=Unit tests pass + manual testing.
CQ-DEPEND=CL:209651
Change-Id: I2469f1862dd7e25dd6684640a755745f09b4db06
Reviewed-on: https://chromium-review.googlesource.com/209770
Reviewed-by: David Zeuthen <zeuthen@chromium.org>
Tested-by: David Zeuthen <zeuthen@chromium.org>
Commit-Queue: David Zeuthen <zeuthen@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 44cab30e0ee04b277e8463785ab069e9885a9f2d |
|
23-Jul-2014 |
Alex Vakulenko <avakulenko@chromium.org> |
update_engine: Sort headers alphabetically (build/include_alpha)
We are going to enable build/include_alpha linter warning soon,
so in preparation for this, fixed the warnings in update_engine.
BUG=None
TEST=cpplint.py --filter=-build/include_order,+build/include_alpha update_engine/*
CQ-DEPEND=CL:209472
Change-Id: I261ea04681599a68ec7cb899f2f881cbe228ff7b
Reviewed-on: https://chromium-review.googlesource.com/209631
Reviewed-by: Alex Deymo <deymo@chromium.org>
Tested-by: Alex Vakulenko <avakulenko@chromium.org>
Commit-Queue: Alex Vakulenko <avakulenko@chromium.org>
/system/update_engine/omaha_request_action.h
|
| cf175a098081f3f0e9ca52d997a7ce1585c14c2d |
|
11-Jul-2014 |
Gilad Arnold <garnold@chromium.org> |
Fix cpplint errors.
The only non-obvious change here is the switch from dynamic_cast to
static_cast in three cases of down-casting in UpdateAttempter.
dynamic_cast is banned by style, nor does it add any safety in this
particular case (subsequent code dereferences the result right away
without checking whether it's null).
BUG=None
TEST=None
Change-Id: I9d49b46362feaf9c6fa13b2715ebe9fe50308a9a
Reviewed-on: https://chromium-review.googlesource.com/207470
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Alex Vakulenko <avakulenko@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>
/system/update_engine/omaha_request_action.h
|
| d2779df63aaad8b65fc5d4badee7dbc9bed7f2b6 |
|
16-Jun-2014 |
Alex Vakulenko <avakulenko@chromium.org> |
update_engine: fixed warnings from cpplint
Fixed all the cpplint warnings in update engine.
BUG=None
TEST=Unit tests still pass.
Change-Id: I285ae858eec8abe0b26ff203b99a42a200ceb71c
Reviewed-on: https://chromium-review.googlesource.com/204027
Reviewed-by: Alex Vakulenko <avakulenko@chromium.org>
Tested-by: Alex Vakulenko <avakulenko@chromium.org>
Commit-Queue: Alex Vakulenko <avakulenko@chromium.org>
/system/update_engine/omaha_request_action.h
|
| d1c4d2dd3daed1d507038046c0355fbafb85260c |
|
05-Jun-2014 |
Gilad Arnold <garnold@chromium.org> |
Change ErrorCode into an enum class.
This change is needed in order for us to be able to import ErrorCode
symbols from chromeos_update_engine into chromeos_update_manager.
Unfortunately, shifting from plain 'enum' into an 'enum class' means
that the compiler treats the new class as a distinct type from int,
which in turn means that plenty of seamless arithmetic/bitwise
operations we used for manipulating error code values throughout the
code needed to be retrofitted with static_cast operators.
In the future, we should consider imposing a proper abstraction on
update engine error codes that'll prevent mingling with value encoding
directly and prevent such nastiness. It'll also make things more
coherent (types, semantics) and safer.
BUG=chromium:358329
TEST=Unit tests.
Change-Id: Ie55fa566b764cdab6c4785d995fb6daee4cb32d3
Reviewed-on: https://chromium-review.googlesource.com/203209
Tested-by: Gilad Arnold <garnold@chromium.org>
Reviewed-by: Alex Deymo <deymo@chromium.org>
Commit-Queue: Gilad Arnold <garnold@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 77f79e876a77796fc248d099b6574f05bd23c954 |
|
03-Jun-2014 |
Chris Sosa <sosa@chromium.org> |
Only disable update downloads over expensive connections, not all transfers.
Previous to this CL, all network traffic was disabled from the update engine
if an update wasn't allowed. Instead, in this CL, we switch to only disable
the update application portion (downloading and applying the payload). This
is done by moving the detection logic from the mechanism (the network fetcher)
to the user of said mechanism i.e. the omaha request/response actions.
I have done a little refactoring of the unittests to make this CL easier to
test and found 1 bug in the http_fetcher_unittests where we weren't sending
either the right URL or handling a server not existing correctly.
This CL comes with one caveat:
Technically in the previous impl if a download started over wifi then got
disconnected / retried and bounced to a different connection type that
we couldn't update over, we'd stop the update. This would no longer be true
here if the http_fetcher recovered seamlessly.
BUG=chromium:379832
TEST=Unittests
Change-Id: I6b1a76e4c030d4e384e8ba0b519424a35406aafb
Reviewed-on: https://chromium-review.googlesource.com/202435
Tested-by: Chris Sosa <sosa@chromium.org>
Reviewed-by: David Zeuthen <zeuthen@chromium.org>
Commit-Queue: Chris Sosa <sosa@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 33bae491eded4ef4f1eb4f4ef0f01ef0e5463f3a |
|
26-Feb-2014 |
David Zeuthen <zeuthen@chromium.org> |
Add new metrics.
The current metrics (Installer.* namespace) have several shortcomings,
for example it's not immediately clear when and how frequent each
metric is reported. This CL introduces new metrics that addresses this
and other problems. The new metrics are all in the UpdateEngine.*
namespace and fall into five categories
UpdateEngine.Daily.* Reported daily.
UpdateEngine.Check.* On every check.
UpdateEngine.Attempt.* On every attempt.
UpdateEngine.SuccessfulUpdate.* With every successful update.
UpdateEngine.* Miscellaneous
Most of the new metrics mimic existing metrics and also leverage the
existing code, book-keeping and unit tests. The plan is to remove the
Installer.* metrics once we're happy with the new ones.
I've also tested this manually by performing updates and verifying
that chrome://histograms looks correct.
BUG=chromium:355745
TEST=New unit tests + unit tests pass + manual testing.
Change-Id: I7a3f68d75910384b116c7e4664776e25d3997584
Reviewed-on: https://chromium-review.googlesource.com/191314
Reviewed-by: David Zeuthen <zeuthen@chromium.org>
Tested-by: David Zeuthen <zeuthen@chromium.org>
Commit-Queue: David Zeuthen <zeuthen@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 759c275760b51defcfe5545abb887ad2616335f4 |
|
18-Mar-2014 |
Alex Deymo <deymo@chromium.org> |
Fix header guards to comply with Google Coding Style.
The Google Style Guide says that every header file should have a
define guard and the format of the symbol name should be
<PROJECT>_<PATH>_<FILE>_H_
This patch does all the minor fixes to comply with this and includes
a header guard for the bzip.h file, which didn't have it.
Also, the Copyright notice is adjusted to the Chromium OS code,
replacing "Chromium Authors" by "Chromium OS Authors".
BUG=None
TEST=build passes.
Change-Id: I6575cc307c464d60a5cb2b132cf1e46acb6500b5
Reviewed-on: https://chromium-review.googlesource.com/190445
Tested-by: Alex Deymo <deymo@chromium.org>
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Queue: Alex Deymo <deymo@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 639aa36fc7e27ba400402cd7a32b091f555783a6 |
|
04-Feb-2014 |
David Zeuthen <zeuthen@chromium.org> |
Record installation date and include it in every Omaha request.
Introduce a new state variable, install-date-days, to track the the
point in time that OOBE completed and include this value - if set - in
each Omaha request. This state variable tracks the number of PST8PDT
("Pacific Time") calendar weeks since Jan 1st 2007 0:00 PST, times
seven. It is included as an attribute of the <app> element, like this:
<app appid="{...}" ... delta_okay="true" ... installdate="2590">
If the state variable is not set, the installdate attribute is not
included.
For new installs (e.g. where OOBE is not complete), the
install-date-days variable is set from the "elapsed_days" value in the
Omaha response. In this case - which should be the majority going
forward - we don't rely on the local clock on the device at all.
On the other hand, for existing installs (e.g. where OOBE was
completed in an OS version not including this CL) and also new
installs where the update-check during OOBE failed (e.g. no network
connection), install-date-days is derived from the timestamp of the
/home/chronos/.oobe_completed marker file. This case obviously relies
on the local clock on the device being set correctly.
Also introduce a new metric, Installer.InstallDateProvisioningSource
to track how install-date-days is provisioned. This metric has two
possible values, kProvisionedFromOmahaResponse (0) and
kProvisionedFromOOBEMarker (1).
In addition to new unit tests, I tested this manually by munging the
/home/chronos/.oobe_completed and
/var/lib/update_engine/prefs/install-date-days files. Also, since
devserver does not send the "elapsed_days" value, I had to point
update_engine to the official Omaha server using the -omaha-url option
with the https://tools.google.com/service/update2 value.
BUG=chromium:336838
TEST=New unit tests + unit tests pass + manual testing.
Change-Id: Id901059c4ab0f9184d1f4ddce72273d739e58224
Reviewed-on: https://chromium-review.googlesource.com/184907
Tested-by: David Zeuthen <zeuthen@chromium.org>
Reviewed-by: David Zeuthen <zeuthen@chromium.org>
Commit-Queue: David Zeuthen <zeuthen@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 8f191b22a1a1ab2b803d65ee488729206e648695 |
|
06-Aug-2013 |
David Zeuthen <zeuthen@chromium.org> |
p2p: Use p2p for updates
This is the main patch for enabling use of p2p for consuming and/or
sharing updates via p2p. Refer to the ddoc and other documentation for
how this works.
BUG=chromium:260426,chromium:273110
TEST=New unit tests + unit tests pass + manual testing
Change-Id: I6bc3bddae1e041ccc176969a651396e8e89cb3f0
Reviewed-on: https://chromium-review.googlesource.com/64829
Reviewed-by: David Zeuthen <zeuthen@chromium.org>
Commit-Queue: David Zeuthen <zeuthen@chromium.org>
Tested-by: David Zeuthen <zeuthen@chromium.org>
/system/update_engine/omaha_request_action.h
|
| a99981fda75fe0b17e96c700e3ddc93eca1cebe5 |
|
29-Apr-2013 |
David Zeuthen <zeuthen@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>
/system/update_engine/omaha_request_action.h
|
| a178e5e6efc0849e286b9275d3b052ada6b1a43f |
|
05-Apr-2013 |
Yunlian Jiang <yunlian@google.com> |
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>
/system/update_engine/omaha_request_action.h
|
| ae4697c073b84b260990a141acd53c6806da0708 |
|
19-Mar-2013 |
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>
/system/update_engine/omaha_request_action.h
|
| 082628869ed3ee3e173c08354d3fc40cdb7df2c0 |
|
29-Dec-2012 |
Jay Srinivasan <jaysri@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>
/system/update_engine/omaha_request_action.h
|
| 2b5a0f065187fd19179e3809148dbfc376ada7a0 |
|
20-Dec-2012 |
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>
/system/update_engine/omaha_request_action.h
|
| 6f6ea00aa8c4cf54b6842be32ca1226854c24f78 |
|
14-Dec-2012 |
Jay Srinivasan <jaysri@chromium.org> |
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>
/system/update_engine/omaha_request_action.h
|
| 23b92a52e8781d68c451d6cd5e67aab1e5f82264 |
|
27-Oct-2012 |
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>
/system/update_engine/omaha_request_action.h
|
| f4318709ff5bd808a5fb8dd360acd9b66253a24e |
|
24-Sep-2012 |
Jay Srinivasan <jaysri@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>
/system/update_engine/omaha_request_action.h
|
| 51dcf260754837962dd22db3b7babee181471e7d |
|
14-Sep-2012 |
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>
/system/update_engine/omaha_request_action.h
|
| 480ddfa079ebd01ed87e495332dec121d9ae781f |
|
02-Jun-2012 |
Jay Srinivasan <jaysri@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>
/system/update_engine/omaha_request_action.h
|
| 56d5aa471205bf2271219252ec94b5f0c986a68b |
|
26-Mar-2012 |
Jay Srinivasan <jaysri@chromium.org> |
Report usage of StopAutoUpdate policy in borgmon charts
Omaha already has an event result for reporting UpdateDeferred (9)
which shows up in the borgman charts. In order to use that we should
perform a normal updatecheck without the updatedisabled set to true and
then discard the response with event type UpdateComplete (3) but with
event result UpdateDeferred (9).
BUG=28645: Report StopAutoUpdate enforcement in Borgmon charts for Omaha
TEST=Tested success, error and deferred cases on my zgb.
Change-Id: I27cb4465ea9876b39edaff3b747ada44a4f875d4
Reviewed-on: https://gerrit.chromium.org/gerrit/19112
Reviewed-by: Don Garrett <dgarrett@chromium.org>
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 7ed561bfe6019ed4b988142e97505d7c643e119c |
|
04-Oct-2011 |
Darin Petkov <petkov@chromium.org> |
AU: Remove support for old-style updates.
This code is basically untested, unused and a security risk. So, remove...
BUG=chromium-os:12542
TEST=unit tests, tested VM update
Change-Id: Ibed0582b09497acef9debdf88658cddc2b5cecce
Reviewed-on: http://gerrit.chromium.org/gerrit/8728
Tested-by: Darin Petkov <petkov@chromium.org>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Commit-Ready: Darin Petkov <petkov@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 771e1bd1ed58ef791ccc41a2b9d96e257403abec |
|
30-Aug-2011 |
Andrew de los Reyes <adlr@chromium.org> |
Make public key verification check binding.
Until now, we've just warned on failure. This CL makes the update fail
if the check fails.
BUG=chromium-os:19872
TEST=unittests; tested on device
Change-Id: I485b2548849f46d2b802c478736671bb44a85aab
Reviewed-on: http://gerrit.chromium.org/gerrit/6998
Reviewed-by: Darin Petkov <petkov@chromium.org>
Tested-by: Andrew de los Reyes <adlr@chromium.org>
/system/update_engine/omaha_request_action.h
|
| d903c3b0507a433ec25675ed6dc68ce8551127c7 |
|
13-May-2011 |
Chris Masone <cmasone@chromium.org> |
[update_engine] Roll forward to new libchrome
BUG=chromium-os:14304
TEST=build, unit tests
Change-Id: Ic6bc4c27ade8f960b770cd766753d6e5729d4878
Reviewed-on: http://gerrit.chromium.org/gerrit/823
Reviewed-by: Chris Masone <cmasone@chromium.org>
Reviewed-by: Darin Petkov <petkov@chromium.org>
Tested-by: Chris Masone <cmasone@chromium.org>
/system/update_engine/omaha_request_action.h
|
| 116fda3221ff3df037ea1feb271883c87644c839 |
|
19-Apr-2011 |
Thieu Le <thieule@chromium.org> |
Add support to update_engine to poke Omaha after an update has been applied
successfully and is awaiting reboot to help ensure the number of actives
remains accurate.
BUG=chromium-os:12026
TEST=Manual test, unit tests
Change-Id: Ie3397264b0b34e8d423fb9748970f7d330122180
Review URL: http://codereview.chromium.org/6836025
/system/update_engine/omaha_request_action.h
|
| 173e63c7e21ea7a6fdda0509c6184d79e146e4c3 |
|
05-Apr-2011 |
Andrew de los Reyes <adlr@chromium.org> |
AU: OmahaRequestAction: allow to be skipped.
This CL changes OmahaRequestAction to take a request to skip its
action when it's run. This will be useful in a future CL, where we'll
want to schedule an OmahaRequestAction to run, but then in some cases
prevent it from actually doing so.
This also changes MockHttpFetcher to be able, if properly configured,
to fail it it's used. This is used in the test to make sure that a
skipped OmahaRequestAction does no HTTP traffic.
BUG=chromium-os:13813
TEST=unittests
Review URL: http://codereview.chromium.org/6677146
Change-Id: Ic3e4099d221c4d7d0bca65b1a0064c33dca4edb5
/system/update_engine/omaha_request_action.h
|
| 95508da905b279a6b91aadfc7c4c72f57a5fa610 |
|
05-Jan-2011 |
Darin Petkov <petkov@chromium.org> |
AU: Send a previous version event after reboot following an update.
The previous version event is sent along with the first update check. This is
best effort -- if the update check doesn't reach the server, the event is lost.
BUG=9198
TEST=unit tests, tested on device
Change-Id: I5ceb7c8e99ae54eb331f6ac58b8977d2a111461c
Review URL: http://codereview.chromium.org/5993007
/system/update_engine/omaha_request_action.h
|
| 6c11864907e9a92f8069c77c08650102e0b34e0d |
|
21-Oct-2010 |
Darin Petkov <petkov@chromium.org> |
AU: propagate a deadline form the update check response to Chrome.
Currently, this is done through the file system.
BUG=3284
TEST=unit tests
Change-Id: I0e579ef6ccd7832ca22a248e71f2689c27159056
TBR=resubmitting due to git issues
/system/update_engine/omaha_request_action.h
|
| 85ced136af57dbfa442e163b430d3c7a3c0a94f5 |
|
01-Sep-2010 |
Darin Petkov <petkov@chromium.org> |
AU: Implement server-dictated poll interval.
The server will need to include a PollInterval XML attribute in its
update check response. The requested interval is in seconds.
BUG=5984
TEST=unit tests, gmerged on device and tested with a modified dev server
Change-Id: I89d13f9f85d93bc141b74ae677cca813e3364fb5
Review URL: http://codereview.chromium.org/3275006
/system/update_engine/omaha_request_action.h
|
| 1023a6029771fb8dea867e14193df8e58a59a662 |
|
30-Aug-2010 |
Darin Petkov <petkov@chromium.org> |
AU: Implement exponential back off for 500 and 503 HTTP response codes.
Also refactors the automatic update checks into a separate
scheduler class and adds unit tests for them.
update_check_scheduler.cc 59 / 59: 100.0%
update_check_scheduler.h 1 / 1: 100.0%
Note: because the unit tests for this CL use the
UpdateAttempter class, the CL brings in several untested
modules into the test report reducing the overall test
coverage to ~82%.
BUG=2394
TEST=unit tests, gmerged on device and inspected logs
Change-Id: I078b1727b5338f6fc34e51f5e04a375518d63cef
Review URL: http://codereview.chromium.org/3215006
/system/update_engine/omaha_request_action.h
|
| 84c763cffce6778711792944387fadb760c55c8d |
|
30-Jul-2010 |
Darin Petkov <petkov@chromium.org> |
AU: Remove instances of Omaha ID -- machine ID and user ID.
Also add a unit test to make sure we are not sending machineid or userid
attributes.
BUG=1439
TEST=unit tests, gmerged on device, checked for update, looked at logs
Review URL: http://codereview.chromium.org/2808082
/system/update_engine/omaha_request_action.h
|
| 1cbd78ffe68039a5781c3434816e03e64033dc0b |
|
29-Jul-2010 |
Darin Petkov <petkov@chromium.org> |
Don't send machine and user ID to Omaha anymore. Send a/r pings instead.
This avoids sending a unique ID in order to track active user counts.
Note that this CL doesn't remove the machine/user/Omaha ID/file from
the params object -- it just makes them unused/obsolete. Removal will
be done in a subsequent CL in an effort to make this CL smaller.
BUG=1439
TEST=unit tests, x86-generic, arm-generic, gmerged and inspected logs
Review URL: http://codereview.chromium.org/2856070
/system/update_engine/omaha_request_action.h
|
| e17f86bae4299882232d3e6858ada68692e80501 |
|
20-Jul-2010 |
Darin Petkov <petkov@chromium.org> |
Switch OmahaEvent's error_code to ActionExitCode.
Also, emit the errorcode attribute only for non-success events.
Added explicit unit tests for OmahaEvent.
BUG=560
TEST=unit tests, gmerged on device, forced update, looked at logs.
Review URL: http://codereview.chromium.org/3035007
/system/update_engine/omaha_request_action.h
|
| 8c2980e8b973a21468c9fece0490cd440afc0660 |
|
17-Jul-2010 |
Darin Petkov <petkov@chromium.org> |
AU: send success events to Omaha at more points in the update process.
BUG=560
TEST=unit tests, gmerged on device and looked at logs, emerge-arm-generic.
Review URL: http://codereview.chromium.org/3044003
/system/update_engine/omaha_request_action.h
|
| 3270f7411f55b872db385d0edffdfed18a684121 |
|
16-Jul-2010 |
Andrew de los Reyes <adlr@chromium.org> |
AU: Changes for deltas on traditional bios machines.
BUG=None
TEST=Attached unittests/tested on image
- Fix uninitialized variable err in action processor unittest
- Let Omaha dictate if an update is a delta or full update
- Bug fix in delta generator for differently-sized images
- More logging when applying delta updates
- Fix infinite loop in http fetcher unittest
- log each HTTP connection to know when a dropped connection is
reestablished.
- Detect when speed goes below a threshold and reestablish HTTP
connection (currently < 10bytes/sec for 90 contiguous seconds).
- Fix stack overflow in libcurl http fetcher.
- optimize out a lot of needless CPU usage in libcurl http fetcher
(turns out adding a glib main loop source uses a lot of CPU).
- subprocess: pass PATH, log stdout/stderr
- postinstall runner: support for ext3 and ext4 target filesystems.
Review URL: http://codereview.chromium.org/2805027
/system/update_engine/omaha_request_action.h
|
| a4a8a8ccc2d9e0285728ed247b43f09433e63323 |
|
16-Jul-2010 |
Darin Petkov <petkov@chromium.org> |
Turn OmahaRequestPrepAction into OmahaRequestDeviceParams.
Pass the params to OmahaRequestAction's ctor. This simplifies a bit
executing as well as testing of OmahaRequestAction and testing of
OmahaRequestDeviceParams. It also allows us to initialize the params
once per update attempt and use them for all OmahaRequestActions.
BUG=560
TEST=unit tests, gmerged on device and forced an update through dev server,
inspected logs.
Review URL: http://codereview.chromium.org/2836053
/system/update_engine/omaha_request_action.h
|
| 0dc8e9a73fc3179a67a72ab72ceb2bc6540949bf |
|
14-Jul-2010 |
Darin Petkov <petkov@chromium.org> |
Initial implementation of sending an install success event to Omaha.
BUG=560
TEST=emerged,ran unit tests
Review URL: http://codereview.chromium.org/2981008
/system/update_engine/omaha_request_action.h
|
| 6a5b3229b44c1f81ee153829e9b501e547f29926 |
|
13-Jul-2010 |
Darin Petkov <petkov@chromium.org> |
Rename UpdateCheckAction|Params to OmahaRequestAction|Params.
Also, renamed UpdateCheckResponse to OmahaResponse.
BUG=560
TEST=unit tests, gmerge'd on device.
Review URL: http://codereview.chromium.org/2981007
/system/update_engine/omaha_request_action.h
|