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
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
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.
The current argument is unused and it should have been removed
with commit 81229329f1
("Generate download clients using a builder class"). Instead of
removing it completely, use it to pass the File of the download.
This change allows to define a proper interface for the download
client and keep its implementation completely separate. It also
allows to create clients without starting the download right away,
which could be useful when defining callbacks that require a
reference to the client.
Note that this change also drops the unused methods of DownloadClient.
The files are supposed to be downloaded in a privileged location
that the user can't access. If the user wipes the data of the
application, the updates downloaded are not removed. Perform a
one-time cleanup so that our downloads dir doesn't grow without
control.
Each update must now be in updates.json to be downloaded. Since this
file already stores the URL of each update and that the URL is not
needed after the download, the URL entry can be removed from the
database.
This allows to properly update the status of the application.
In particular, when an update is deleted:
- Cancel the associated notification, if any.
- Remove the entry from the controller if the update is no longer
available online.
- Disable the resume button if download is partially downloaded
and is no longer available online.
It's possible to resume already completed downloads. When this
happens, starts verifying the package. Otherwise we won't be
able to resume the download since the server will likely reply
with 416.
