summaryrefslogtreecommitdiffstats
path: root/tests/src/com/android/providers/downloads/FakeSystemFacade.java
Commit message (Collapse)AuthorAgeFilesLines
* Make DownloadProvider honor the cleartext traffic policy.Alex Klyubin2015-04-011-0/+6
| | | | | | | | | | | | | | | | | | | This makes the Provider-side of the DownloadManager framework honor the per-UID cleartext network traffic policy. The policy is enforced in the Provider rather than in its client (DownloadManager) because download URLs could get redirected between HTTPS and HTTP and only the Provider currently has visibility into and control over this. Whether cleartext network traffic is permitted is a per-package policy. However, the DownloadProvider can only access the UID of the requesting application. Multiple packages can run under the same UID. In that scenario, cleartext traffic is permited for the UID if cleartext traffic is permitted for any of the packages running under the UID. This could be improved by making the DownloadManager provide the package name in addition to the UID. Bug: 19215516 Change-Id: Ib37585a7a2fc2869954d52a1b08052926f49bc9b
* Many improvements to download storage management.Jeff Sharkey2014-02-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all data transfer to occur through FileDescriptors instead of relying on local files. This paves the way for downloading directly to content:// Uris in the future. Rewrite storage management logic to preflight download when size is known. If enough space is found, immediately reserve the space with fallocate(), advising the kernel block allocator to try giving us a contiguous block regions to reduce fragmentation. When preflighting on internal storage or emulated external storage, ask PackageManager to clear private app caches to free up space. Since we fallocate() the entire file, use the database as the source of truth for resume locations, which requires that we fsync() before each database update. Store in-progress downloads in separate directories to keep the OS from deleting out from under us. Clean up filename generation logic to break ties in this new dual-directory case. Clearer enforcement of successful download preconditions around content lengths and ETags. Move all database field mutations to clearer DownloadInfoDelta object, and write back through single code path. Catch and log uncaught exceptions from DownloadThread. Tests to verify new storage behaviors. Fixed existing test to reflect correct RFC behavior. Bug: 5287571, 3213677, 12663412 Change-Id: I6bb905eca7c7d1a6bc88df3db28b65d70f660221
* Clean up DownloadManager threading tests.Jeff Sharkey2013-01-081-27/+19
| | | | | | | | | | | 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
* Rewrite of download notifications.Jeff Sharkey2012-11-091-1/+4
| | | | | | | | | | | | | | | | | | Switch to using new inbox-style notifications when collapsing multiple downloads. Correctly handles clustering, including cancellation of stale notifications. All notifications are now handled in a single class, making it easier to reason about correctness. Fixed bugs around handling of visibility flags. Move away from using "int" as internal keys, since they can overflow. Started work for time estimates, will finish in a future CL. Explicitly pass all relevant IDs to DownloadReceiver instead of doing a second racy query. Fix StrictMode warnings when querying in DownloadReceiver. Bug: 6777872, 5463678, 6663547, 6967346, 6634261, 5608365 Change-Id: I5eb47b73b90b6250acec2ce5bf8d7a274ed9d3a9
* Move notification tests to LittleMock.Jeff Sharkey2012-07-241-29/+0
| | | | | | Directly mock NotificationManager instead of using SystemFacade. Change-Id: If932d26e23816e8674469c275a828701cce5fc2d
* Add and enforce ALLOW_METERED column.Jeff Sharkey2012-04-171-0/+6
| | | | | | | | | | | | 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
* Teach DownloadManager about network policy.Jeff Sharkey2011-06-171-2/+7
| | | | | | | | | | | 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
* fix broken DownloadManager testsVasu Nori2010-12-091-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement dialogs for wifi required + recommended limits.Steve Howard2010-09-211-0/+5
| | | | | | | | | | | | | | | | | | | 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
* Fix notification bugs, cleanup DownloadService + DownloadReceiverSteve Howard2010-09-201-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Get wifi limit from secure settings.Steve Howard2010-07-281-2/+2
| | | | Change-Id: I750654c28cb3d9f9aa67bd56e4d8d770dbfde4b4
* Serialize threading for download manager testing.Steve Howard2010-07-271-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Stub out and test system notifications.Steve Howard2010-07-231-0/+29
| | | | | | | | | | | | | 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
* Public API support for broadcasts and connectivity control.Steve Howard2010-07-211-0/+16
| | | | | | | | | | | | | | | | * 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
* Support for max download size that may go over mobileSteve Howard2010-07-191-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-151-1/+19
| | | | | | | | | 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
* Stub out the system clock in the download manager, add testsSteve Howard2010-07-011-0/+13
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