| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
for background activity starts
When the DownloadManager download notification is clicked,
that broadcast is sent to an app, and the app should be able
to open activities from bg for its duration.
Bug: 135515407
Test: com.android.providers.downloads.PublicApiFunctionalTest#testNotificationClickedBroadcast
Test: manual
Change-Id: Ic1691f5bda890ceb2938ac76f4ca2a4c7e7a1160
|
| |
|
|
|
|
|
|
|
|
| |
Previously DownloadManager only respected the manifest attribute, this
change makes DownloadManager handle both the manifest and the network
security config
Change-Id: I5666a1eea6278acc3864620a0e5a4c3ae37635b8
Fixes: 78028215
Test: atest CtsNetSecConfigDownloadManagerTestCases
|
| |
|
|
|
|
|
|
|
| |
Checking new capability is perferred way to verify a network isn't
roaming; isRoaming() is now deprecated.
Test: bit DownloadProviderTests:*
Bug: 68397798
Change-Id: I11d19fd5a389b52e199c604a6906423d405072e2
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On devices with multiple active networks, or rapidly switching
between networks, we need an API to tell jobs explicitly which
network to use. (For example, the default route could meet all
job criteria, but we could have changed the default network by the
time we spun up the JobService.)
Test: verified via DownloadManager
Bug: 64133169
Change-Id: I9c131818d7199f79e147893d85c281473d00bee9
|
| |
|
|
|
|
|
|
|
|
| |
The OS now completely relies on NET_CAPABILITY_NOT_METERED to avoid
confusion and staleness.
Bug: 63391323
Test: builds, boots, Wi-Fi policy is upgraded
Exempt-From-Owner-Approval: Bug 63673347
Change-Id: Iea83e0afd8cbd2be10d85b8a35c903047716b5b9
|
| |
|
|
|
| |
Bug:29505888
Change-Id: Ifc33fd75e44d1dbc5a4ce5caa8e1ff938b94623e
|
| |
|
|
|
|
|
|
|
|
|
| |
Downloads with visible notifications should behave as if the
requesting app was running a foreground service. The easiest way
to implement this for now is to ignore any BLOCKED network status
and use the new setWillBeForeground() API so job scheduling ignores
any active blocked/dozing status.
Bug: 26571724
Change-Id: I8ea2b2a7cdb5f469adc11b4d897ff55bd8a9db9a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JobScheduler is in a much better position to coordinate tasks across
the platform to optimize battery and RAM usage. This change removes
a bunch of manual scheduling logic by representing each download as
a separate job with relevant scheduling constraints. Requested
network types, retry backoff timing, and newly added charging and
idle constraints are plumbed through as job parameters.
When a job times out, we halt the download and schedule it to resume
later. The majority of downloads should have ETag values to enable
resuming like this.
Remove local wakelocks, since the platform now acquires and blames
our jobs on the requesting app.
When an active download is pushing updates to the database, check for
both paused and cancelled state to quickly halt an ongoing download.
Shift DownloadNotifier to update directly based on a Cursor, since we
no longer have the overhead of fully-parsed DownloadInfo objects.
Unify a handful of worker threads into a single shared thread.
Remove legacy "large download" activity that was thrown in the face
of the user; the UX best-practice is to go through notification, and
update that dialog to let the user override and continue if under
the hard limit.
Bug: 28098882, 26571724
Change-Id: I33ebe59b3c2ea9c89ec526f70b1950c734abc4a7
|
| |
|
|
|
|
|
|
|
| |
Downloads should use the default network for the caller. This prevents
applications from, for example, bypassing VPN by routing all requests
through the DownloadProvider.
Bug: 27074270
Change-Id: I7830226dd2910757d3a5c78f373330f84637ccfa
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
