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

Use parseInt when the result is assigned to an int. Allocates fewer
objects.

bug: 28078871
Change-Id: I2c58112795fecce6395c558f2bb1e1fefe83a5bf

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

Change-Id: I9b2711c2a9b3edd4bbef97ff6cdcae9fdc9ef433

Bug: 22958127
Change-Id: I314a9bdd21988bf7e6cc79a2ae842bed29c96f17

Add a "Cancel" action to in-progress downloads shown in notification
pane.
We add a new action type for a new "cancel" intent sent by
DownloadNotifier to DownloadReceiver, which in turn cancels the
download by way of DownloadManager.

BUG=19972464

Change-Id: I83cd2f40e1442c327f756027b99f9eac913a0e70

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