| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
This patch enables -Wnon-virtual-dtor enforcing that virtual classes
such as interfaces have a virtual destructor. This is required by
the Google Coding Style and avoids some problems where the derived
class' destructor is not called.
BUG=None
TEST=FEATURES=test emerge-link update_engine
Change-Id: Id907e3c14923fcccc20b83bd064fa9c9c51fffb3
Reviewed-on: https://chromium-review.googlesource.com/228927
Commit-Queue: Alex Deymo <deymo@chromium.org>
Tested-by: Alex Deymo <deymo@chromium.org>
Reviewed-by: Alex Vakulenko <avakulenko@chromium.org>
|
|
update_engine no longer uses the integer types from base/basictypes.h.
It should simply include base/macros.h for the DISALLOW_COPY_AND_ASSIGN
macro instead.
BUG=None
TEST=`FEATURES=test emerge-$BOARD update_engine`
Change-Id: Idf18bc69339b7170122b289342c724c862454062
Reviewed-on: https://chromium-review.googlesource.com/216140
Tested-by: Ben Chan <benchan@chromium.org>
Reviewed-by: Alex Deymo <deymo@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
|
|
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>
|
|
Fixed remaining errors from cpplint as well as some spelling errors
mostly in comments.
BUG=None
TEST=FEATURES=test emerge-link update_engine
Change-Id: I484988ab846ac5a3c68c016ddccfb247f225ec27
Reviewed-on: https://chromium-review.googlesource.com/208897
Reviewed-by: Alex Vakulenko <avakulenko@chromium.org>
Commit-Queue: Alex Vakulenko <avakulenko@chromium.org>
Tested-by: Alex Vakulenko <avakulenko@chromium.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Enterprises need the ability to stop the auto updates and pin clients
to a given target version. This CL adds support for these features in
the update_engine.
BUG=27307: Implement StopAutoUpdate based on enterprise policy
TEST=Added new unit tests, manually tested all cases on ZGB.
CQ-DEPEND=I523c3f67e0cb07fd24744dc0a30382ff2fe2128a
Change-Id: Id576401afc6d2c93f0e9ece7c6c0ddcf4b1bc00d
Reviewed-on: https://gerrit.chromium.org/gerrit/17867
Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
Reviewed-by: Jay Srinivasan <jaysri@chromium.org>
Tested-by: Jay Srinivasan <jaysri@chromium.org>
|
|
BUG=chromium-os:16006
TEST=unit tests, tested on device
Change-Id: I94938529aa2cf2d85396a632d03624c71528b7f9
Reviewed-on: http://gerrit.chromium.org/gerrit/2786
Tested-by: Darin Petkov <petkov@chromium.org>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
|
|
The firmware updater will fail if we are booted into FW slot B and we
try to update firmware. We shouldn't treat this like a usual update
failure because trying again won't help until we reboot. Thus, with
this CL, we detect this case and request a reboot from the
user. Technically this request is a lie, b/c we are reusing the reboot
request mechanism which tells the user an update has been applied and
thus must be rebooted. We accept this fib since this situation is very
rare: use would have to have 2 FW update updates in a row w/o any
extra boots between.
Also, fix error code in subprocess.
Also, remove execute permissions on a bunch of source files.
BUG=chromium-os:14343
TEST=unittests, tested updates on machine that success, fail, have FW B failure
Review URL: http://codereview.chromium.org/6880077
Change-Id: I2509c6e1c9c9da3ff1ea27da4861c4850bd4d000
|
|
Make a new OmahaEvent (Type: 14 (kTypeUpdateDownloadFinished), Result:
0 (kResultError), ErrorCode: 18
(kActionCodeDownloadPayloadPubKeyVerificationError)). This event is
sent if we have a successful download that fails public key
verification. Currently this is a non-fatal failure, but we plan to
make it fatal in future clients.
BUG=chromium-os:13341
TEST=unittests; 3 on device tests: w/o public key on device, w/ pub
key and matching download, w/ pub key and non-matching download
Change-Id: Ib6589c78449c2dfcbffa4c85ab679f7fe844584b
Review URL: http://codereview.chromium.org/6792065
|
|
This is necessary to ensure that if a public key is present the payload is
signed and the signature passes verification.
BUG=chromium-os:11760
TEST=unit tests, tested on device
Change-Id: I6af61ead0e918c0b971dbcfeabcab3be03e6eb97
Review URL: http://codereview.chromium.org/6574009
|
|
BUG=chromium-os:10320
TEST=unit test, tested on device in normal and dev mode
Change-Id: I67d695bc167a4cc1a638711f047e2b86f8eaa8f1
Review URL: http://codereview.chromium.org/6098008
|
|
Use instances of FilesystemCopierAction to do applied update verification. This
speeds it up slightly because asynchronous reads happen in parallel with hash
calculation but, more importantly, makes update_engine be responsive to D-Bus
during that step.
BUG=9140
TEST=unit tests, tested on device
Change-Id: I3ec9445de5e8258a63433a61f1a476aef4434f6c
Review URL: http://codereview.chromium.org/5516009
|
|
BUG=6251
TEST=unit tests, tested on device
Change-Id: If1b28d47287abeb0a507d77aa3790fdf39d6513a
Review URL: http://codereview.chromium.org/4719002
|
|
BUG=8651
TEST=unit tests, tested an update on the device through dev server
Change-Id: Ic590906be269fe371702bfbe282cddc197ab01fc
Review URL: http://codereview.chromium.org/4432002
|
|
New style full updates will not send the old rootfs hash so no check takes
place.
BUG=7562
TEST=unit tests, gmerged on device and tested with good/bad source partition
Change-Id: I65b28bf57110e4d87472d4aea59121878cde24b0
Review URL: http://codereview.chromium.org/3712003
|
|
Also, don't try to resume any delta update that fails for any reason
other than download transfer errors.
BUG=7348
TEST=unit tests, gmerged on device
Change-Id: Ice464b8d421256717d7909fd5fa46d762bd48952
Review URL: http://codereview.chromium.org/3599025
|
|
The signature and hash are verified only if the public key file exists.
This means that currently this feature is desabled until we install a public
key.
BUG=5663
TEST=unit tests, applied a signed delta update on the server
Change-Id: I5be72f7fde88400587f8aae0c7d5745c79fc4428
Review URL: http://codereview.chromium.org/3592008
|
|
This patch makes sure that the size of the payload received from the server
matches the size reported by Omaha. We could also verify that the HTTP header
size field matches the Omaha size but that seems redundant -- ultimately, it's
important that the number of bytes that AU actually downloads (and calculates
the hash on) matches the Omaha size.
BUG=6579
TEST=unit tests, gmerged on device and tested with a regular as well as a
modified dev server to send incorrect size.
Change-Id: I2f38e2df53e713c0b4f417533028fcb623e2df16
Review URL: http://codereview.chromium.org/3499004
|
|
This increases the UpdateAttmpter line coverage to almost 40%. More is needed
but this is a good starting point / checkpoint. Also some UpdateCheckScheduler
unit test cleanup.
BUG=6243
TEST=unit tests, gmerge on device
Change-Id: I39c80de3f18095c4a28cb36ab868bed6d7073824
Review URL: http://codereview.chromium.org/3259011
|
|
This way if we miss a spot for returning a more specific error code,
we'll at least know which action failed.
BUG=560
TEST=unit tests, gmerged and confirmed that the PostinstallRunner action
still fails...
Review URL: http://codereview.chromium.org/2819059
|
|
BUG=560
TEST=unit tests
Review URL: http://codereview.chromium.org/3046007
|
|
This way we can signal specific error conditions and then
send appropriate events to Omaha from the UpdateAttempter.
BUG=560
TEST=unit tests, gmerged and looked at logs
Review URL: http://codereview.chromium.org/3022008
|
|
Also, some bug fixes.
Review URL: http://codereview.chromium.org/492008
|
|
- proto file for delta files; still needs hardlink support
- code to generate a delta update from two directory trees (old, new).
- code to parse delta update
- Actions: postinst-runner, install, bootable flag setter, filesystem
copier, Omaha response handler, Omaha request preparer,
- misc utility functions, like StringHasSuffix(), templatized Action
classes to feed/collect an object from another action.
- FilesystemIterator: iterates a directory tree with optional
exclusion path. Tolerates deleting of files during iteration.
- Subprocess class: support for synchronously or asynchronously
running an external command. Doesn't pass any env variables.
- Integration test that strings many Actions together and tests using
actual Omaha/Lorry. Currently only tests full updates.
- New simple HTTP server for unittest that supports fake flaky
connections.
- Some refactoring.
Review URL: http://codereview.chromium.org/466036
git-svn-id: svn://chrome-svn/chromeos/trunk@334 06c00378-0e64-4dae-be16-12b19f9950a1
|
|
git-svn-id: svn://chrome-svn/chromeos/trunk@24 06c00378-0e64-4dae-be16-12b19f9950a1
|
