| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Directly mock NotificationManager instead of using SystemFacade.
Change-Id: If932d26e23816e8674469c275a828701cce5fc2d
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Change-Id: I750654c28cb3d9f9aa67bd56e4d8d770dbfde4b4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
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
|
