| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: Ie0373c1f2a6be16cd1cfc197a8350582c00c6871
|
|
|
|
|
|
|
|
|
| |
JobScheduler.getAllPendingJobs() can return null when there are none.
Deal with it.
Bug 21642868
Change-Id: I11fcc6e146f9db51e03dcf57f7518bb7878fbd28
|
|
|
|
|
|
|
|
|
| |
...preparatory to finally removing the scratchpad "idle maintenance"
infrastructure from the product.
Bug 14993295
Change-Id: I1e84247de19e616910db1781b2c399a8b15a805c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
This reverts commit 4f9d2d04003fafb358d7c127054055b3a9732c9b, was only
wanted for debugging.
|
|
|
|
|
|
|
|
| |
Try to catch the download provider in the act of deleting pending
system updates.
Bug: 12680933
Change-Id: If58aba5c30fd624217e5d073730645af05e98ac7
|
|
|
|
|
|
|
| |
Also reduce and adjust some logging.
Bug: 8470658
Change-Id: Ia1f1cbd315ded04edd2113506e5c5a1db5ec85b4
|
|
|
|
|
|
| |
This reverts commit 97d507d95f9885ceb12f2ce2483361b5ed265f9f
Change-Id: I20374301561b3a1c79c2d986292af50049de2aac
|
|
|
|
|
| |
Bug: 8470658
Change-Id: I4cfd6a01c2c2d845a72d3f58c29eec8b44176537
|
|
|
|
|
|
|
|
|
| |
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: 8233041
Change-Id: Ifb70273474c391ef687ba018d9ef809a359c7149
|
|
|
|
|
|
|
|
|
| |
Otherwise we end up triggering MSG_FINAL_UPDATE while still waiting
for socket timeouts. Using 20 seconds for timeout is more sane, and
matches Volley.
Bug: 8233041
Change-Id: Ia7220033a5942c46ca1d79a88e2b3f530cb3edac
|
|
|
|
|
|
|
|
|
| |
Otherwise they end up leaking. There is a race around UpdateThread
continuing to process messages before onDestroy() has been invoked,
so explicitly UpdateThread.quit() in both places.
Bug: 8233041
Change-Id: I73f1b70aedace19e23a61a3dddf4986d82f2c7d6
|
|
|
|
|
|
|
|
| |
Since DownloadService starts and stops frequently, recycle a single
UpdateThread across invocations.
Bug: 8233041
Change-Id: I07756fb6bfdbad811cbd58e628fdfdbf63d71bf8
|
|
|
|
|
|
|
|
|
|
|
| |
Wait until we've passed a full sample window (500ms) before reporting
an estimated speed. This avoid showing skewed times like "900 hours
remaining."
Also remember to clean up the UpdateThread.
Bug: 8176417
Change-Id: I851e0abcbb443114abe9c22f4650fee7a9bc3aaa
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the service lifecycle was managed through a large for()
loop which was extremely tricky to reason about. This resulted in
several race conditions that could leave the service running
indefinitely, or terminate it early before tasks had finished.
This change redesigns the update loop to be event driven based on
database updates, and to collapse mutiple pending update passes. It
is much easier to reason about service termination conditions, and
it correctly uses startId to handle races during command delivery.
Also moves scanner into isolated class, and switches to using public
API instead of binding to private interface.
Bug: 7638470, 7455406, 7162341
Change-Id: I380e77f5432223b2acb4e819e37f29f98ee4782b
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Now DownloadService creates and owns the lifecycle of its own
StorageManager instance.
Change-Id: I8f6bedc02f1dbe610a8e6a25d55383a12716d344
|
|
|
|
|
| |
Bug: 7693834
Change-Id: I5e212be321cccae0f7c76f80049c4e09f0867694
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
When deleting a download, don't bother scanning it, since we'll just
delete it moments later. This was already racy since it didn't even
wait for the scan to complete.
Bug: 7256243
Change-Id: I8c3b96823d94bc1688ef336cb45746ccd35fc760
|
|
|
|
|
|
| |
Directly mock NotificationManager instead of using SystemFacade.
Change-Id: If932d26e23816e8674469c275a828701cce5fc2d
|
|
|
|
|
| |
Bug: 6544953
Change-Id: I4157c67b9b9cddab4ade795c328a202f6a230f95
|
|
|
|
|
| |
Bug: 6362988
Change-Id: Iab4b86cfcaa6aeed6466f88ff49eb935f96db495
|
|
|
|
|
| |
Bug: 4997552
Change-Id: I3c612acb5145a7638c9345a376a99958851a0891
|
|
|
|
| |
Change-Id: Id4800401c16811df9c4ee78ee9636c77b4c95756
|
|
|
|
|
| |
Bug: 3136228
Change-Id: I77c4f998c9718c7630800dec152779ff59186187
|
|
|
|
| |
Change-Id: Ibbce0782fcf7649209d6f56be240209cebd9045b
|
|
|
|
| |
Change-Id: Iad8cfe0da389a70ff679cf6d3378f50e945d03a6
|
|
|
|
|
|
| |
and retry downloads that failed due to the error "sdcard media not mounted"
Change-Id: Id181b8167d331214f72679c85f18cc8b9b969e40
|
|
|
|
| |
Change-Id: Ib9d4df107787191a5349365908cbe096b67770dc
|
|
|
|
|
|
|
|
|
|
| |
make sure the doanloads data dir size is limited by some quote -
100MB default and 200MB for SR.
bug:3286430
tests are in Change-Id: I688f7e058511089bec7fa21e972e23780604d98a
Change-Id: Iba7fab9fa91ea018f35e1c3ef5ec0e6b03cba650
|
|
|
|
|
|
|
|
|
|
| |
bug:3264401
still to do:
make sure only N bytes are taken up by downloads dir
N = a value specific to each device.
default = 100MB.
Change-Id: I2a49f4b3831d3a8d7be13b5fd46d85d56e831e38
|
|
|
|
|
| |
bug:3176990
Change-Id: I182331cbd63b6524a18d19e4d8567210886f8c16
|
|
|
|
|
|
|
| |
if a download fails for some reason, then filename could be null.
move Helpers.deleteFile() code into private method in DownloadService
Change-Id: Ifb12a84b6185e19c70d62392e102950c07f56a01
|
|
|
|
|
|
|
|
|
|
|
| |
this is one of the 2 bugs mentioned in bug:3129943
sometimes MediaProvider returns null for returned param Uri.
in such cases, mark the file as 'scanned' in the downloads db
so that it is NOT scanned again later by DownlaodService.
depends on Change-Id: I92514e1a11f5119229c0c7292e410e352a9dbcdd
Change-Id: Ie9d839581f656c929a77bd5f244ad6b2fb1585e6
|
|
|
|
| |
Change-Id: I2edf1bef5e741de8193cb293807e3ace42003b0c
|
|
|
|
|
|
|
|
|
|
| |
DownloadService always scans files and assumes MediaProvider
returns a valid Uri. But MediaProvider returns null for
return param 'uri'
if the file is not audio/video/image etc media type file
(for example, pdf)
Change-Id: If32bd1895b00b5406973a5e240ad3558d46f9f4a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gingerbread.
High-level details
1. When a file is downloaded by DownloadManager, metadata about the file
is stored in 2 databases: DownloadProvider and MediaProvider.
2. So, when it is to be deleted, its metadata needs to be cleaned up from
both the databases.
3. But the 2 databases use differnt content-uri's as "primary keys" and
DownloadProvider loses the "primary-key" of the row in MediaProvider
database.
4. Easiest thing would have been to have DownloadProvider give filepath
to MediaProvider and let MediaProvider linearly scan its database
to locate the row and delete it.
5. The other - faster but more coding for now - option is to have
DownloadProvider store the "primary-key" of the MediaProvider's
row. implemented in this CL.
Low-level details
1. add 2 new columns to downloads table in downloads.db:
mediaprovider_uri = downloaded file's content_uri in mediaprovider db
this column is null for downloads that finished before this column is
added to the database.
deleted = flag is set to true if a file is to be deleted
2. download UI app shows only those files whose 'deleted' flag is not set.
3. when the user deletes downloads from download UI app,
3.1. if mediaprovider_uri is NOT null, then the row is deleted from
downloads table AND from the mediaprovider database.
3.2 if mediaprovider_uri is NULL, then its row in downloads database
is marked 'tp be deleted' by setting 'deleted' column to '1'.
4. When DownloadService (in DownloadProvider) processes all rows from
downloads table, if it sees any rows wth 'deleted' = 1, then
it uses MediaScanner Service to re-scan the file,
get the mediaprovider_uri from MediaProvider
and update the row in downloads table with this mediaprovider_uri value
and then delete the row by doing the following
1. delete it from MediaProvider database using mediaprovider_uri
2. delete it from DownloadProvider database
Problem with this solution:
There is a small window where it is deleted by the user on the Download app
(and the row disappears from the display) but it is still present in
Gallery app.
Thats due to the following asynchronous operations
1. DownladService which processes rows-to-be-deleted is not always up
2. DownloadService uses asynchronous call to have the file re-scanned
by MediaScanner to get mediaprovider_uri
Change-Id: Ib90eb9e647f543312c865d3bbf9a06fb867a648b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes the download manager report more detail when a
download is paused. Rather than always reporting status
RUNNING_PAUSED, there are now four different statuses:
* paused by the app
* waiting to retry after a network error
* waiting for network connectivity
* queued for wifi due to size limits
This allows a few improvements:
* code deciding when to run a download can be improved and cleaned up
(I've taken some extra steps in cleaning up this particular code)
* notification code no longer has to rely on the in-memory-only
"mPausedReason" member of DownloadInfo; instead, it knows from the
status that the download is queued for wifi, and can display the
appropriate string. This moves the string fetching out into the
UI-specific logic and is a sign that this is really the right way
to do things.
And finally, the real motivation for this change: I've changed the
meaning of "Queued" in the downloads UI so it now means "Queued for
WiFi'. This is what was originally intended, I'd misunderstood. What
was formerly known as "Queued", a download that hadn't started, is now
displayed as "In progress" (it's always a transient state so it's
basically meaningless anyway). Otherwise it remains the same (in
particular, downloads paused for other reasons are still reported as
"In progress").
I've also increased some of the logging in DownloadThread a bit, as
this change initally introduced some bugs that were impossible to
track down without that logging. There have been other bug reports
that were impossible to diagnose and these few extra log statements
should really help, without cluttering logs too much. I've taken care
to avoid potentially introducing any PII into the logs.
Change-Id: Id0b8d65fc8e4406ad7ffa1439ffc22a0281b051f
|
|
|
|
| |
Change-Id: I92180fc4344579b93361d5584243688a1cfdd091
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces a second view into the download manager
database via a set of URIs starting with /all_downloads, renaming the
original /download URIs to /my_downloads. In addition to making
things more clear, this change allows the downloads UI to grant
permissions on individual downloads to viewer apps.
The old semantics were:
* for ordinary callers, /download included only downloads initiated by
the calling UID
* for intraprocess calls or calls by root, /download included all
downloads
The new semantics are
* /my_downloads always includes only downloads initiated by the
calling UID, and requires only INTERNET permission. It could just
as well require no permission, but that's not possible in the
framework, since path-permissions can only broaden access, not
tighten it. It doesn't matter, because these URIs are useless
without INTERNET permission -- if a user can't initiate downloads,
there's no reason to read this.
* /all_downloads always includes all downloads on the system, and
requires the new permission ACCESS_ALL_DOWNLOADS. This permission
is currently protectionLevel=signature -- this could be relaxed
later to support third-party download managers.
All download manager code has been changed to use /all_downloads URIs,
except when passing a URI to another app. In making this change
across the download manager code, I've taken some liberties in
cleaning things up. Other apps are unchanged and will use
/my_downloads.
Finally, this incorporates changes to DownloadManager to return a
content URI for /cache downloads -- the download UI no longer assumes
it's a file URI, and it grants permissions to the receiver of the VIEW
intent. The public API test has also been updated.
I've also fixed some null cursor checking in DownloadManager.
Change-Id: I05a501eb4388249fe80c43724405657c950d7238
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As it stands, when a download is paused because it's too big to
proceed over mobile, and must proceed over wifi, it looks like any
other paused download, with no indication of why it's paused. That
may be passable for most other reasons for pausing a download, but it
seems too confusing for this case. So this change adds a simple
string message that replaces the progress bar when a download is
paused for this reason (the icon also changes to a warning).
The implementation isn't beautiful and could use some improvement, but
I think it's acceptable and necessary. The exact UI design and
wording are certainly open to change.
Change-Id: I753d57f463e2614b5694bdc178d2a51066da8ca3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|