summaryrefslogtreecommitdiffstats
path: root/tests/src
Commit message (Collapse)AuthorAgeFilesLines
* Fix bug with deciding when to restart a download.Steve Howard2010-07-201-0/+13
| | | | | | | | | | | | | | In previous refactoring I had combined the code for starting a download (from DownloadService.insertDownload()) and restarting a download (from DownloadService.updateDownload()). I'd missed the fact that the former checks DownloadInfo.isReadyToStart() while the latter checks DownloadInfo.isReadyToRestart(). This cause a race condition where multiple startService() calls during a download would cause the service to try to spawn a second thread for the same running download. I've fixed the bug and added a test case to exercise this. Change-Id: Ia968331a030137daac7c8b5792a01e3e19065b38
* Support for max download size that may go over mobileSteve Howard2010-07-192-9/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Introduce a seam to ConnectivityManager and TelephonyManagerSteve Howard2010-07-154-164/+46
| | | | | | | | | 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
* Support for custom HTTP headers on download requestsSteve Howard2010-07-151-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support for file URI destinations + last modified timestampSteve Howard2010-07-142-9/+56
| | | | | | | | | | | | | 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
* New functional test for download manager public API.Steve Howard2010-07-133-246/+535
| | | | | | | | | | 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
* Stub out the system clock in the download manager, add testsSteve Howard2010-07-013-54/+142
| | | | | | | | | | | | | | 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
* Fix build in master - new method in FakeIConnectivityManagerSteve Howard2010-06-291-0/+4
| | | | Change-Id: I76996b9a7b6d0f725480cacb1da032cec2dade0b
* First pass at a functional test for the Download Manager.Steve Howard2010-06-285-23/+603
| | | | | | | | | | | | | | | | | | | | | This "Large" test sets up an HTTP server on the device using MockWebServer and then initiates downloads from that server through the download manager. It uses ServiceTestCase to control the construction and execution of the DownloadService, and it uses some logic from ProviderTestCase2 to construct a DownloadProvider and a ContentResolver that uses it. This setup gives us some ability to mock dependencies. This commit includes use of a fake ConnectivityManager to test responses to connectivity changes, and use of some customizations to MockWebServer to test resuming an interrupted download. This test is disabled, though, since it requires a very long sleep. Avoiding that, and achieving certain other things, will require changes to the Download Manager code itself to introduce new seams. I wanted to check this in before I started such changes. Change-Id: Iefb13b3c3cccdc13fabe5cc18703e13244805539
* Check in copies of MockWebServer + friends.Steve Howard2010-06-213-0/+486
This commit includes unmodified copies of MockWebServer and its supporting classes, taken from dalvik-dev:libcore/support/src/tests/java. My test will require some changes, but I'm committing unchanged versions first so I can more easily track my changes and eventually merge them back over. Change-Id: Ic4b79c7a2cbd3bd439864ed94c43fe985eae8e78