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
In this way apks built with gradle/Android Studio will have the
same versionCode, allowing to update the one in /system.
Change-Id: I020cc623dd7c1c5085fec4e6f5978b6ee46468a2
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
AsyncTasks are not suitable for long lasting operations and can easily
cause memory leaks. The use of ProgressDialogs is also discouraged, so
move to a foreground service to export the updates.
Change-Id: I488018d01c0baf74660362a384e53bfe5d85de2b
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
* To allow transitions from e.g. variant->unified build
* Example process, using klteusc->klte as the example:
- Set ro.updater.next_device to klte in klteusc's tree
- Wait for build to roll out with ro.updater.next_device
- Pull klteusc from build roster
Change-Id: I3c70d54de3f9e036cd8700edc4ee0b11093740d2
The builds for each device are released more or less at the same
time of the day, so check when the last build was released and
schedule the next check accordingly. Also, allow multiple automatic
updates check in the same day. There's no need to limit the number
of checks since they are not frequent and this can affect negatively
the effectiveness of the new algorithm. In addition to that, remove
any pending oneshot alarm in case a subsequent check succeeds and
log every new alarm.
Change-Id: I4668f2e342e51d3578992eec6d8c270065d9aa21
The condition was wrong and incompatible updates were always
discarded regardless of the flag passed.
Change-Id: Iefc2d64b841921eb77a9f73cf374b63b477d2588
Major upgrades are not possible with Updater and they are already
blocked. This commit adds a dialog with a link to a webpage that
explains how to upgrade manually.
Based on: d5d343d627
Change-Id: Ifb23e0a4db1060fc696d13e6694f3e849af70e2d
There is a problem with Java's toLowerCase() method which returns
"LATIN SMALL LETTER DOTLESS I" for "I" character. This breaks update check
because Utils.getInstalledBuildType() returns "nıghtly (notice dottles small
i)" instead of "nightly".
This change forces toLowerCase() to use ROOT locale which is recommended in
javadocs
There is a note for Turkish locale on javadocs:
http://devdocs.io/openjdk~8/java/lang/string#toLowerCase--
Change-Id: Ifada815202588d67643136846de08f94cefb46a5
Signed-off-by: Mustafa Karatas <mstfkaratas@gmail.com>
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
