| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
The recent JobScheduler rewrite means we no longer spin up a service
when insterting an already-completed download. However, the calling
app may have requested the download to be scanned, so kick off a
scan request for them.
Bug: 28659693
Change-Id: I497e10995ba04f1522fe8d7e547ebea6e305f6e9
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JobScheduler is in a much better position to coordinate tasks across
the platform to optimize battery and RAM usage. This change removes
a bunch of manual scheduling logic by representing each download as
a separate job with relevant scheduling constraints. Requested
network types, retry backoff timing, and newly added charging and
idle constraints are plumbed through as job parameters.
When a job times out, we halt the download and schedule it to resume
later. The majority of downloads should have ETag values to enable
resuming like this.
Remove local wakelocks, since the platform now acquires and blames
our jobs on the requesting app.
When an active download is pushing updates to the database, check for
both paused and cancelled state to quickly halt an ongoing download.
Shift DownloadNotifier to update directly based on a Cursor, since we
no longer have the overhead of fully-parsed DownloadInfo objects.
Unify a handful of worker threads into a single shared thread.
Remove legacy "large download" activity that was thrown in the face
of the user; the UX best-practice is to go through notification, and
update that dialog to let the user override and continue if under
the hard limit.
Bug: 28098882, 26571724
Change-Id: I33ebe59b3c2ea9c89ec526f70b1950c734abc4a7
|
| |
|
|
|
| |
This reverts commit 4f9d2d04003fafb358d7c127054055b3a9732c9b, was only
wanted for debugging.
|
| |
|
|
|
|
|
|
| |
Try to catch the download provider in the act of deleting pending
system updates.
Bug: 12680933
Change-Id: If58aba5c30fd624217e5d073730645af05e98ac7
|
|
|
Previously, the service lifecycle was managed through a large for()
loop which was extremely tricky to reason about. This resulted in
several race conditions that could leave the service running
indefinitely, or terminate it early before tasks had finished.
This change redesigns the update loop to be event driven based on
database updates, and to collapse mutiple pending update passes. It
is much easier to reason about service termination conditions, and
it correctly uses startId to handle races during command delivery.
Also moves scanner into isolated class, and switches to using public
API instead of binding to private interface.
Bug: 7638470, 7455406, 7162341
Change-Id: I380e77f5432223b2acb4e819e37f29f98ee4782b
|
