| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Otherwise these interactions risk getting stuck in a delayed
background broadcast queue, and we'd re-post notifications based on
stale data that hasn't been updated yet.
Test: builds, boots
Bug: 64098529
Change-Id: I93302e5a4380bb0ac8977153c3afaa02bcc36c84
|
| |\
| |
| |
| |
| |
| | |
am: 726919cd92
Change-Id: Id054a1577d019f257da1a3f1575b47143e15382f
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Won't impact devices that have already created the channel.
Bug: 63755460
Test: N/A
Change-Id: I3930ccf67bc5594493e1d10e48fc43fded104ebf
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of reaching directly into PackageManager, use the new
StorageManager API to allocate disk space for downloads. This wraps
both clearing cached files and fallocate() into a single method.
Remove support for storing downloads on the /cache partition, which
doesn't exist on many devices.
Bug: 63057877
Test: bit DownloadProviderTests:*
Exempt-From-Owner-Approval: Bug 63673347
Change-Id: I5749f7a2f7ded9157fea763dc652bf4da88d86ff
|
| |
|
|
|
|
| |
Test: builds, boots
Bug: 37493685
Change-Id: I76cea80de092f99615b4a42058f2abf5f9cdb797
|
| |
|
|
|
|
|
|
| |
We tell the user about active, completed, and waiting downloads.
Test: builds, boots, downloads work
Bug: 36865435
Change-Id: Id5db029a98971a7b7d190f01eea2439120c18531
|
| |
|
|
|
|
|
| |
Only active downloads should be classified as ongoing notifications.
Bug: 30065873
Change-Id: I778eafb0737c7da17216fb3012847e6a3beccde9
|
| |
|
|
|
|
|
|
| |
Otherwise it's confusing to see notifications for downloads that
are otherwise invisible.
Bug: 28623639
Change-Id: I1b2aeccfcca1369f66c56c441dfef68ee95c6d62
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
Bug: 27971263
Change-Id: Ia68d43828ecc32c1b6a656a0d3bb751b2a2e7881
|
| |
|
|
|
|
|
|
|
| |
When service starts, use new API to read the current set of
notification tags from the system instead of clearing and starting
from scratch.
Bug: 27634130
Change-Id: I049fe5e445a62a52042d7638c2cb50417977435f
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
Bug: 15476051
Change-Id: I085c074f1bb66631872712cab68bcaf6ee7ba7dc
|
| |
|
|
|
| |
Bug: 17128331
Change-Id: Ie2529189e4d62c7dc385f9d36c70ac412fb4159c
|
| |
|
|
|
| |
Bug: 8744610
Change-Id: I135a3acbc819fd725f00ba57461e21db1fe24850
|
| |
|
|
|
|
|
|
|
| |
PendingIntent.getBroadcast() doesn't update the intent extras if not
explicitly given something to distinguish the intents. This caused the
notification on-click to do nothing on everything but the first
download.
Change-Id: I29544ae5b04f8304cbbe720066a26ff90e422107
|
| |
|
|
|
|
|
| |
Otherwise notifications end up launching with stale download IDs.
Bug: 8417220
Change-Id: Ie72a2f4ac7b72213678ac6001af45709034492dd
|
| |
|
|
|
|
|
|
|
| |
Most wtf() are looking like network timeouts, not threading bugs, so
disable verbose debugging and add more targeted thread logging before
calling wtf().
Bug: 8233041
Change-Id: I8e276bffd7880cfe13b65e7e81f5507cab627692
|
| |
|
|
|
| |
Bug: 8145142
Change-Id: I9119796f809aa967f7ec6bb2a3d2b815e86eaf1b
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Switch to using a ThreadPoolExecutor for handling downloads, which
gives us parallelism logic that is easier to reason about. Also
open the door to eventually waiting until the executor is drained
to stopSelf().
Removes DownloadHandler singleton, and gives explicit path for
publishing active download speeds to notifications.
Change-Id: I1836e7742bb8a84861d1ca6bd1e59b2040bd12f8
|
| |
|
|
|
| |
Bug: 7693834
Change-Id: I5e212be321cccae0f7c76f80049c4e09f0867694
|
| |
|
|
|
|
|
|
|
|
|
| |
Calculate remaining time in DownloadNotifier so we always use the
most recent progress data, which avoids showing stale times.
Weight speed calculation to prefer historical data so remaining time
is smoother on bumpy network connections.
Bug: 7631948
Change-Id: I497be0899e65086356745340b19d3987c6185bdd
|
| |
|
|
|
|
|
|
|
|
| |
Calculate speed of in-progress downloads and estimate time remaining
until completion. Uses a moving average that is weighted 1:1 with
the most recent 500ms sample. Funnels timing data to notifications
through DownloadHandler.
Bug: 6777872
Change-Id: I9155f2979aa330bd1172f63bbfca1d053815cee5
|
|
|
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
|
