summaryrefslogtreecommitdiffstats
path: root/src/com/android/providers/downloads/DownloadInfo.java
Commit message (Collapse)AuthorAgeFilesLines
* Scan after writing download files.Jeff Sharkey2014-08-051-1/+1
| | | | | | | | Kicks off media scanner after files are written, usually through a DocumentsProvider. Bug: 13557203 Change-Id: I4e29b778b4e19a217f60c1e415c4d814724752d3
* Many improvements to download storage management.Jeff Sharkey2014-02-061-33/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Reduce logging, dump stacks before wtf().Jeff Sharkey2013-03-251-4/+7
| | | | | | | | | 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
* Retries shouldn't backoff when network changes.Jeff Sharkey2013-02-191-1/+0
| | | | | | | 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
* Redesign of DownloadManager update loop.Jeff Sharkey2013-02-121-15/+35
| | | | | | | | | | | | | | | | | | 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
* Cleaner thread management, less global state.Jeff Sharkey2013-01-281-30/+40
| | | | | | | | | | | | 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
* Better handling of retryable errors.Jeff Sharkey2013-01-171-1/+1
| | | | | | | | 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
* Move network state to enums for type safety.Jeff Sharkey2013-01-121-81/+57
| | | | Change-Id: Ib8ea24fc58a866f8a5626cdd20e5891eb0a2bbeb
* Simplify download flow control, handle redirects.Jeff Sharkey2013-01-091-0/+3
| | | | | | | | | | 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
* Clean up DownloadManager threading tests.Jeff Sharkey2013-01-081-3/+2
| | | | | | | | | | | 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
* Remove singleton StorageManager.Jeff Sharkey2013-01-051-6/+10
| | | | | | | Now DownloadService creates and owns the lifecycle of its own StorageManager instance. Change-Id: I8f6bedc02f1dbe610a8e6a25d55383a12716d344
* Better sanity checking for finished downloads.Jeff Sharkey2012-10-241-1/+20
| | | | | | | | | | | | | | | 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
* Handle not fully connected networks.Jeff Sharkey2012-10-031-1/+1
| | | | | | | | | 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
* Adds missing Bluetooth as network type.Håkan3 Johansson2012-07-101-0/+3
| | | | | | | | 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
* am 0acd13fe: Merge "avoid repetition of retrying download"Jean-Baptiste Queru2012-05-211-5/+2
|\ | | | | | | | | * commit '0acd13fed2f4d0857ce89565fe94674c09b1e844': avoid repetition of retrying download
| * Merge "avoid repetition of retrying download"Jean-Baptiste Queru2012-05-211-5/+2
| |\
| | * avoid repetition of retrying downloadHideki Hayami2012-02-141-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Add and enforce ALLOW_METERED column.Jeff Sharkey2012-04-171-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Locking around downloads, and more dump info.Jeff Sharkey2012-04-131-23/+41
|/ / | | | | | | | | Bug: 4997552 Change-Id: I3c612acb5145a7638c9345a376a99958851a0891
* / Allow downloads when no network restriction set.Jeff Sharkey2012-01-051-2/+3
|/ | | | | | | | | 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
* Teach DownloadManager about network policy.Jeff Sharkey2011-06-171-3/+16
| | | | | | | | | | | 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
* Merge "Download provider change for DRM Forward Lock plugin: to convert .dm ↵Gloria Wang2011-06-031-3/+1
|\ | | | | | | files to .fl files during downloading For bug 3188041"
| * Download provider change for DRM Forward Lock plugin:Gloria Wang2011-04-191-3/+1
| | | | | | | | | | | | | | to convert .dm files to .fl files during downloading For bug 3188041 Change-Id: I882b851664432fba3e57dc25a6be827b48006e69
* | Output DownloadInfo state in Service.dump()Jeff Sharkey2011-04-281-26/+25
|/ | | | | Bug: 3136228 Change-Id: I77c4f998c9718c7630800dec152779ff59186187
* (master) bug:3204324 allow no more than certain number of concurrent downloadsVasu Nori2011-03-101-10/+8
| | | | Change-Id: Ibbce0782fcf7649209d6f56be240209cebd9045b
* bug:3435895 listen to media_mounted broadcast intentVasu Nori2011-02-081-0/+10
| | | | | | and retry downloads that failed due to the error "sdcard media not mounted" Change-Id: Id181b8167d331214f72679c85f18cc8b9b969e40
* am 6e9abd8e: am d119d3cb: Revert "bug:3414192 if otaupdate column is set, ↵Vasu Nori2011-02-031-6/+0
|\ | | | | | | | | | | | | don\'t check mobile download limits" * commit '6e9abd8e04c4aaafb8493a25efc34f4dd4fa6013': Revert "bug:3414192 if otaupdate column is set, don't check mobile download limits"
| * Revert "bug:3414192 if otaupdate column is set, don't check mobile download ↵Vasu Nori2011-02-031-6/+0
| | | | | | | | | | | | limits" This reverts commit ea245800c69d6bc10dc2680e6a242f59e9cb49b6.
* | am 49663f1f: am f20af912: Revert "Merge "bug:3341145 if ignore_size_limits ↵Vasu Nori2011-02-031-1/+1
|\| | | | | | | | | | | | | 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"
| * Revert "Merge "bug:3341145 if ignore_size_limits flag set, validate caller's ↵Vasu Nori2011-02-031-1/+1
| | | | | | | | | | | | | | perms" into honeycomb" This reverts commit 3e7bb1c5d7e7d1a013df959c1a6947b33df0a0fd, reversing changes made to b2085f61b37ad4a70c799012f25ff62a38173f68.
* | resolved conflicts for merge of 43d649e9 to masterVasu Nori2011-02-021-1/+1
|\| | | | | | | Change-Id: I27a615509269f256cf66de2dd217d8c4667caab4
| * bug:3341145 if ignore_size_limits flag set, validate caller's permsVasu Nori2011-02-021-1/+1
| | | | | | | | | | | | and then of course ignore the mobile network size limits Change-Id: I6765be9255187f93bd51acecc19a15db4f324204
* | am 8db8fba2: am ea245800: bug:3414192 if otaupdate column is set, don\'t ↵Vasu Nori2011-02-011-0/+6
|\| | | | | | | | | | | | | check mobile download limits * commit '8db8fba215a981edd24ad1f7118d3397be0114d2': bug:3414192 if otaupdate column is set, don't check mobile download limits
| * bug:3414192 if otaupdate column is set, don't check mobile download limitsVasu Nori2011-02-011-0/+6
| | | | | | | | | | | | | | this allows OTA update to work without being subject to download limits on mobile networks. Change-Id: I92c60ba3ecbde615bd93778b391a5fe067dbd2fe
* | bug:3048327 (master) ability to add completed download to dnload mgrVasu Nori2011-01-211-4/+5
|/ | | | Change-Id: Ib9d4df107787191a5349365908cbe096b67770dc
* manual merge of GB change Change-Id: I1acf2fb9491d24f5e109206a91dda3eea429e447Vasu Nori2011-01-161-3/+0
| | | | Change-Id: Ibaf889d78fc99a32038a77671036fc6a5068580f
* bug:3286430 set quota on downloads data dirVasu Nori2010-12-231-3/+3
| | | | | | | | | | 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
* Download dir: /data/data/com.android.providers.downloads/cache NOT /cacheVasu Nori2010-12-141-0/+1
| | | | | | | | | | 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
* bug:3144642 fix is to treat empty strings as nullsVasu Nori2010-12-021-46/+18
| | | | | | | | | | | | 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
* changes to support CL: I1f5dd734e394db0056579a3a0c26862fee27981eVasu Nori2010-11-041-1/+1
| | | | | | | | | | | 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
* downloadmanager public API usage can cause non-scanning of media filesVasu Nori2010-11-031-1/+2
| | | | | bug:3162073 Change-Id: I13b80fedd7658c8574f33b43b74b5aa28a2895bc
* bug:3069735 in Download UI app, handle deletes correctlyVasu Nori2010-10-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Seriously improve error reporting in DownloadThread.Steve Howard2010-09-301-5/+41
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Improve how the download manager reports paused statuses.Steve Howard2010-09-291-66/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Moved DownloadManager to android.app (DO NOT MERGE)Steve Howard2010-09-271-1/+1
| | | | | | | I'll merge this manually, as there's some additional master-only code that will be to be simultaneously changed. Change-Id: Ifdb1740f32e228bc07f266585737b98a7b794685
* Support multi-valued HTTP headers, handle new API changesSteve Howard2010-09-221-12/+14
| | | | | | | | | * 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
* Implement dialogs for wifi required + recommended limits.Steve Howard2010-09-211-22/+70
| | | | | | | | | | | | | | | | | | | 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
* Fix notification bugs, cleanup DownloadService + DownloadReceiverSteve Howard2010-09-201-76/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* New URI structure with "my_downloads" and "all_downloads"Steve Howard2010-09-141-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add UI message when queued for wifi due to size.Steve Howard2010-08-201-1/+12
| | | | | | | | | | | | | | | | 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 08:44:52 +0000