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
|