History log of /packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
3a4a3e7cd5a379e7e757177826ba935f000eb455 25-Jun-2016 Jeff Sharkey <jsharkey@android.com> Make scanning decisions based on latest data.

When deciding to kick off a media scan of a newly-downloaded file,
use the latest values from InfoDelta, instead of stale values from
the last database read, which may lead us to skip the scan.

Bug: 29234780
Change-Id: I7ffbcdd1edb9965999b7f5f100f57a9c2933f3a5
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
b5ca499c7417fc5954b6914d6d52e6e2c02ce7d8 22-Jun-2016 Jeff Sharkey <jsharkey@android.com> Re-schedule downloads queued for unmetered.

When a download is stopped due to a metered network, we should
reschedule the job just like any other network failure. If a
download requires an unmetered network, treat WAITING_FOR_NETWORK as
QUEUED_FOR_WIFI so we show a meaningful notification.

Bug: 29440531
Change-Id: I31e6535c575fd32e2982ef840ae501acf1db3927
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
b3597b9d2fdde31bb0a8af821e3da3ca786e277b 28-Apr-2016 Jeff Sharkey <jsharkey@android.com> Visible downloads should run while blocked/dozing.

Downloads with visible notifications should behave as if the
requesting app was running a foreground service. The easiest way
to implement this for now is to ignore any BLOCKED network status
and use the new setWillBeForeground() API so job scheduling ignores
any active blocked/dozing status.

Bug: 26571724
Change-Id: I8ea2b2a7cdb5f469adc11b4d897ff55bd8a9db9a
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.java
ed30deae5fe5b9de142b44933001c9b098c47712 13-Jul-2015 Jeff Sharkey <jsharkey@android.com> Relax permissions on package-specific paths.

Normally apps must hold the WRITE_EXTERNAL_STORAGE permission in
order to use DownloadManager. However, now that the platform has
relaxed permissions on package-specific directories, we relax the
DownloadManager check in a similar way. This also opens up using
DownloadManager to save files on secondary external storage devices.

Fix bug so that we now check the relevant volume state when thinking
about resuming a download.

Bug: 22135060
Change-Id: If439340ea48789ea167f49709b5b69a4f0883150
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
495edec1d9f7659923c71b009db66c1bd4782034 05-Aug-2014 Jeff Sharkey <jsharkey@android.com> Scan after writing download files.

Kicks off media scanner after files are written, usually through a
DocumentsProvider.

Bug: 13557203
Change-Id: I4e29b778b4e19a217f60c1e415c4d814724752d3
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.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/DownloadInfo.java
2eb144d8effed2dbb067957c5b25e735233bca89 19-Feb-2013 Jeff Sharkey <jsharkey@android.com> Retries shouldn't backoff when network changes.

When a download fails due to a network change, treat it as waiting
for network, instead of subjecting it to full retry backoff.

Change-Id: Ifdae62fd7c2baad7422f68e09da94740b5f513d0
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.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/DownloadInfo.java
12f5dc46aaa8e28cabfbe25d55f0af68f24ab306 18-Jan-2013 Jeff Sharkey <jsharkey@android.com> Better handling of retryable errors.

Now the final errors are always thrown, and the outer code decides
how to handle them as retries. Also clean up method signatures.

Bug: 8022478
Change-Id: I4e7e43be793294ab837370df521e7c381e0bb6c3
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
97862429de71477b5c4488faa911a2256b90089b 13-Jan-2013 Jeff Sharkey <jsharkey@android.com> Move network state to enums for type safety.

Change-Id: Ib8ea24fc58a866f8a5626cdd20e5891eb0a2bbeb
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
0de55602ec6d350548248feddc68c91b29326eff 24-Dec-2012 Jeff Sharkey <jsharkey@android.com> Simplify download flow control, handle redirects.

Move redirection handling into a single loop, and handle each HTTP
response code inline to make flow control easier to reason about.

Fix race condition in tests by waiting for first status update.

Bug: 7887226
Change-Id: Id4bfd182941baad4cd0bb702376c4beeb7275bb2
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.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/DownloadInfo.java
2fa007ef678b2283d47d007aa3dc91af683cc52c 25-Oct-2012 Jeff Sharkey <jsharkey@android.com> Better sanity checking for finished downloads.

Downloads in the RUNNING state are considered ready to start so that
downloads are correctly resumed when the process crashes. However,
this causes a race condition while UpdateThread is processing a
Cursor when a DownloadThread finishes.

With this change, DownloadThread now skips requests for downloads
already marked as finished. Apps listening for the DOWNLOAD_COMPLETE
broadcast will no longer see data mutated by the second thread, and
will not see the broadcast duplicated.

Bug: 6948938, 6970458, 6818900
Change-Id: I35deac3cedbfe7f50091fab5818d85594dba558c
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
b92aa3a88dd25a798bbedc860d9b29aef42bbb0f 03-Oct-2012 Jeff Sharkey <jsharkey@android.com> Handle not fully connected networks.

When checking network status, treat non-connected networks as
disconnected. This handles cases like captive portal checks, and
slow DHCP servers.

Bug: 7264340
Change-Id: I0b466cee5d5cb73037f3fb209c583711b8f9eefd
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
61dc320aa883a2fcf68d44ef0bbe4cd7c51a7655 08-Feb-2012 HÃ¥kan3 Johansson <hakan3.johansson@sonyericsson.com> Adds missing Bluetooth as network type.

The network connection type for Bluetooth is added so
that it is possible to use Bluetooth as Hotspot during
download from the Internet.

Change-Id: Ic32b083068d8316a41f2c31a3575a28163f6c7f3
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
c1df0651e86ab6d0918cfac86ff54d3fb3781a69 21-May-2012 Jean-Baptiste Queru <jbq@google.com> am 0acd13fe: Merge "avoid repetition of retrying download"

* commit '0acd13fed2f4d0857ce89565fe94674c09b1e844':
avoid repetition of retrying download
0acd13fed2f4d0857ce89565fe94674c09b1e844 21-May-2012 Jean-Baptiste Queru <jbq@google.com> Merge "avoid repetition of retrying download"
a7ae77fdae69bcc6d6609d4639fed5d96e55eeaa 17-Apr-2012 Jeff Sharkey <jsharkey@android.com> Add and enforce ALLOW_METERED column.

Include flag with each download to indicate if its allowed to proceed
over metered networks. Downloads are left in WAITING_FOR_NETWORK
state, similar to how ALLOWED_NETWORK_TYPES is handled.

Also keep blocked downloads in WAITING_FOR_NETWORK state instead
of marking them as failed.

Bug: 3001465, 5734560
Change-Id: I80bb9aa9bd25ddf6f7a2472db344b6ba6878bd74
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.java
579be0d0d0de6af307ee94af07720a568ed2e7d1 14-Feb-2012 Hideki Hayami <hayami.hideki@sharp.co.jp> avoid repetition of retrying download

If isReadyToStart returns 'true' for STATUS_INSUFFICIENT_SPACE_ERROR,
DownloadProvider retries downloading after it gets requests from
browser to download contents. The retrying loop won't stop until
its completion (recovering from space error), or user stops
downloading. This retry loop impacts to network traffic, battery
consumption and packet charge. So, change this method to return
'false' for the error in order to stop the loop.

Change-Id: Ia3466db60d86c5900842c7c28d294898ae3ff2bc
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
f720bc684b1a8332eb4d5f8d25c5feaf7eb54433 05-Jan-2012 Jeff Sharkey <jsharkey@android.com> Allow downloads when no network restriction set.

Fixes bug where DownloadManager would block downloads on WiMAX,
bluetooth, and ethernet networks, even when no network restrictions
had been set.

Bug: 5689335
Change-Id: I6d1bb78cbccb3c5eb1fce40a13b0689be0c3fa13
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
961024389b3782936a40a7d090d670290bb66c3c 15-Jun-2011 Jeff Sharkey <jsharkey@android.com> Teach DownloadManager about network policy.

Now network access is determined by using getActiveNetworkInfoForUid()
which uses BLOCKED to indicate that network should be rejected for
the requesting UID. While download in progress, watch for any policy
changes that should trigger pause.

Also check NetworkInfo.isConnected() for correctness.

Change-Id: I1efa79823f15ecc3fa088a6719da1b770c64b255
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
9356a4a9b1b1e5be9a3bd639cd89bb30aa6a5ae5 03-Jun-2011 Gloria Wang <gwang@google.com> Merge "Download provider change for DRM Forward Lock plugin: to convert .dm files to .fl files during downloading For bug 3188041"
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/DownloadInfo.java
0a17c2a28738d6ecb274def0e8e54f556d89f5f3 16-Feb-2011 Gloria Wang <gwang@google.com> Download provider change for DRM Forward Lock plugin:
to convert .dm files to .fl files during downloading
For bug 3188041

Change-Id: I882b851664432fba3e57dc25a6be827b48006e69
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.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/DownloadInfo.java
7806290088fbd6f802288021ec551ddd9469892a 04-Feb-2011 Vasu Nori <vnori@google.com> am 6e9abd8e: am d119d3cb: Revert "bug:3414192 if otaupdate column is set, don\'t check mobile download limits"

* commit '6e9abd8e04c4aaafb8493a25efc34f4dd4fa6013':
Revert "bug:3414192 if otaupdate column is set, don't check mobile download limits"
580871b3950761a39a69e3cb4db9fbdfb96f3917 04-Feb-2011 Vasu Nori <vnori@google.com> am 49663f1f: am f20af912: Revert "Merge "bug:3341145 if ignore_size_limits flag set, validate caller\'s perms" into honeycomb"

* commit '49663f1ffe58a546fb0d2ab84898843ef5e89eb5':
Revert "Merge "bug:3341145 if ignore_size_limits flag set, validate caller's perms" into honeycomb"
d119d3cbae976e791c9093cc5bea91ab9145a993 03-Feb-2011 Vasu Nori <vnori@google.com> Revert "bug:3414192 if otaupdate column is set, don't check mobile download limits"

This reverts commit ea245800c69d6bc10dc2680e6a242f59e9cb49b6.
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
f20af91262fecce05928167123c8d335b4cfd33d 03-Feb-2011 Vasu Nori <vnori@google.com> Revert "Merge "bug:3341145 if ignore_size_limits flag set, validate caller's perms" into honeycomb"

This reverts commit 3e7bb1c5d7e7d1a013df959c1a6947b33df0a0fd, reversing
changes made to b2085f61b37ad4a70c799012f25ff62a38173f68.
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
ed4870094f53bcd19c0542400389a1f56636ce5a 03-Feb-2011 Vasu Nori <vnori@google.com> resolved conflicts for merge of 43d649e9 to master

Change-Id: I27a615509269f256cf66de2dd217d8c4667caab4
86c04344cd871e0a443ab3dee86f8f7994f6d429 03-Feb-2011 Vasu Nori <vnori@google.com> bug:3341145 if ignore_size_limits flag set, validate caller's perms

and then of course ignore the mobile network size limits

Change-Id: I6765be9255187f93bd51acecc19a15db4f324204
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
93842036405d99a1c26471d5d06fe3f1b5048b2d 02-Feb-2011 Vasu Nori <vnori@google.com> am 8db8fba2: am ea245800: bug:3414192 if otaupdate column is set, don\'t check mobile download limits

* commit '8db8fba215a981edd24ad1f7118d3397be0114d2':
bug:3414192 if otaupdate column is set, don't check mobile download limits
ea245800c69d6bc10dc2680e6a242f59e9cb49b6 02-Feb-2011 Vasu Nori <vnori@google.com> bug:3414192 if otaupdate column is set, don't check mobile download limits

this allows OTA update to work without being subject to download limits
on mobile networks.

Change-Id: I92c60ba3ecbde615bd93778b391a5fe067dbd2fe
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.java
3022abb31ad80a5e4b263ac078709e91b97bf226 16-Jan-2011 Vasu Nori <vnori@google.com> manual merge of GB change Change-Id: I1acf2fb9491d24f5e109206a91dda3eea429e447

Change-Id: Ibaf889d78fc99a32038a77671036fc6a5068580f
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.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/DownloadInfo.java
1dc416983a4638a250b67b11564466088cfa41f6 02-Dec-2010 Vasu Nori <vnori@google.com> bug:3144642 fix is to treat empty strings as nulls

in the database, sometimes _data column in downloads is set to null
and sometimes to empty string. this is inconsistent
and causes bugs such as bug:3144642
aThis bug is caused by line# 793 in DownloadThread.
state.mFileName is null sometimes and empty string sometimes - because
the correspodning field is set inconsistentlt in downloads.db
_data column.

Change-Id: Ifea1544737023008eff44aef9acd976902a0c143
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
3ca67748bc92eac89f731796c5597ff1fbe9217b 04-Nov-2010 Vasu Nori <vnori@google.com> changes to support CL: I1f5dd734e394db0056579a3a0c26862fee27981e

1. if an application designates a downloaded file to be mediascanner
scannable or not, store that fact in database.
2. use the above to determine whether a file shoudl be mediascanned or not
in DownloadService
3. implement code to return mimetype for the new Uri "/public_downloads"
introduced in CL: I1f5dd734e394db0056579a3a0c26862fee27981e

Change-Id: I5c062ad6d1b58306044cee49ff3827e908d27fd9
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
971525cbe68f83a4f05cfe942f774486702947a7 03-Nov-2010 Vasu Nori <vnori@google.com> downloadmanager public API usage can cause non-scanning of media files

bug:3162073
Change-Id: I13b80fedd7658c8574f33b43b74b5aa28a2895bc
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.java
26604ffc248081b8014ff7260536d18b43cb0de9 01-Oct-2010 Steve Howard <showard@google.com> Seriously improve error reporting in DownloadThread.

My old error reporting strategy for DownloadThread was to log the
stack trace for the exception, so we'd know exactly what conditions
caused the StopRequest. hackbod suggested that we shouldn't log
tracebacks as they clutter the log. Instead, we should just always
include a little string tag explaining why the request is being
stopped -- this is more concise and more useful to developers.

There are three main changes here to acheive this goal:
* make StopRequest require a short, log-friendly error message upon
construction, and add such a message to all construction sites
* make a similar change to GenerateSaveFileError, so that the variety
of errors that originate with Helpers.generateSaveFile() get
similarly fine-grained and concise error reporting
* make network usable checking code return a distinct error code for
each distinct negative condition, and add a utility to return a
log-friendly error message for each such code.

Finally, I cleaned up some of the ways errors/exceptions are handled
in the process.

Change-Id: Ie70cbf3f2960e260e97f8449258e25218d0f900f
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.java
14961f94d762e733a733e3268fca1074d8da5f8c 28-Sep-2010 Steve Howard <showard@google.com> Moved DownloadManager to android.app (DO NOT MERGE)

I'll merge this manually, as there's some additional master-only code
that will be to be simultaneously changed.

Change-Id: Ifdb1740f32e228bc07f266585737b98a7b794685
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
ebb555c0687061993dd6a22d15f6aab2437ee8c5 23-Sep-2010 Steve Howard <showard@google.com> Support multi-valued HTTP headers, handle new API changes

* backend support for multiple values for the same HTTP headers, for
corresponding API changes

* other minor changes in response to DownloadManager API changes

Change-Id: I7c595e94a60ed7afaca6cc3fb4c05aaeeff20c2a
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
d319729622da1893e895f2e35f41d01ecdca3705 18-Sep-2010 Steve Howard <showard@google.com> Implement dialogs for wifi required + recommended limits.

This change extends the original work to add a size limit over which
wifi is required to download a file.

First, this change adds a second size limit, over which wifi is
recommended but not required. The user has the option to bypass this
limit.

Second, this change implements dialogs shown to the user when either
limit is exceeded. These dialogs are shown by the background download
manager service when a download is started and found to be over the
limit (and wifi is not connected).

I'm including one small fix to the unit tests needed from the previous
change.

Change-Id: Ia0f0acaa7b0d00e98355925c3446c0472048df10
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.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/DownloadInfo.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/DownloadInfo.java
1df61f0e1a275961ad9762ffc1d141adb91870e0 19-Aug-2010 Steve Howard <showard@google.com> Avoid endless restarts when waiting for connectivity.

Adding an extra check for usable network connectivity to avoid an endless
restart-pause loop while waiting for usable connectivity.

Change-Id: If4da9ad222993b5479ada658508f445d10a42013
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
adb6887d3270d180c94eaf90878d5b67d74a8f28 31-Jul-2010 Steve Howard <showard@google.com> Clean up error codes returned by download manager.

This set of changes cleans up the error codes returned by the download
manager in various failure cases, aiming for improved consistency.
Error codes are part of the public API so it's important to get this
right now.

The main changes here are:
* Refactoring the flow of error status information throughout
DownloadThread to make it more explicit, by having StopRequest
accept a status code in its constructor and eliminating
State.mFinaStatus.
* Eliminating the use of valid HTTP 4xx statuses when those statuses
weren't actually returned by the server. Now, if the returned error
code is a valid HTTP status code, that means it was returned by the
server. These cases have been replaced with more sensible
artificial error codes, including a new ERROR_CANNOT_RESUME when an
interrupted download can't be resumed.
* Improvements to some of the error handling code paths -- ensuring we
don't clear the cache for external downloads, ensuring we don't fail
with CANNOT_RESUME when the download hasn't actually started yet,
removing the restriction on acceptable mime types for public API
downloads.

Change-Id: I0d825845fe0fe7ed5df74bad26e8d34ac0d1cc4e
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java
0d4f9f105c3a31475a36e9a1edfa868c66ff455f 28-Jul-2010 Steve Howard <showard@google.com> Get wifi limit from secure settings.

Change-Id: I750654c28cb3d9f9aa67bd56e4d8d770dbfde4b4
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.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/DownloadInfo.java
b5629da794cb3c1ca1970d206343743b165b9644 16-Jul-2010 Steve Howard <showard@google.com> Major refactoring of DownloadThread.run().

Motivation: I need to fix the handling of 302s, so that after a
disconnect, subsequent retries will use the original URI, not the
redirected one. Rather than store extra information in the DB, I'd
like to just keep the redirected URI in memory and make the redirected
request within the same DownloadThread. This involves working with
the large-scale structure of DownloadThread.run(). Since run() was a
~700 line method, I didn't feel comfortable making such changes.

So this change refactors run() into a ~80 line method which calls into
a collection of ~20 other short methods. The state previously kept in
local variables has been pulled into a couple of state-only inner
classes. The error-handling control flow, formerly handled by "break
http_request_loop" statements, is now handled by throwing a
"StopRequest" exception. The remaining structure of run() has been
simplified -- the outermost for loop, for example, could never
actually repeat and has been removed for now. Some other bits of code
have been cleaned up a bit, but the functionality has not been
modified.

There are many good next steps to this refactoring. Besides various
other cleanup bits, a major improvement would be to consolidate the
State/InnerState classes, move some functionality to this new class
(there are many functions of the form "void foo(State)" which would be
good candidates), and promote it to a top-level class. But I want to
take things one step at a time, and I think what I've got here is a
major improvement and should be enough to allow me to safely implement
the changes to redirection handling.

In the process of doing this refactoring I added many test cases to
PublicApiFunctionalTest to exercise some of the pieces of code I was
moving around. I also moved some test cases from
DownloadManagerFunctionalTest. Over time I'd like to move everything
over to use the PublicApiFunctionalTest approach, and then I may break
that into some smaller suites.

Other minor changes:
* use longs instead of ints to track file sizes, as these may be
getting quite large in the future
* provide a default DB value of -1 for COLUMN_TOTAL_BYTES, as this
simplifies some logic in DownloadThread
* small extensions to MockResponse to faciliate new test cases

Change-Id: If7862349296ad79ff6cdc97e554ad14c01ce1f49
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.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/DownloadInfo.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/DownloadInfo.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/DownloadInfo.java
4a977a52c3eb3ac08b94b81aef72fb618be39f81 24-Sep-2009 Jean-Baptiste Queru <jbq@google.com> Re-use the same random value to compute a download's restart time.

The restart time is used multiple times during the same pass,
and it needs to be consistent across calls. Otherwise, it's
possible for a download to not be restarted immediately and
to not be scheduled for a future restart.

BUG=2055624
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.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/DownloadInfo.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/DownloadInfo.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/DownloadInfo.java
57f55b3cb4f7e4136cde8d1ea12c1e70ec903362 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution
/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadInfo.java