| Age | Commit message (Collapse) | Author |
|---|
|
BUG=none
TEST=unittest
Change-Id: Icdaf5017e03a197bc576f08f4b8dcdd00cff217c
Reviewed-on: https://chromium-review.googlesource.com/1407541
Commit-Ready: Amin Hassani <ahassani@chromium.org>
Tested-by: Amin Hassani <ahassani@chromium.org>
Reviewed-by: Sen Jiang <senj@chromium.org>
|
|
We changed the ActionProcessor interface and how we update boot flags in
CL:1065113 and CL:1011244. This patch reflects those changes in
update_attempter_android.*
BUG=chromium:807976
TEST=unittests
TEST=build and run in android
Change-Id: Ib06b6c1560e58771e66288208a525130a5811360
Reviewed-on: https://chromium-review.googlesource.com/1150737
Commit-Ready: Amin Hassani <ahassani@chromium.org>
Tested-by: Amin Hassani <ahassani@chromium.org>
Reviewed-by: Sen Jiang <senj@chromium.org>
|
|
Currently, an object that uses an ActionProcessor for processing one or more
actions has to own the Actions. This is problematic, because if we want to
create an action on the fly and use an ActionProcessor to perform it, we have to
own the Action until it is finished. Furthermore, if someone forget to own the
action, there will be memory leaks because ActionProcessor does not delete the
Action.
This patch passes the ownership of the Actions to the ActionProcessor through
unique pointers. If an object wants to have access to the Action, it can get it
when ActionComplete() is called.
BUG=chromium:807976
TEST=unittests
TEST=cros flash
TEST=precq
Change-Id: I28f7e9fd3425f17cc51b4db4a4abc130a7d6ef8f
Reviewed-on: https://chromium-review.googlesource.com/1065113
Commit-Ready: Amin Hassani <ahassani@chromium.org>
Tested-by: Amin Hassani <ahassani@chromium.org>
Reviewed-by: Xiaochu Liu <xiaochu@chromium.org>
|
|
This patch implements the core functionality of suspend/resume actions
from the ActionProcessor. No actions support suspend/resume yet.
Bug: 27047026
TEST=Added unittets, tested on edison-eng.
Change-Id: Ib9600098dbccf05fc30f10f0add4a5bc87892b66
|
|
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
|
