| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: If8d354da04747d22c1f7bd016301692c432db3a7
|
|
|
|
|
|
|
|
|
|
|
| |
Today it is not possible to style the download ui using the
overlay mechanism. The reason for this is that the download
ui is missing an application theme.
The solution is to add a DefaultTheme that can be overridden
using overlay.
Change-Id: I2d01838feb863408e284fd0b558eb0d9c8e50e89
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to timing issues a download could be cancelled. This happens when the
downloading state machine gets in the wrong state. There are two variables
in the state machine which gets out of sync with each other: status and
mHasActiveThread.
The DownloadService thread reads several downloads from the database
and starts to process them. For each applicable download a DowloadThread
is started. For that download mHasActiveThread is set to true and the
download is started. When the download is finished the correct status
is written to the database and mHasActiveThread is set to false.
The problem is that mHasActiveThread changes value instantly in
DownloadService but the status for all downloads are read from the
database at certain times. If the DownloadThread changes the value of
mHasActiveThread before that download has been processed in the
DownloadService thread the value of mHasActiveThread will be up to date
but the status value will be out of sync.
The download will then be restarted even if it is already completed. The
DownloadService will interpred the download as a resume but the server will
handle it as a new download. The downloading statemachine will then be
confused and terminate the download.
This is fixed by synching the changing of status and mHasActiveThread between
DownloadService and DownloadThread. The database information in DowloadService
will also be re-read when it is not up to date.
Change-Id: I8bb28b42b434b424187c918dfded4fdf3baa055b
|
|\
| |
| |
| | |
git://android.git.kernel.org/platform/packages/providers/DownloadProvider into HEAD
|
| |
| |
| |
| | |
Change-Id: Ie0f8770532d0236e882c98312a0f2017389664fd
|
| |
| |
| |
| | |
Change-Id: I47de09bd3d0e853d1b04d3ddf197b29c9b43075e
|
| |
| |
| |
| | |
Change-Id: Idafb34373db2691d1a21fead3d0decbb7e10f735
|
|\|
| |
| |
| | |
git://android.git.kernel.org/platform/packages/providers/DownloadProvider into 233-merge
|
| |
| |
| |
| | |
Change-Id: I974bf33097aaaad0a7e79ce36b45de2f22252f15
|
| |
| |
| |
| | |
Change-Id: Ib81647ed5436d4949a0c81c9900baf407215b9f5
|
| |\
| | |
| | |
| | | |
into gingerbread
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
bug:3175143
sometimes mediaprovider doesn't delete the file from disk when
it is deleted from its db. for example, audio files, pdf files.
DownloadManager/DownloadApp should delete the file when it is
deleted from downloads db.
DO NOT MERGE
this is esentially porting HC fix from DownloadService.java to GB
Change-Id: I70f3a7ad968f82ccba00d664e9a2993d75a18d15
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
redirectcount shouldn't be stored in the db.
say, you are downloading a large app and there are redirects
involved inthe download.
if network connectivity changes during download, then download
is paused and resumed once connectivy is back on.
when the download is resumed, it should start with redirectcount of 0
instead of redirectcount from the previous download session.
Change-Id: I1acf2fb9491d24f5e109206a91dda3eea429e447
|
| | |
| | |
| | |
| | | |
Change-Id: I1c05f11e064f34a04c021bfa0d2282956827eb51
|
| |\ \
| | |/
| |/|
| | | |
Change-Id: I6a6553f8e89f576cf21ee0fb0cba62479f96f2b3
|
| | |
| | |
| | |
| | |
| | |
| | | |
big typo in that CL broke the downloading functionality.
Change-Id: If7dc0f86ea7a3c4394603416ca0fc33847f10fa7
|
| |\ \
| | | |
| | | |
| | | | |
into gingerbread
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Real fix is in Change-Id: Ifea1544737023008eff44aef9acd976902a0c143
In the database, sometimes _data column in downloads is set to null
and sometimes to empty string. this is inconsistent
and causes bugs such as bug:3144642.
This bug is caused by line# 793 in DownloadThread.
state.mFileName is null sometimes and empty string sometimes - because
the correspodning field is set inconsistentlt in downloads.db
_data column.
in GB MR, apply a bandaid because real fix could be too risky for
GB.
Change-Id: I115b3ba6cfe0262269dbbc4c336b9e1d63c618e4
|
| |\ \ \
| | |/ /
| |/| | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Bug 3245452
Change-Id: Ie2e81528c7a16dce5350f5d6845c8b4c0da15f96
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Old platform behavior of DownloadProvider would allow anyone with
special access to access all the downloads. New behavior is to return
/my_downloads/ on an .insert() call. For things that aren't using the
new API where DownloadInfo.getAllDownloadsUri() is accessible, make any
application with ACCESS_ALL_DOWNLOADS permission bypass the calling UID
check for /my_downloads/
Bug: 3242328
Change-Id: I536fde4525dd74066879f7c7da7fa609ff344645
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently only certain ASCII characters are allowed in a filename, all
other characters are replaced with an underscore. This gives bad
usability for foreign languages (e.g. japanese). This fix replaces the
current regexp with a method which replaces only those characters unsafe
to be used on VFAT filesystems (should work on most other
filesystems as well).
Change-Id: I114d47b4b35f28490e6b12493138355532fda499
Signed-off-by: Eddie Ringle <eddie.ringle@gmail.com>
|
|\ \ \
| | | |
| | | |
| | | | |
gingerbread
|
| | |/
| |/| |
|
|/ /
| |
| |
| |
| | |
Change-Id: Ib1712eb3c4d0335e0822be53f9c6fd7b6ac9585e
Signed-off-by: Eddie Ringle <eddie.ringle@gmail.com>
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Old platform behavior of DownloadProvider would allow anyone with
special access to access all the downloads. New behavior is to return
/my_downloads/ on an .insert() call. For things that aren't using the
new API where DownloadInfo.getAllDownloadsUri() is accessible, make any
application with ACCESS_ALL_DOWNLOADS permission bypass the calling UID
check for /my_downloads/
Bug: 3242328
Change-Id: I4d7dae75c528d2803d594c5d79d19865ef37ed30
|
|
|
|
| |
Change-Id: Iadedcf076f8bbe43d1864baf989b21d9d30f13f7
|
|
|
|
| |
Change-Id: Id9cdaf0062ee97f067b644bcc00d41182ff52934
|
|
|
|
| |
Change-Id: If3fb1c213f9f9c6f21bd1f13f633393a32d2509a
|
|
|
|
| |
Change-Id: I3c7ee819077d344072deee4cfd61f883c64da758
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I21052e55a62dd3d9a9846dec30c3ac12cc9c25af
|
|\ \
| |/
|/|
| | |
gingerbread
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
| |
Change-Id: I03a58b6efd2e1a12054bc7dbb320368be6cfdd17
|
|
|
|
| |
Change-Id: I7e1fe99cc482fc270894a820049275fc0c64233e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 avoids filling up the query cache unnecessary, but required some
structural changes to ease the passing around of a selection along
with its arguments.
Change-Id: I724185763b94146d17573cab68f675c24e49634e
|
|/
|
|
| |
Change-Id: I1f00b783250d0c4112cf7918f9ab05f83c209407
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I0dc0ef687ebc33a19b3af070df2722840a20eba1
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
My old error reporting strategy for DownloadThread was to log the
stack trace for the exception, so we'd know exactly what conditions
caused the StopRequest. hackbod suggested that we shouldn't log
tracebacks as they clutter the log. Instead, we should just always
include a little string tag explaining why the request is being
stopped -- this is more concise and more useful to developers.
There are three main changes here to acheive this goal:
* make StopRequest require a short, log-friendly error message upon
construction, and add such a message to all construction sites
* make a similar change to GenerateSaveFileError, so that the variety
of errors that originate with Helpers.generateSaveFile() get
similarly fine-grained and concise error reporting
* make network usable checking code return a distinct error code for
each distinct negative condition, and add a utility to return a
log-friendly error message for each such code.
Finally, I cleaned up some of the ways errors/exceptions are handled
in the process.
Change-Id: Ie70cbf3f2960e260e97f8449258e25218d0f900f
|
|/ /
| |
| |
| | |
Change-Id: Ic937b05308cecce244725e25767a3a1310a8463d
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'd written this to assume a non-null local URI, but I forgot the
legacy downloads can still have null local URI, so this handling needs
to remain until the legacy API is dead and gone.
Change-Id: Icfe8dc2a6fead03b09cabe684c713fb6f0e6c1ab
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | | |
Change-Id: I27a5fc3ab9bd0fd3e6d9db674ef32077d623e7b6
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | | |
Browser downloads, when clicked, will launch the downloads UI. When
clicked from the downloads UI (as opposed to a notification), we don't
want to launch a second copy of the downloads UI activity.
Change-Id: I0ae546bb423814f1bd1d6481085bf5f237d1213b
|