History log of /packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
be3aa64469e8d1806250318808f79f41fb4c7cbd 17-Jun-2014 Christopher Tate <ctate@google.com> Transition the Download Service's cleanup work to a scheduled Job

...preparatory to finally removing the scratchpad "idle maintenance"
infrastructure from the product.

Bug 14993295

Change-Id: I1e84247de19e616910db1781b2c399a8b15a805c
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
dffbb9c4567e9d29d19964a83129e38dceab7055 31-Jan-2014 Jeff Sharkey <jsharkey@android.com> Many improvements to download storage management.

Change all data transfer to occur through FileDescriptors instead of
relying on local files. This paves the way for downloading directly
to content:// Uris in the future.

Rewrite storage management logic to preflight download when size is
known. If enough space is found, immediately reserve the space with
fallocate(), advising the kernel block allocator to try giving us a
contiguous block regions to reduce fragmentation. When preflighting
on internal storage or emulated external storage, ask PackageManager
to clear private app caches to free up space.

Since we fallocate() the entire file, use the database as the source
of truth for resume locations, which requires that we fsync() before
each database update.

Store in-progress downloads in separate directories to keep the OS
from deleting out from under us. Clean up filename generation logic
to break ties in this new dual-directory case.

Clearer enforcement of successful download preconditions around
content lengths and ETags. Move all database field mutations to
clearer DownloadInfoDelta object, and write back through single
code path.

Catch and log uncaught exceptions from DownloadThread. Tests to
verify new storage behaviors. Fixed existing test to reflect correct
RFC behavior.

Bug: 5287571, 3213677, 12663412
Change-Id: I6bb905eca7c7d1a6bc88df3db28b65d70f660221
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.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/DownloadService.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/DownloadService.java
ff0220f5b4624049a1052bd868d7706eee5a0daf 26-Mar-2013 Jeff Sharkey <jsharkey@android.com> Unregister observer when tearing down service.

Also reduce and adjust some logging.

Bug: 8470658
Change-Id: Ia1f1cbd315ded04edd2113506e5c5a1db5ec85b4
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
0f2f63932bd8d963764d37527b3237d219fdaa4d 26-Mar-2013 Fabrice Di Meglio <fdimeglio@google.com> Revert "Avoid sending messages after HandlerThread.quit()."

This reverts commit 97d507d95f9885ceb12f2ce2483361b5ed265f9f

Change-Id: I20374301561b3a1c79c2d986292af50049de2aac
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
97d507d95f9885ceb12f2ce2483361b5ed265f9f 26-Mar-2013 Jeff Sharkey <jsharkey@android.com> Avoid sending messages after HandlerThread.quit().

Bug: 8470658
Change-Id: I4cfd6a01c2c2d845a72d3f58c29eec8b44176537
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
703bc3a83056a878a83e263b992fb5331b84535f 25-Mar-2013 Jeff Sharkey <jsharkey@android.com> Reduce logging, dump stacks before wtf().

Most wtf() are looking like network timeouts, not threading bugs, so
disable verbose debugging and add more targeted thread logging before
calling wtf().

Bug: 8233041
Change-Id: I8e276bffd7880cfe13b65e7e81f5507cab627692
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
a9917b41429e3e18074d8a8a709894e488883686 21-Mar-2013 Jeff Sharkey <jsharkey@android.com> Increase timeout for domains with many DNS entries.

Bug: 8233041
Change-Id: Ifb70273474c391ef687ba018d9ef809a359c7149
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
80a535d83ea9ed21f443fdc701c743569ae53eec 26-Feb-2013 Jeff Sharkey <jsharkey@android.com> Adjust timeouts to reduce false-positive bugs.

Otherwise we end up triggering MSG_FINAL_UPDATE while still waiting
for socket timeouts. Using 20 seconds for timeout is more sane, and
matches Volley.

Bug: 8233041
Change-Id: Ia7220033a5942c46ca1d79a88e2b3f530cb3edac
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
dd1179c09fb6ac2420292e52ea3ced395f76a7be 21-Feb-2013 Jeff Sharkey <jsharkey@android.com> Ack, we actually need to UpdateThread.quit().

Otherwise they end up leaking. There is a race around UpdateThread
continuing to process messages before onDestroy() has been invoked,
so explicitly UpdateThread.quit() in both places.

Bug: 8233041
Change-Id: I73f1b70aedace19e23a61a3dddf4986d82f2c7d6
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
71a53040699e713bcae839a01b7f8abd9e13bab6 21-Feb-2013 Jeff Sharkey <jsharkey@android.com> Only use single UpdateThread.

Since DownloadService starts and stops frequently, recycle a single
UpdateThread across invocations.

Bug: 8233041
Change-Id: I07756fb6bfdbad811cbd58e628fdfdbf63d71bf8
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
d1214c9c92b6a4a44cfc46125c33d071a0f3d880 20-Feb-2013 Jeff Sharkey <jsharkey@android.com> Only report speeds from full samples windows.

Wait until we've passed a full sample window (500ms) before reporting
an estimated speed. This avoid showing skewed times like "900 hours
remaining."

Also remember to clean up the UpdateThread.

Bug: 8176417
Change-Id: I851e0abcbb443114abe9c22f4650fee7a9bc3aaa
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.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/DownloadService.java
38648831a92295e9a11831e19e5a9dab4cbd939e 13-Jan-2013 Jeff Sharkey <jsharkey@android.com> Cleaner thread management, less global state.

Switch to using a ThreadPoolExecutor for handling downloads, which
gives us parallelism logic that is easier to reason about. Also
open the door to eventually waiting until the executor is drained
to stopSelf().

Removes DownloadHandler singleton, and gives explicit path for
publishing active download speeds to notifications.

Change-Id: I1836e7742bb8a84861d1ca6bd1e59b2040bd12f8
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
8ac10e0e0667a4fe35191deebb5fa9786bf4226c 04-Jan-2013 Jeff Sharkey <jsharkey@android.com> Clean up DownloadManager threading tests.

Change runUntilStatus() methods to polling with timeout instead of
requiring internal knowledge about threading.

Fix notification tests, and move opening of InputStream until after
handling headers to avoid FNFE. Always reset facade to defaults
before each test.

Change-Id: I6b2d6cfc4e685d2090c1133b1b2e89ae12760f8b
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
701d66efeff513a7509eeaafab6e47f4f6edb857 05-Jan-2013 Jeff Sharkey <jsharkey@android.com> Remove singleton StorageManager.

Now DownloadService creates and owns the lifecycle of its own
StorageManager instance.

Change-Id: I8f6bedc02f1dbe610a8e6a25d55383a12716d344
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
b0bb182a1b52b31ccf1ec5e0be82308ebb4857e2 13-Dec-2012 Jeff Sharkey <jsharkey@android.com> Cancel stale notifications when starting.

Bug: 7693834
Change-Id: I5e212be321cccae0f7c76f80049c4e09f0867694
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
52b703c5d0c4cff72bafdec0e2229368d3cc20d0 13-Nov-2012 Jeff Sharkey <jsharkey@android.com> Show remaining time in download notifications.

Calculate speed of in-progress downloads and estimate time remaining
until completion. Uses a moving average that is weighted 1:1 with
the most recent 500ms sample. Funnels timing data to notifications
through DownloadHandler.

Bug: 6777872
Change-Id: I9155f2979aa330bd1172f63bbfca1d053815cee5
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
a40a349c0107660bfb4004467550725a3ca3ec97 03-Aug-2012 Jeff Sharkey <jsharkey@android.com> Rewrite of download notifications.

Switch to using new inbox-style notifications when collapsing multiple
downloads. Correctly handles clustering, including cancellation of
stale notifications. All notifications are now handled in a single
class, making it easier to reason about correctness.

Fixed bugs around handling of visibility flags. Move away from using
"int" as internal keys, since they can overflow. Started work for
time estimates, will finish in a future CL.

Explicitly pass all relevant IDs to DownloadReceiver instead of doing
a second racy query. Fix StrictMode warnings when querying in
DownloadReceiver.

Bug: 6777872, 5463678, 6663547, 6967346, 6634261, 5608365
Change-Id: I5eb47b73b90b6250acec2ce5bf8d7a274ed9d3a9
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
70b5c30db87b3405e2e001c06c4a4a5dd6e25b72 06-Oct-2012 Jeff Sharkey <jsharkey@android.com> Skip scanning a file which will be deleted.

When deleting a download, don't bother scanning it, since we'll just
delete it moments later. This was already racy since it didn't even
wait for the scan to complete.

Bug: 7256243
Change-Id: I8c3b96823d94bc1688ef336cb45746ccd35fc760
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
36612d27b67ff2e79ffff8eb12d95d2058abde02 25-Jul-2012 Jeff Sharkey <jsharkey@android.com> Move notification tests to LittleMock.

Directly mock NotificationManager instead of using SystemFacade.

Change-Id: If932d26e23816e8674469c275a828701cce5fc2d
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
ebcc93801eb9545004536587d10f82db378aeab5 21-Jul-2012 Jeff Sharkey <jsharkey@android.com> Reduce deletion logging.

Bug: 6544953
Change-Id: I4157c67b9b9cddab4ade795c328a202f6a230f95
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
f8b1f373fd884fffe384acf564d0a4e374de8e02 20-Apr-2012 Jeff Sharkey <jsharkey@android.com> More slogging around download deletion.

Bug: 6362988
Change-Id: Iab4b86cfcaa6aeed6466f88ff49eb935f96db495
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
6da2d0a2e1d046cd39270a46c3c77f8234f4cfaa 13-Apr-2012 Jeff Sharkey <jsharkey@android.com> Locking around downloads, and more dump info.

Bug: 4997552
Change-Id: I3c612acb5145a7638c9345a376a99958851a0891
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
f4411b0e2255b9abe56e227225398b2aec2a7427 11-Oct-2011 Doug Zongker <dougz@android.com> log when DownloadManager deletes files

Change-Id: Id4800401c16811df9c4ee78ee9636c77b4c95756
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
665f4105ea68a05d85dcd22cc9d823f45f7e6a37 12-Apr-2011 Jeff Sharkey <jsharkey@android.com> Output DownloadInfo state in Service.dump()

Bug: 3136228
Change-Id: I77c4f998c9718c7630800dec152779ff59186187
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
6baceb7073ed7858d3424ccf774e5f6a946bec59 10-Mar-2011 Vasu Nori <vnori@google.com> (master) bug:3204324 allow no more than certain number of concurrent downloads

Change-Id: Ibbce0782fcf7649209d6f56be240209cebd9045b
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
3ff0baf4ed8eaba1b21979335ff1b9d8b2fede70 02-Mar-2011 Vasu Nori <vnori@google.com> remove log spew from downloadmanager

Change-Id: Iad8cfe0da389a70ff679cf6d3378f50e945d03a6
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
789745f667c65661d82ccbd5ef49fdb132911736 09-Feb-2011 Vasu Nori <vnori@google.com> bug:3435895 listen to media_mounted broadcast intent

and retry downloads that failed due to the error "sdcard media not mounted"

Change-Id: Id181b8167d331214f72679c85f18cc8b9b969e40
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
b18ed519040c1ecd98f8cb139adcc315a3f4eedc 21-Jan-2011 Vasu Nori <vnori@google.com> bug:3048327 (master) ability to add completed download to dnload mgr

Change-Id: Ib9d4df107787191a5349365908cbe096b67770dc
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
5218d33d57990c3e3549c58bd3f0ac244dfc3d59 17-Dec-2010 Vasu Nori <vnori@google.com> bug:3286430 set quota on downloads data dir

make sure the doanloads data dir size is limited by some quote -
100MB default and 200MB for SR.
bug:3286430

tests are in Change-Id: I688f7e058511089bec7fa21e972e23780604d98a

Change-Id: Iba7fab9fa91ea018f35e1c3ef5ec0e6b03cba650
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
9aadb4b3f2b3c914166ebfae8851fbecaf536f4f 14-Dec-2010 Vasu Nori <vnori@google.com> Download dir: /data/data/com.android.providers.downloads/cache NOT /cache

bug:3264401
still to do:
make sure only N bytes are taken up by downloads dir
N = a value specific to each device.
default = 100MB.

Change-Id: I2a49f4b3831d3a8d7be13b5fd46d85d56e831e38
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
3f276dc044f533d54392c7385ab5f3b1dcb44594 09-Nov-2010 Vasu Nori <vnori@google.com> if any exceptions encountered while trimming downloads db, ignore 'em.

bug:3176990
Change-Id: I182331cbd63b6524a18d19e4d8567210886f8c16
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
b3ae94915d68e4c3f325ea02bab32d00cccb4f1a 29-Oct-2010 Vasu Nori <vnori@google.com> make sure filename is non-null before delting it.

if a download fails for some reason, then filename could be null.
move Helpers.deleteFile() code into private method in DownloadService

Change-Id: Ifb12a84b6185e19c70d62392e102950c07f56a01
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
fdbeea8d2eb7566bbd556d42960995cfc695c983 27-Oct-2010 Vasu Nori <vnori@google.com> reduce number of times mediascanner is invoked by downloadservice

this is one of the 2 bugs mentioned in bug:3129943
sometimes MediaProvider returns null for returned param Uri.
in such cases, mark the file as 'scanned' in the downloads db
so that it is NOT scanned again later by DownlaodService.

depends on Change-Id: I92514e1a11f5119229c0c7292e410e352a9dbcdd

Change-Id: Ie9d839581f656c929a77bd5f244ad6b2fb1585e6
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
04f09085f85d094207d22ae8969102bd48178180 20-Oct-2010 Vasu Nori <vnori@google.com> remove usage of hidden public constants.

Change-Id: I2edf1bef5e741de8193cb293807e3ace42003b0c
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
be2eaa55bb3dca3422da25fe907b50a4ad70df17 15-Oct-2010 Vasu Nori <vnori@google.com> bug:3099994 NPE in DownloadManager when deleting non-media file

DownloadService always scans files and assumes MediaProvider
returns a valid Uri. But MediaProvider returns null for
return param 'uri'
if the file is not audio/video/image etc media type file
(for example, pdf)

Change-Id: If32bd1895b00b5406973a5e240ad3558d46f9f4a
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
e00c31208405bd2e4c88e069df7a2b15237f70bf 13-Oct-2010 Vasu Nori <vnori@google.com> bug:3069735 in Download UI app, handle deletes correctly

gingerbread.
High-level details
1. When a file is downloaded by DownloadManager, metadata about the file
is stored in 2 databases: DownloadProvider and MediaProvider.

2. So, when it is to be deleted, its metadata needs to be cleaned up from
both the databases.

3. But the 2 databases use differnt content-uri's as "primary keys" and
DownloadProvider loses the "primary-key" of the row in MediaProvider
database.

4. Easiest thing would have been to have DownloadProvider give filepath
to MediaProvider and let MediaProvider linearly scan its database
to locate the row and delete it.

5. The other - faster but more coding for now - option is to have
DownloadProvider store the "primary-key" of the MediaProvider's
row. implemented in this CL.

Low-level details
1. add 2 new columns to downloads table in downloads.db:
mediaprovider_uri = downloaded file's content_uri in mediaprovider db
this column is null for downloads that finished before this column is
added to the database.
deleted = flag is set to true if a file is to be deleted
2. download UI app shows only those files whose 'deleted' flag is not set.
3. when the user deletes downloads from download UI app,
3.1. if mediaprovider_uri is NOT null, then the row is deleted from
downloads table AND from the mediaprovider database.
3.2 if mediaprovider_uri is NULL, then its row in downloads database
is marked 'tp be deleted' by setting 'deleted' column to '1'.
4. When DownloadService (in DownloadProvider) processes all rows from
downloads table, if it sees any rows wth 'deleted' = 1, then
it uses MediaScanner Service to re-scan the file,
get the mediaprovider_uri from MediaProvider
and update the row in downloads table with this mediaprovider_uri value
and then delete the row by doing the following
1. delete it from MediaProvider database using mediaprovider_uri
2. delete it from DownloadProvider database

Problem with this solution:
There is a small window where it is deleted by the user on the Download app
(and the row disappears from the display) but it is still present in
Gallery app.
Thats due to the following asynchronous operations
1. DownladService which processes rows-to-be-deleted is not always up
2. DownloadService uses asynchronous call to have the file re-scanned
by MediaScanner to get mediaprovider_uri

Change-Id: Ib90eb9e647f543312c865d3bbf9a06fb867a648b
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
b108a273b150e81bf26553b8851d6241bc711f98 30-Sep-2010 Steve Howard <showard@google.com> Improve how the download manager reports paused statuses.

This change makes the download manager report more detail when a
download is paused. Rather than always reporting status
RUNNING_PAUSED, there are now four different statuses:

* paused by the app
* waiting to retry after a network error
* waiting for network connectivity
* queued for wifi due to size limits

This allows a few improvements:

* code deciding when to run a download can be improved and cleaned up
(I've taken some extra steps in cleaning up this particular code)
* notification code no longer has to rely on the in-memory-only
"mPausedReason" member of DownloadInfo; instead, it knows from the
status that the download is queued for wifi, and can display the
appropriate string. This moves the string fetching out into the
UI-specific logic and is a sign that this is really the right way
to do things.

And finally, the real motivation for this change: I've changed the
meaning of "Queued" in the downloads UI so it now means "Queued for
WiFi'. This is what was originally intended, I'd misunderstood. What
was formerly known as "Queued", a download that hadn't started, is now
displayed as "In progress" (it's always a transient state so it's
basically meaningless anyway). Otherwise it remains the same (in
particular, downloads paused for other reasons are still reported as
"In progress").

I've also increased some of the logging in DownloadThread a bit, as
this change initally introduced some bugs that were impossible to
track down without that logging. There have been other bug reports
that were impossible to diagnose and these few extra log statements
should really help, without cluttering logs too much. I've taken care
to avoid potentially introducing any PII into the logs.

Change-Id: Id0b8d65fc8e4406ad7ffa1439ffc22a0281b051f
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
ad017bfbbb549cbbaa522038fa46450f0cedf413 28-Sep-2010 Brad Fitzpatrick <bradfitz@android.com> Trim the database & check spurious files off the UI thread.

Change-Id: I92180fc4344579b93361d5584243688a1cfdd091
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
3398db8f3b195959faa2a7cf09918f364432ac28 15-Sep-2010 Steve Howard <showard@google.com> Fix notification bugs, cleanup DownloadService + DownloadReceiver

This change started out just fixing a few regressions related to
notifications:

* Browser downloads weren't picking up a title from the determined
filename. This was due to my change to default the title field to
"" instead of null.

* Notification click/hide events weren't being handled properly. This
was due to previous change to the URI structure of DownloadProvider.
DownloadReceiver needed to be changed to perform queries through
/all_downloads URIs, like all other parts of the download manager
code. I did some general refactoring of the DownloadReceiver code
while I was there.

* The code in DownloadNotification wasn't picking up some updates to
downloads properly. This was due to my change to make
DownloadNotification use the DownloadInfo objects rather than
querying the database directly, so that it could make use of info
provided by the DownloadThread that didn't go into the DB. Fixing
this didn't turn out to be all that complicated, but along the way
to figuring this out I made some substantial refactoring in
DownloadService which made it much cleaner anyway and eliminated a
lot of duplication. That's something that had to happen eventually,
so I'm leaving it all in.

Change-Id: I847ccf80e3d928c84e36bc24791b33204104e1b2
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
3d55d829c03fe78ad8cdab119293efb6c6e49c64 13-Sep-2010 Steve Howard <showard@google.com> New URI structure with "my_downloads" and "all_downloads"

This change introduces a second view into the download manager
database via a set of URIs starting with /all_downloads, renaming the
original /download URIs to /my_downloads. In addition to making
things more clear, this change allows the downloads UI to grant
permissions on individual downloads to viewer apps.

The old semantics were:

* for ordinary callers, /download included only downloads initiated by
the calling UID
* for intraprocess calls or calls by root, /download included all
downloads

The new semantics are

* /my_downloads always includes only downloads initiated by the
calling UID, and requires only INTERNET permission. It could just
as well require no permission, but that's not possible in the
framework, since path-permissions can only broaden access, not
tighten it. It doesn't matter, because these URIs are useless
without INTERNET permission -- if a user can't initiate downloads,
there's no reason to read this.
* /all_downloads always includes all downloads on the system, and
requires the new permission ACCESS_ALL_DOWNLOADS. This permission
is currently protectionLevel=signature -- this could be relaxed
later to support third-party download managers.

All download manager code has been changed to use /all_downloads URIs,
except when passing a URI to another app. In making this change
across the download manager code, I've taken some liberties in
cleaning things up. Other apps are unchanged and will use
/my_downloads.

Finally, this incorporates changes to DownloadManager to return a
content URI for /cache downloads -- the download UI no longer assumes
it's a file URI, and it grants permissions to the receiver of the VIEW
intent. The public API test has also been updated.

I've also fixed some null cursor checking in DownloadManager.

Change-Id: I05a501eb4388249fe80c43724405657c950d7238
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
97d590d5a1f583acb7992d20851bdc6cd0454d12 21-Aug-2010 Steve Howard <showard@google.com> Add UI message when queued for wifi due to size.

As it stands, when a download is paused because it's too big to
proceed over mobile, and must proceed over wifi, it looks like any
other paused download, with no indication of why it's paused. That
may be passable for most other reasons for pausing a download, but it
seems too confusing for this case. So this change adds a simple
string message that replaces the progress bar when a download is
paused for this reason (the icon also changes to a warning).

The implementation isn't beautiful and could use some improvement, but
I think it's acceptable and necessary. The exact UI design and
wording are certainly open to change.

Change-Id: I753d57f463e2614b5694bdc178d2a51066da8ca3
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
e6a05a1aa4697440e9630d12b741b3bae321fe49 27-Jul-2010 Steve Howard <showard@google.com> Serialize threading for download manager testing.

The download manager uses threading in a simple way -- it launches two
threads, UpdateThread and DownloadThread, and both are "fire and
forget". This is fortunate for testing, since it means we can
eliminate multithreading and simply run each thread in order, and
everything still works.

This change does just that, abstracting Thread.start() behind
SystemFacade and making FakeSystemFacade put new threads into a queue
and then run through them serially. This simplifies much of the test
code and makes it all much more predictable.

I've simplified the test code as much as possible here and moved a few
more tests over to PublicApiFunctionalTest, leaving only a minimum in
DownloadManagerFunctionalTest, which will eventually be deleted
altogether. I've also improved testing in some areas -- for example,
we can now test that running notifications get cancelled after the
download completes in a robust way.

There is one test case that checks for race conditions and requires
multithreading. I've moved this into a new ThreadingTest class, which
uses a custom FakeSystemFacade that allows multithreading. I've
extracted AbstractPublicApiTest for the newly shared code.

Change-Id: Ic1d5c76bfa9913fe053174c3d8b516790ca8b25f
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
93155e1da7e89d4925e244f5afa94afb8ada7381 24-Jul-2010 Steve Howard <showard@google.com> Stub out and test system notifications.

This change abstracts NotificationManager interactions behind
SystemFacade and takes advantage of that to test notifications, to a
limited degree.

It also fixes a silly typo in AbstractDownloadManagerFunctionalTest,
and it introduces an extra sleep between tests to avoid some
flakiness. I'll look for a better solution to that problem after this
change goes in.

Change-Id: I3a0307f828955cd45b0e3581ad499da28cc0556e
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
0a77c62a82503b38c484e0079648f0231dd85d53 21-Jul-2010 Steve Howard <showard@google.com> Public API support for broadcasts and connectivity control.

* Three new DB fields, one indicating whether a download was initiated by the public API or not, two to hold connectivity control info. DB migration to add these fields and code in DownloadProvider.insert() to handle them.
* Change broadcast intent code to match public API spec, for public API downloads only. (Legacy code can go away once existing clients are converted over to the new API.)
* Introduce SystemFacade methods for sending broadcasts and checking package ownership; this facilitates new tests of broadcast code.
* Change DownloadInfo.canUseNetwork() to obey new connectivity controls available in public API, but again, retain legacy behavior for downloads initiated directly through DownloadProvider
* New test cases to cover the new behavior

Also made a couple changes to reduce some test flakiness I was observing:
* in tearDown(), wait for any running UpdateThread to complete
* in PublicApiFunctionalTest.setUp(), if the test directory already exists, remove it rather than aborting

DB changes for broadcast + roaming support

Change-Id: I60f39fc133f678f3510880ea6eb9f639358914b4
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
5180de23e77139dd6971dfd48269242e3e3562d9 20-Jul-2010 Steve Howard <showard@google.com> Fix bug with deciding when to restart a download.

In previous refactoring I had combined the code for starting a
download (from DownloadService.insertDownload()) and restarting a
download (from DownloadService.updateDownload()). I'd missed the fact
that the former checks DownloadInfo.isReadyToStart() while the latter
checks DownloadInfo.isReadyToRestart(). This cause a race condition
where multiple startService() calls during a download would cause the
service to try to spawn a second thread for the same running download.

I've fixed the bug and added a test case to exercise this.

Change-Id: Ia968331a030137daac7c8b5792a01e3e19065b38
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
071bd7acb3185f4f1e807855605c5e6018e9742f 16-Jul-2010 Steve Howard <showard@google.com> Support for max download size that may go over mobile

This change introduces support for a maximum download size that may go
over a mobile connection. Downloads above this limit will wait for a
wifi connection.

To accomplish this, I moved a lot of the logic for checking
connectivity info into DownloadInfo itself. I then moved the code to
call these checks from DownloadService, where it would call the checks
before spawning a DownloadThread, into DownloadThread itself. This
makes it simpler to check connectivity after we get Content-Length
info. It also eliminates the risk of a race condition where
connectivity changes between the check and the actual request
execution.

I realize this change reduces efficiency, because we now call into
ConnectivityManager/TelephonyManager twice per DownloadThread, rather
than once per DownloadService "tick". I feel that it's OK since its a
small amount of computation running relatively infrequently. If we
feel that it's a serious concern, and that the efficiency issues
outweigh the race problem, I can go easily back to the old approach.

I've left out the code to actually fetch the limit. I think this will
come from system settings, but I want to double-check, so I'll put it
in a separate change.

Other changes:
* simplify SystemFacade's interface to get connectivity info - rather
than returning all connected types, just return the active type,
since that should be all we care about
* adding @LargeTest to PublicApiFunctionalTest

Change-Id: Id1faa2c45bf2dade9fe779440721a1d42cbdfcd1
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
af28400b74de05862b470412a5c92f68e99f59f8 16-Jul-2010 Steve Howard <showard@google.com> Introduce a seam to ConnectivityManager and TelephonyManager

This change abstracts access to ConnectivityManager and
TelephonyManager behind methods on SystemFacade, moving the code from
Helpers into RealSystemFacade and adding fake implementations to
FakeSystemFacade. This facilitates new connectivity tests.

Change-Id: Id6c6b861e1d4ca45b3c1572bfb8ae0aa26af756b
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
5224c6fbf20b4803a580ef449ab87ebfbbfedb78 14-Jul-2010 Steve Howard <showard@google.com> Support for custom HTTP headers on download requests

Provider changes:
* new many-to-one DB table holding headers for each download. since
there was no real migration logic in DownloadProvider, I implemented
some.
* DownloadProvider.insert() reads request headers out of the
ContentValues and puts them into the new table
* DownloadProvider.query() supports a new URI form,
download/#/headers, to fetch the headers associated with a download
* DownloadProvider.delete() removes request headers from this table

Service changes:
* made DownloadInfo store request headers upon initialization. While
I was at it, I refactored the initialization logic into DownloadInfo
to get rid of the massive 24-parameter constructor. The right next
step would be to move the update logic into DownloadInfo and merge
it with the initialization logic; however, I realized that headers
don't need to be updatable, and in the future, we won't need the
update logic at all, so i didn't bother touching the update code.
* made DownloadThread read headers from the DownloadInfo and include
them in the request; merged the custom Cookie and Referer logic into
this logic

Also added a couple new test cases for this stuff.

Change-Id: I421ce1f0a694e815f2e099795182393650fcb3ff
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
23357198c440e6872d3aef3e608295db7f8273bc 23-Jun-2010 Steve Howard <showard@google.com> Stub out the system clock in the download manager, add tests

Introduce SystemFacade, an interface that allows us to stub out the
system clock for testing the download manager. This allows us to test
retrying a failed download without having the test wait 60 seconds.
This interface can include other dependencies in the future as well.

I've also used this to add tests for 503 (retry-after) and 301
(redirect), and I've added a test for download to the cache partition.

Other changes:
* made MockWebServer capable of checking + rethrowing exceptions from child threads
* refactoring + cleanup of DownloadManagerFunctionalTest
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
581abbbbeba49e64219e5f11f8a8474760a2f902 22-Jan-2010 Leon Scroggins <scroggo@google.com> Revert "Download files even if there is no activity to launch them."

This reverts commit 0f1aae327a9e4c68044d767e9bafbac747b6d985.

I misunderstood the bug. We do not want to be able to download
files for which there is currently no Activity to launch them.
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
0f1aae327a9e4c68044d767e9bafbac747b6d985 21-Jan-2010 Leon Scroggins <scroggo@google.com> Download files even if there is no activity to launch them.

Fixes http://b/issue?id=2367247
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
7dd92fa94df0a13b4592ee636b7aa2b605f6b473 08-Jan-2010 Jean-Baptiste Queru <jbq@google.com> Use the private legacy API

The public API is getting deeply reworked for forward compatibility,
but since the Download Manager and the Browser need to continue using
the old API, a separate copy is being kept on the side.

Bug: 2245521

Change-Id: I85eff6ba9efc68600aa80e8dffa6720b0f2ed155
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
2061c03400a8e23cfeee5394b7e71db2440a48ed 24-Sep-2009 Jean-Baptiste Queru <jbq@google.com> Remove unnecessary logging

Also tweak some slightly inaccurate logging, and add a note
about a potential bug.

BUG=2055624
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
764844ebbb788cdde731abbacc89b9afcab8b49f 23-Sep-2009 Jean-Baptiste Queru <jbq@google.com> Log the service being launched

BUG=2055624
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
e2607d88081f02a418ff5d5067f5327d513e00a1 23-Sep-2009 Jean-Baptiste Queru <jbq@google.com> Add a bit more logging to track down network state issues.

BUG=2055624
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
977d38d21876fbc39598ff0a966a27db92ee1d59 18-Mar-2009 Jean-Baptiste Queru <jbq@google.com> Merge commit 'remotes/korg/cupcake' into merge

Conflicts:
docs/index.html
src/com/android/providers/downloads/DownloadProvider.java
src/com/android/providers/downloads/DownloadService.java
2dd83ce992eaaf3d44c32bc7468b47e3db014027 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
1edb39f280d23b3a87db45b63c2f26850d68eafe 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
c2fb15f7689a10c7fe3b6c1f1ed0ce1f5a95ba9b 19-Feb-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //branches/cupcake/...@132276
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
59910f4a9ce953ea74c8db759448f227c96796b3 20-Jan-2009 Jean-Baptiste Queru <jbq@google.com> Use the new download manager APIs introduced in change 7400
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
c6f5aad265cfc36a64cd2bdb5adf3cc9736bbd80 20-Jan-2009 Jean-Baptiste Queru <jbq@google.com> Match the official code style guide.

This fixes a number of style violations that weren't caught by automated
tools and brings those files closer to compliance with the official style
guide for this language.
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
1fbad9cfa532f13f6cf03f542febf2e4689edec5 18-Dec-2008 The Android Open Source Project <initial-contribution@android.com> Code drop from //branches/cupcake/...@124589
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java
57f55b3cb4f7e4136cde8d1ea12c1e70ec903362 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadService.java