History log of /packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadScanner.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
053674aa4d0ecd7e37dadb8ee37a9cafbdf2f16c 09-May-2016 Jeff Sharkey <jsharkey@android.com> Scan completed downloads when requested.

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
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadScanner.java
3a5f5eafb34eaa4963c801882148e8f61514a61b 21-Apr-2016 Jeff Sharkey <jsharkey@android.com> Move DownloadManager to use JobScheduler.

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
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadScanner.java
9b731a5521f569c91aeb419d43fa098a34cf78cb 27-Jan-2014 Doug Zongker <dougz@android.com> Revert "change download provider to use system log"

This reverts commit 4f9d2d04003fafb358d7c127054055b3a9732c9b, was only
wanted for debugging.
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadScanner.java
4f9d2d04003fafb358d7c127054055b3a9732c9b 27-Jan-2014 Doug Zongker <dougz@android.com> change download provider to use system log

Try to catch the download provider in the act of deleting pending
system updates.

Bug: 12680933
Change-Id: If58aba5c30fd624217e5d073730645af05e98ac7
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadScanner.java
925976230936a5177365dc24b50da8607a9af8d4 12-Feb-2013 Jeff Sharkey <jsharkey@android.com> Redesign of DownloadManager update loop.

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
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadScanner.java