summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'gingerbread' of ↵cm-7.0.3cm-7.0.2.1cm-7.0.1cm-7.0.0Steve Kondik2011-02-283-26/+25
|\ | | | | | | git://android.git.kernel.org/platform/packages/providers/DownloadProvider into 233-merge
| * Merge "(GB/GBMR) (do not merge) delete file from disk when deleting from db" ↵Vasu Nori2011-01-161-16/+18
| |\ | | | | | | | | | into gingerbread
| | * (GB/GBMR) (do not merge) delete file from disk when deleting from dbVasu Nori2010-12-031-16/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bug:3175143 sometimes mediaprovider doesn't delete the file from disk when it is deleted from its db. for example, audio files, pdf files. DownloadManager/DownloadApp should delete the file when it is deleted from downloads db. DO NOT MERGE this is esentially porting HC fix from DownloadService.java to GB Change-Id: I70f3a7ad968f82ccba00d664e9a2993d75a18d15
| * | (GB MR) bug:3351783 don't store redirectcount in dbVasu Nori2011-01-162-9/+5
| |/ | | | | | | | | | | | | | | | | | | | | | | redirectcount shouldn't be stored in the db. say, you are downloading a large app and there are redirects involved inthe download. if network connectivity changes during download, then download is paused and resumed once connectivy is back on. when the download is resumed, it should start with redirectcount of 0 instead of redirectcount from the previous download session. Change-Id: I1acf2fb9491d24f5e109206a91dda3eea429e447
| * downloads broken by Change-Id: I115b3ba6cfe0262269dbbc4c336b9e1d63c618e4Vasu Nori2010-12-031-1/+1
| | | | | | | | | | | | big typo in that CL broke the downloading functionality. Change-Id: If7dc0f86ea7a3c4394603416ca0fc33847f10fa7
| * (GB MR) bug:3144642 temporary small fix in GB MR and real fix in HCVasu Nori2010-12-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Real fix is in Change-Id: Ifea1544737023008eff44aef9acd976902a0c143 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. This 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. in GB MR, apply a bandaid because real fix could be too risky for GB. Change-Id: I115b3ba6cfe0262269dbbc4c336b9e1d63c618e4
| * Don't filter by UID for apps with ACCESS_ALL_DOWNLOADSKenny Root2010-12-011-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Old platform behavior of DownloadProvider would allow anyone with special access to access all the downloads. New behavior is to return /my_downloads/ on an .insert() call. For things that aren't using the new API where DownloadInfo.getAllDownloadsUri() is accessible, make any application with ACCESS_ALL_DOWNLOADS permission bypass the calling UID check for /my_downloads/ Bug: 3242328 Change-Id: I536fde4525dd74066879f7c7da7fa609ff344645
* | Added support for downloading files with unicode charactersAndreas Sandblad2010-12-191-2/+52
| | | | | | | | | | | | | | | | | | | | | | | | Currently only certain ASCII characters are allowed in a filename, all other characters are replaced with an underscore. This gives bad usability for foreign languages (e.g. japanese). This fix replaces the current regexp with a method which replaces only those characters unsafe to be used on VFAT filesystems (should work on most other filesystems as well). Change-Id: I114d47b4b35f28490e6b12493138355532fda499 Signed-off-by: Eddie Ringle <eddie.ringle@gmail.com>
* | Merge "Don't try to purge the dalvik-cache directory on /cache." into ↵Keyan Mobli2010-12-192-4/+7
|\ \ | | | | | | | | | gingerbread
| * | Don't try to purge the dalvik-cache directory on /cache.Steve Kondik2010-12-192-4/+7
| | |
* | | Download any file typeEddie Ringle2010-12-191-37/+1
|/ / | | | | | | | | Change-Id: Ib1712eb3c4d0335e0822be53f9c6fd7b6ac9585e Signed-off-by: Eddie Ringle <eddie.ringle@gmail.com>
* / Don't filter by UID for apps with ACCESS_ALL_DOWNLOADSKenny Root2010-12-091-1/+3
|/ | | | | | | | | | | | Old platform behavior of DownloadProvider would allow anyone with special access to access all the downloads. New behavior is to return /my_downloads/ on an .insert() call. For things that aren't using the new API where DownloadInfo.getAllDownloadsUri() is accessible, make any application with ACCESS_ALL_DOWNLOADS permission bypass the calling UID check for /my_downloads/ Bug: 3242328 Change-Id: I4d7dae75c528d2803d594c5d79d19865ef37ed30
* bug:3099994 NPE in DownloadManager when deleting non-media fileVasu Nori2010-10-152-54/+73
| | | | | | | | | | 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
* fix broken build bug:3095237Vasu Nori2010-10-131-3/+1
| | | | Change-Id: I7e1fe99cc482fc270894a820049275fc0c64233e
* bug:3069735 in Download UI app, handle deletes correctlyVasu Nori2010-10-133-18/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make DownloadProvider use parameterized queries.Steve Howard2010-10-081-39/+57
| | | | | | | | This avoids filling up the query cache unnecessary, but required some structural changes to ease the passing around of a selection along with its arguments. Change-Id: I724185763b94146d17573cab68f675c24e49634e
* Merge "Seriously improve error reporting in DownloadThread." into gingerbreadSteve Howard2010-10-014-198/+164
|\
| * Seriously improve error reporting in DownloadThread.Steve Howard2010-09-304-198/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Avoid NPE when checking file URI in DownloadProviderSteve Howard2010-09-301-1/+2
|/ | | | Change-Id: Ic937b05308cecce244725e25767a3a1310a8463d
* Improve how the download manager reports paused statuses.Steve Howard2010-09-294-96/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Merge "Trim the database & check spurious files off the UI thread." into ↵Brad Fitzpatrick2010-09-281-2/+3
|\ | | | | | | gingerbread
| * Trim the database & check spurious files off the UI thread.Brad Fitzpatrick2010-09-281-2/+3
| | | | | | | | Change-Id: I92180fc4344579b93361d5584243688a1cfdd091
* | Moved DownloadManager to android.app (DO NOT MERGE)Steve Howard2010-09-272-2/+2
|/ | | | | | | I'll merge this manually, as there's some additional master-only code that will be to be simultaneously changed. Change-Id: Ifdb1740f32e228bc07f266585737b98a7b794685
* Merge "DB migration to eliminate some null fields in old downloads" into ↵Steve Howard2010-09-231-1/+28
|\ | | | | | | gingerbread
| * DB migration to eliminate some null fields in old downloadsSteve Howard2010-09-221-1/+28
| | | | | | | | | | | | | | | | | | The DownloadProvider now ensures that current bytes, total bytes, title and description are never null in the DB. Some new code relies on this assumption for simplicity. That means we need to ensure this invariant is true for pre-existing downloads as well. Change-Id: Iea2289516d2636edf3394678ab08aa9cea31dc69
* | Support multi-valued HTTP headers, handle new API changesSteve Howard2010-09-222-15/+17
|/ | | | | | | | | * 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-216-25/+240
| | | | | | | | | | | | | | | | | | | 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
* Improve file error reporting + new detailed error messages in UISteve Howard2010-09-203-67/+103
| | | | | | | | | | | * support new error code for "destination file already exists" * improve error handling for various file error cases to return a more specific error code when appropriate * make UI support more detailed error messages for some cases * use Uri.getPath() instead of Uri.getSchemeSpecificPart() for file URIs Change-Id: Icb01d4d3b47c7776be3ddcd8347212e950cd023e
* Fix notification bugs, cleanup DownloadService + DownloadReceiverSteve Howard2010-09-207-641/+470
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Temporary fix to support old URIs for MarketSteve Howard2010-09-171-1/+6
| | | | | | | | Market has its own copies of the download manager URIs. This change bring back support for those so Market will keep working until they can properly update their code. Change-Id: I283ea65931085c0f083a182842d362c113427537
* New URI structure with "my_downloads" and "all_downloads"Steve Howard2010-09-146-231/+236
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Merge "Fix silly bug with completed notifications." into gingerbreadSteve Howard2010-09-121-2/+1
|\
| * Fix silly bug with completed notifications.Steve Howard2010-09-101-2/+1
| | | | | | | | | | | | | | | | | | This functionality isn't part of the public API, hence it lacks test coverage. Rather than adding tests, I'm inclined to leave it and hopefully we'll be able to migrate existing apps to the public API soon enough. Change-Id: I1210c6525dfb7cb12c1b8e35c04684060d3ad87e
* | Further work on the new downloads UI.Steve Howard2010-09-102-3/+35
|/ | | | | | | | | | | | | | | | | | | | * add support for downloads not visible in the UI * add support for restarting failed downloads and downloads for which the file is missing * add "clear selection" button to selection menu * fix DateSortedExpandableListAdapter to ensure the view refreshes properly anytime the underlying data changes * make DownloadList handle when a selected download gets deleted by another app * make DownloadList close a dialog for a pending download when the download starts * show a dialog when the user tries to open a download but the file is missing * display "<Unknown>" when no title is provided for a download * add a test case for DownloadManager.orderBy() (should've gone in the previous commit) Change-Id: Ibf3062e8228e7f2c1270be24d8d5527dfb064658
* Add UI message when queued for wifi due to size.Steve Howard2010-08-204-98/+88
| | | | | | | | | | | | | | | | 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
* Avoid endless restarts when waiting for connectivity.Steve Howard2010-08-181-1/+1
| | | | | | | Adding an extra check for usable network connectivity to avoid an endless restart-pause loop while waiting for usable connectivity. Change-Id: If4da9ad222993b5479ada658508f445d10a42013
* Fix and test handling of null/empty download fields.Steve Howard2010-08-181-2/+10
| | | | | | | Minor change to make title/description default to blank stings, and add test case covering all null/empty download fields. Change-Id: Id44344bc2e464f46589faed49c8f383a45a8d329
* Clean up error codes returned by download manager.Steve Howard2010-08-163-90/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Extend PublicApiAccessTest to exercise DownloadManager.Steve Howard2010-08-161-0/+8
| | | | | | | | | This change adds a new test case to PublicApiAccessTest to enqueue a request through DownloadManager, ensuring that the values constructed by DownloadManager fit within the allowed bounds. It also fixes a bug with allowing http header values exposed by the new test. Change-Id: I94fec57d7a41298ac42ddaab338516e6a60c4e75
* Make all public API downloads visible.Steve Howard2010-07-281-2/+9
| | | | | | | | | | | | | | | | This change makes all downloads through the public API visible by default. It removes the API that had allowed applications to control notifications while the download runs. This has been replaced with a hidden API, since such behavior is needed by SystemUpdater and Market (for self-updates). Additionally, the behavior is now protected by a new permission. I'm making this permission signatureOrSystem, and changing the non-purgeable permission to the same (it should've been that, I just didn't know). I'm also adding string descriptions to appease the translation folks. Change-Id: I192e8b19ff9b0e425257cef0db081c3d75996ea5
* Get wifi limit from secure settings.Steve Howard2010-07-283-4/+11
| | | | Change-Id: I750654c28cb3d9f9aa67bd56e4d8d770dbfde4b4
* Add test for many interruptions to a single download.Steve Howard2010-07-271-80/+46
| | | | | | | | | | | | | | | Adding a new test case for downloads that undergo many interruptions (as may happen with a very large download that takes many hours). Includes some refactoring in the test suite. Early on, this test exposed a race condition in which the download manager got some I/O exception while reading from the MockWebServer. I went in and improved/refactored much of the error logging code in DownloadThread to try and track this down. Unfortunately, once I finished, the race condition no longer seems to be reproducible, even with hundreds of runs of the test case. So I've given up on it for now. In any event, error logging is better and much duplicate code has been eliminated.
* Improved support for 302/307 redirects.Steve Howard2010-07-271-61/+90
| | | | | | | | | | | | | | | | | Change the download manager's handling of 302/307 temporary redirects so that after an interruption of any kind, the delayed retry/resume will return to the original URI. This complies better with the HTTP spec. This change also makes the download manager handle other redirects immediately rather than using the delay that's otherwise applied to download errors. I made one more method extraction in DownloadThread to simplify this change, pulling the top-level logic for a single request into executeDownload(). It was then just a matter of introducing a new RetryDownload exeception, similar to StopRequest, and making the redirection code use it. Change-Id: Ic719c5725a9fd2e5eebe4dc03453ee71d9f27cd4
* Fix bug with closing output stream for external downloads.Steve Howard2010-07-272-4/+4
| | | | | | | | I added a unit test to cover this, and it caught another issue with disallowing external destinations outside of the default downloads directory (which are now allowed with the new API). Change-Id: I4df6442bebb06458ad28c85f6bc8cbcbf3ce67a1
* Serialize threading for download manager testing.Steve Howard2010-07-274-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Stub out and test system notifications.Steve Howard2010-07-235-20/+49
| | | | | | | | | | | | | 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
* Support for non-purgeable downloads through the public API.Steve Howard2010-07-231-5/+16
| | | | | | | | | | | This change adds a permission, android.permission.DOWNLOAD_CACHE_NON_PURGEABLE. When an app has this permission, any downloads it requests through the public API to the download cache will automatically become non-purgeable, i.e. they'll never be automatically deleted by the download manager to free up space. This is intended for use only by the system updater. Change-Id: I35cdd44f7e5d46bc70443d1a9743f61a51395ddb
* Make DownloadProvider accessible for public API usage.Steve Howard2010-07-222-47/+125
| | | | | | | | | | | | | | | | | | | | | | | | | This change removes the requirement that apps have the ACCESS_DOWNLOAD_MANAGER permission in order to access DownloadProvider. This enables the public API to work. Instead, DownloadProvider enforces the new permissions model for the public API: * insert() requires INTERNET permission * insert() checks that input fits within the restricted input allowed for the public API * insert() also strictly checks the file URI provided with DESTINATION_FILE_URI (and still requires WRITE_EXTERNAL_STORAGE permission if that is supplied) Note that if an app has the ACCESS_DOWNLOAD_MANAGER permission, legacy behavior is retained. I've added a test to cover this new access, and updated the existing permissions tests. I also fixed a bug in WHERE clause construction in update() and delete(), and refactored the code to eliminate duplication. Change-Id: I53a08df137b35c2788c36350276c9dff24858af1
* Make COLUMN_URI readable and tighten UID restrictions.Steve Howard2010-07-211-34/+15
| | | | | | | | | | | | I need to make COLUMN_URI readable by apps, since the public API exposes that field. In order to avoid any possible security issues, I got rid of the feature that potentially allowed apps to view downloads from other UIDs. No one was using that feature and the public API exposes no such feature (yet). While at it, I cleaned up some related code in update() and delete(). Change-Id: I5384115d2a865255d009fbe37449488fd2269389
* Public API support for broadcasts and connectivity control.Steve Howard2010-07-216-23/+158
| | | | | | | | | | | | | | | | * 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 00:19:34 +0000