We are referencing the wrong key for deciding whether to delete the
update on reboot.
Change-Id: If83d278259291b61c26302bdd59c2774901b18ca
Signed-off-by: Roman Birg <romanbirg@gmail.com>
When the installation terminates because of an error, update_engine
sets the status to IDLE and sends a notification. Thus, we might
miss the error report and never update the status of the update.
Change-Id: Ic1536b1c157c4dab0128f039f9512f2fb734287d
This should prevent future changes from accidentally turning a
sticky service into a not sticky one.
Change-Id: I89f172626a98635149441a63536e0aa5a27f8280
The NPE shouldn't happen as we get a null intent only when the
service is sticky (i.e., isInstallingUpdate() is true), so this
is currently not a problem.
Change-Id: I8647498d9a1022f5c7207a2da3e42cf57d9ee030
UpdateEngine doesn't send an initial notification to bound client
if the last status is not known, so clear the preference when we
detect that the device has been rebooted.
Change-Id: Ib15dff5fa8ac9ec07a68018a83683cc561fd3e85
Otherwise the service won't run in foreground after restarting
the app while an update is being installed.
Change-Id: I8a75d206ead2945e7326c144b0b4354fbb2accb4
We are loosely tied to UpdateEngine and have no way to know whether
we are bound or not without keeping track of the connection manually.
Since UpdaterService is for both A/B and legacy updates, turn
ABUpdateInstaller into a singleton to keep the code simple while
ensuring that a single callback is registered.
Change-Id: Ib4e9ad1413ba96bf5ed59cc3383741b5c9bac427
Same as change I488018d01c0baf74660362a384e53bfe5d85de2b
("Use a service to export the updates"). While at it, move the code
out of UpdaterService to better separate the code that deal with AB
updates and regular updates.
Change-Id: I2bc3e78e80f5e63c57303cbbcdc0353dbab0f67f
The update engine service is independent and once started doesn't need
our service to install updates. Therefore we can't assume that our
service will stay up as long as the installation is being performed.
If the service gets terminated while an update is being installed, we
simply lose our connection to the update engine service and stop
receiving notifications, the installation itself won't stop. Keep
track of ongoing installations using a shared preference and use a
sticky service when installing updates. The service will try to
re-connect to the update engine service and determine if the
installation is still ongoing.
Change-Id: Id2fc11cab51610d04bf41a0927824bb8c0c94d71
Consider an update as installed only when update engine reports that
the device needs to be rebooted. This change also move the entire
logic in onStatusUpdate(), which reports all we need to properly
track the progress of the installation.
Change-Id: Ic8db00cccdd19fd62ba4dee31fd1dccc9037193d
The version of OkHttp used in AOSP doesn't handle dynamic table size
updates [1] properly [2]. Instead of fixing OkHttp or importing a
prebuilt updated version, implement a new download client only using
HttpURLConnection, which seems to work properly.
[1] https://tools.ietf.org/html/rfc7541#section-6.3
[2] https://trac.nginx.org/nginx/ticket/1397
Change-Id: I3eedf7326f2017812c4a12d41f9ea028d255f7a8
It takes a bit of time to actually pause (i.e. cancel) a download. If
we change the update status once the download is actually cancelled,
we might override any status change that happened between the user
request and its completion. For example, the following can happen when
the user deletes an ongoing downloads:
- pauseDownload(): DOWNLOADING -> PAUSED
- deleteUpdate(): PAUSED -> DELETED
- onFailure(): DELETED -> PAUSED
Don't change the status of cancelled downloads from the onFailure()
callback not to have an incorrect final status.
Change-Id: Iee90482d82df984672c59d7c508ad834fa08061f
On encrypted devices, uncrypt modifies the zip so that it can be
read without mounting the filesystem. Instead of installing the zip
downloaded, create a copy of it which will be deleted. This will
allow to re-install the zip multiple times or export it after
installing it.
The controller should report the actual status of the downloads, let
the clients handle the special cases. Also, don't try to resume
downloads whose destination doesn't exist.
This partially reverts 7369e9cea9
("Set the status of paused downloads to unknown if no file exists").
The returned content-length depends on the requested range, therefore
when resuming download the reported size is smaller than the actual
file size and we should not update it.
