summaryrefslogtreecommitdiffstats
path: root/src/com/android/providers/downloads/DownloadNotification.java
Commit message (Collapse)AuthorAgeFilesLines
* Move to Notification.Builder progress API.Jeff Sharkey2011-08-091-47/+33
| | | | | | | | Instead of using custom layout to surface progress information, use new Builder API. Also use resources to build percent string. Bug: 4022082 Change-Id: I556a666771e9103ce5d7ddb60faa879b8777b284
* bug:3425749 if adding completed download to db, send completion notifVasu Nori2011-02-101-38/+40
| | | | Change-Id: I9f9f6f2e0b2bd18f3767574fc51301b75bb1b76d
* when download-complete-notif is clicked on, don't show notif anymoreVasu Nori2010-12-151-1/+1
| | | | | | | | | | | bug:3272589 in HC, when using public API, if the downloaded file is in downloads data dir, wrong intent action is set when the user clicks on download-complete notification. fix this by sending the correct intent action if the download is in downloads data dir or any other location specified by the app. Change-Id: I72621be5f1d6a5caecb8ec85634b351e08b66c31
* remove usage of hidden public constants.Vasu Nori2010-10-201-2/+2
| | | | Change-Id: I2edf1bef5e741de8193cb293807e3ace42003b0c
* Improve how the download manager reports paused statuses.Steve Howard2010-09-291-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix notification bugs, cleanup DownloadService + DownloadReceiverSteve Howard2010-09-201-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* Add UI message when queued for wifi due to size.Steve Howard2010-08-201-95/+73
| | | | | | | | | | | | | | | | 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
* Stub out and test system notifications.Steve Howard2010-07-231-7/+5
| | | | | | | | | | | | | 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
* Cleanup whitespace in DownloadNotificationSteve Howard2010-07-151-24/+24
| | | | Change-Id: I598ece9690649573d44d3089e473612e25f2974b
* Create a new permission that allows apps to see downloads from otherLeon Scroggins2010-02-051-22/+7
| | | | | | | | | | | | applications to the SD card. Necessary for http://b/issue?id=2384554 Also create names for files by default, so they do not display as <Untitled>. Remove calls to createTitleFromFilename, which are no longer necessary. Requires a change to frameworks/base.
* Revert "Download files even if there is no activity to launch them."Leon Scroggins2010-01-221-11/+2
| | | | | | | 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.
* Update the title of the download based on the filename.Leon Scroggins2010-01-211-6/+20
| | | | | | | | Now that the downloads page is not necessarily opened when a download starts, we need to provide a name even if the downloads page isn't shown. So when we create a notification, provide the title. Depends on a change to frameworks/base
* Download files even if there is no activity to launch them.Leon Scroggins2010-01-211-2/+11
| | | | Fixes http://b/issue?id=2367247
* Use the private legacy APIJean-Baptiste Queru2010-01-141-35/+36
| | | | | | | | | | 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
* Fix Download application notification timestamp not correct issueLixin Yue2009-11-251-2/+2
| | | | | | | | | | | | | Should set the value of Notification.when before calling setLatestEventInfo(). On downloading an image without exif information, the received file's timestamp is correct for main database field but incorrect for temporary display field. Root cause is that if Notification.when not set before calling setLatestEventInfo(), the timestamp value in milliseconds unit will be directly set to a field as second unit. Thus database will record the time as 1000 times forward as 2067, etc. However from UI the file's time will be just shown like "10/10/67", misleading people to think time is set backwards before system time 0(1969).
* Use the new download manager APIs introduced in change 7400Jean-Baptiste Queru2009-01-211-18/+27
|
* Match the official code style guide.Jean-Baptiste Queru2009-01-201-31/+31
| | | | | | 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.
* Code drop from //branches/cupcake/...@124589The Android Open Source Project2008-12-171-10/+10
|
* Initial ContributionThe Android Open Source Project2008-10-211-0/+300