| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Bug: 4726601
Change-Id: Ibe537bd5c2a092dbf974360cd454751881f7f4ea
|
|
|
|
| |
Change-Id: Ibbce0782fcf7649209d6f56be240209cebd9045b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
one big change in this CL is addition of a new feature to MockWebServer.
It can now play a long response to the Downloading thread to keep it busy
while something - such as cancel/remove - can be done to that Download Request.
Also, added changes to FakeSystemFacade to start threads in normal fashion
instead of queuing them up and later running just their run() methods.
the following tests should work now
packages/providers/DownloadProvider/tests/src/com/android/providers/downloads/
DownloadManagerFunctionalTest.java
PublicApiFunctionalTest.java
ThreadingTest.java
PublicApiAccessTest.java
DownloadProviderPermissionsTest.java
the following are flaky. they need to be split up into smaller tests.
frameworks/base/core/tests/coretests/src/android/app/
DownloadManagerIntegrationTest.java
DownloadManagerStressTest.java
Change-Id: Ia0b11963f92e8f8365f701761dcbce467be3ee9b
|
|
|
|
| |
Change-Id: I2edf1bef5e741de8193cb293807e3ace42003b0c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Now that I've learned how ContentResolver.notifyChange() works, add a
test to explicitly check it's being called in DownloadProvider, and
take advantage of it in waitForDownloadToStop to get rid of the ugly
old polling mechanism.
Change-Id: Iba71bdf1b0d31454cc4e186ceb4fdd9fdb5faad5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
File URI destinations:
* permission checking in DownloadProvider
* implementation in Helpers.generateSaveFile(). it's a fairly small
amount of logic added here, but I did some significant method
extraction to simplify this change and clean up the code in general.
* added test case
Last modified timestamp:
* made DownloadProvider use a SystemFacade for getting system time, so I could properly test timestamps
* updated test cases to cover last modified time + handle new ordering
|
|
I refactored a lot of the logic from DownloadManagerFunctionalTest
into a new abstract class so that it could be shared with the new
PublicApiFunctionalTest. There could be even more sharing, but it's
not entirely clear it'd be worthwhile at this point. The new test
covers most features of the new public API.
Change-Id: I8c6859411f44b6430f8b348cf26a61225f5768cb
|