| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Motivation: I need to fix the handling of 302s, so that after a
disconnect, subsequent retries will use the original URI, not the
redirected one. Rather than store extra information in the DB, I'd
like to just keep the redirected URI in memory and make the redirected
request within the same DownloadThread. This involves working with
the large-scale structure of DownloadThread.run(). Since run() was a
~700 line method, I didn't feel comfortable making such changes.
So this change refactors run() into a ~80 line method which calls into
a collection of ~20 other short methods. The state previously kept in
local variables has been pulled into a couple of state-only inner
classes. The error-handling control flow, formerly handled by "break
http_request_loop" statements, is now handled by throwing a
"StopRequest" exception. The remaining structure of run() has been
simplified -- the outermost for loop, for example, could never
actually repeat and has been removed for now. Some other bits of code
have been cleaned up a bit, but the functionality has not been
modified.
There are many good next steps to this refactoring. Besides various
other cleanup bits, a major improvement would be to consolidate the
State/InnerState classes, move some functionality to this new class
(there are many functions of the form "void foo(State)" which would be
good candidates), and promote it to a top-level class. But I want to
take things one step at a time, and I think what I've got here is a
major improvement and should be enough to allow me to safely implement
the changes to redirection handling.
In the process of doing this refactoring I added many test cases to
PublicApiFunctionalTest to exercise some of the pieces of code I was
moving around. I also moved some test cases from
DownloadManagerFunctionalTest. Over time I'd like to move everything
over to use the PublicApiFunctionalTest approach, and then I may break
that into some smaller suites.
Other minor changes:
* use longs instead of ints to track file sizes, as these may be
getting quite large in the future
* provide a default DB value of -1 for COLUMN_TOTAL_BYTES, as this
simplifies some logic in DownloadThread
* small extensions to MockResponse to faciliate new test cases
Change-Id: If7862349296ad79ff6cdc97e554ad14c01ce1f49
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |\
| |
| |
| | |
Change-Id: If84d4054324db6d10fd0cdbd2169c039c6675726
|
| | |
| |
| |
| |
| |
| |
| | |
verified with lsof DownloadProvider after downloading a file shows:
${proc} 338 10034 33w REG 179,0 167634 5 /sdcard/download/fw4-1.pdf
Change-Id: I8e2412fe9a6348f5ece6f5ca3a9ebf99a4474bce
|
| | | |
|
| | |
| |
| |
| | |
persistent SSL session caching.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/ |
|
| |
|
|
|
|
|
| |
Also tweak some slightly inaccurate logging, and add a note
about a potential bug.
BUG=2055624
|
| |
|
|
| |
BUG=2055624
|
| |
|
|
|
|
|
| |
This is enabled by a separate build-time constant, so that it can
be turned on for everyone without having to use a system property.
BUG=2055624
|
| |\
| |
| |
| |
| | |
Conflicts:
src/com/android/providers/downloads/DownloadThread.java
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This will write the downlaoded file to the storage (sdcard in default).
It can prevent file corruption if the user removes the sdcard unsafely
after a download completes.
|
| | | |
|
| |/
|
|
|
|
| |
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.
|
| | |
|
| |
|
