| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I9f9f6f2e0b2bd18f3767574fc51301b75bb1b76d
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I2edf1bef5e741de8193cb293807e3ace42003b0c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I598ece9690649573d44d3089e473612e25f2974b
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Fixes http://b/issue?id=2367247
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|