IssueTracker

Which device are you using?

I have three currently:

* Nexus 4
* Nexus S
* HTC One X

Obviously only two of them have the default Android lock screen, but they all let stuff happen from the status bar even when the phone is locked.

Thanks

Me too, I don't like having the status bar on my lock screen. Also, it seems dumb to allow the status bar to be hidden if I have a pin or pattern lock but display it if I have swipe to unlock.  The unlock method really has nothing to do with the status bar.  I don't want to see it on the lock screen.

Why is this obsolete?  What new change has been made?

Well this post is from a year and a half ago and there have been several upgrades to Android. I would say it became obsolete 8 months ago, but then I haven't used stock Android since it came out.

There may have been updates, but it's not been fixed.

Yes, please increase the priority. This bug makes DownloadManager become useless on Samsung and Acer devices.

Hi all, I'm only emphasizing what everybody above have said, the DM is useless in these conditions, I have been failing it on 3.1, 3.2 on Samsung P7500, Motorola Xoom and Acer Iconia. In the end I wrote my own download manager; the priority should be raised as it is a major bug not being able to get data onto your device.

Is this fixed in the recent versions? I might have the same issues, how can I solve it?

07-18 07:43:10.227: INFO/DownloadManager(1047): Initiating request for download 3174
07-18 07:43:10.306: INFO/DownloadManager(1047): Initiating request for download 3175
07-18 07:43:10.406: INFO/DownloadManager(1047): Initiating request for download 3176
07-18 07:43:10.576: INFO/DownloadManager(1047): Initiating request for download 3177
07-18 07:43:10.576: INFO/DownloadManager(1047): Initiating request for download 3178
07-18 07:43:10.765: INFO/DownloadManager(1047): Initiating request for download 3179
07-18 07:43:11.416: INFO/DownloadManager(1047): Initiating request for download 3163
07-18 07:43:11.416: INFO/DownloadManager(1047): Initiating request for download 3165
07-18 07:43:11.427: INFO/DownloadManager(1047): Initiating request for download 3150
07-18 07:43:11.427: WARN/DownloadManager(1047): Aborting request for download 3163: http error 416
07-18 07:43:11.436: WARN/DownloadManager(1047): Aborting request for download 3165: http error 416
07-18 07:43:11.436: INFO/DownloadManager(1047): Initiating request for download 3172
07-18 07:43:11.436: INFO/DownloadManager(1047): Initiating request for download 3175
07-18 07:43:11.446: WARN/DownloadManager(1047): Aborting request for download 3150: http error 416
07-18 07:43:11.446: INFO/DownloadManager(1047): Initiating request for download 3177
07-18 07:43:11.446: INFO/DownloadManager(1047): Initiating request for download 3178
07-18 07:43:11.456: WARN/DownloadManager(1047): Aborting request for download 3172: http error 416
07-18 07:43:11.478: DEBUG/DownloadManager(1047): File already exists: xxx
07-18 07:43:11.506: INFO/DownloadManager(1047): Initiating request for download 3179
07-18 07:43:11.515: WARN/DownloadManager(1047): Aborting request for download 3175: requested destination file already exists
07-18 07:43:11.515: WARN/DownloadManager(1047): Aborting request for download 3178: http error 416
07-18 07:43:11.535: DEBUG/DownloadManager(1047): File already exists: xxx
07-18 07:43:11.535: WARN/DownloadManager(1047): Aborting request for download 3179: requested destination file already exists
07-18 07:43:11.535: DEBUG/DownloadManager(1047): File already exists: xxx
07-18 07:43:11.535: WARN/DownloadManager(1047): Aborting request for download 3177: requested destination file already exists
07-18 07:43:11.807: INFO/DownloadManager(1047): Initiating request for download 3168
07-18 07:43:11.839: WARN/DownloadManager(1047): Aborting request for download 3168: http error 416

What is this error 416?

Kind regards

We ended up writing our own. It took about 2 person/days. We never found a work around.

Hamilton, is it possible to provide your custom implementation to prevent people, including ourselves, reinventing the wheel? :-).

Kind regards

Seeing this as well. For me it's like this:

Download is started and seems to complete ok, I get the DOWNLOAD_COMPLETED broadcast. However, right after this I see DownloadManager logging:

I/DownloadManager( 5893): Initiating request for download 1419
W/DownloadManager( 5893): Aborting request for download 1419: Trying to resume a download that can't be resumed

Then I get another DOWNLOAD_COMPLETED with the same download ID. Also, it seems the downloaded file gets deleted during this second, failed attempt.

Any ideas what triggers this? Or any workarounds? Or is everyone just writing their own download managers...

Did anyone managed to get a good fix or workaround on that?

I met this issue very often, do any one has some workaround for this issue?
if No, then the download manager is un-usable.

we need to support various types of machines, and I have found no workaround for this, it will cause very bad user experience, why google can not fix it? or provider a work around for this issue? do anyother has some suggestions

here is a work around https://github.com/yingyixu/android-download-manager

We have this problem as well. The complete source of the affected application is available here: https://github.com/gpodder/detlef/blob/master/detlef/src/at/ac/tuwien/detlef/download/DetlefDownloadManager.java#L69

Problem is reproducible on Asus Transformer TF-101 w/ Android ICS v4.0.3
Problem is not reproducible on Asus Nexus7 w Android JB v4.2.1

Android download manager uses ETag header for concurrent thread to resume on the same download. You need provide a ETag header at server side or wait for thread to finish.

The detail is at
http://papaya-backend.net/2013/04/12/why-http-etag-header-may-cause-your-downloading-apps-on-android-failed/

[Comment deleted]

I am using Download manager and register receiver callback for following Action :

DownloadManager.ACTION_DOWNLOAD_COMPLETE to know if download complete and

ConnectivityManager.CONNECTIVITY_ACTION to check network connectivity.

Here I am facing very wired behavior :

As I off wifi, receiver for ACTION_DOWNLOAD_COMPLETE called, don't know why??
any one have idea about it/any suggestion.

[Comment deleted]

the links from socrates is good. once we started using etags, download manager works like charm.

Yeah, can someone tell me how I start using etags when I'm downloading images from Picassa? (That was a rhetorical question.)

This seems to be duplicated in 34791

I still have the same issue here with my Galaxy S2..

I have tested this on a 15" Outform tablet running Android 4.0.4 and on an Nexus 7 running 4.4.2.

The bug happens similar to the way other posters have mentioned:

1) A download success status from DownloadManager service hits the receiver
2) The receiver tries to move the file into position. This fails.
3) The receiver immediately gets a message that the same download_id (with no other data) failed. (I've tried waiting around to see if the filesystem is being slow and the DownloadManager reports a success before it's completely written to no avail. The file on the filesystem is truncated: sometimes it's half the size, 1/4 the size it should be.)
4) The receiver has some recovery code that re-requests the download which goes into an infinite loop on 4.0.4 device. 4.4.2 device seems more robust: it eventually succeeds after re-requesting the file once, sometimes twice.

Note I have a FileObserver watching the files and reporting progress to the UI when present. The appearance is that the file is being written properly, reaching 99%+ complete before the receiver finally gets the download success so I don't understand the truncation of the file.

adding etag on header solve the problem.

(fail and tested on xperia l26i 4.1.2, then, after add etag to header, works)

I did find a work around for my case. I found that I was getting a download successful followed by a failure (ERROR_CANNOT_RESUME) for the same refId. So I just copied the successful file before if got overwritten. This worked well but probably won't work if the app is closed and the broadcasts are not received.

I'm astounded this bug still exists. I first encountered it 2 years ago so I wrote my own downloader which was buggy and possibly ate batteries sometime. The Download Manager is great because I don't need a background service. But this bug is a killer.

I am surprised the Android team hasn't come down hard on buggy implementations on such a core service. Please do. It makes developers lives hard. I have to send debug APK's to users to test and send log's back. This is not how it should be.

Cheers.

adding 'ETag' in response with MD5 and checking request for 'If-Match' header and if it has the same send NOT_MODIFIED.
But even this does not filters all double requests

In my case (Oreo):
1 Download file.ext to ./directory.
2 See ./file.ext and ./directory/file.ext.

Still facing same issue

I have this issue as well, pretty often actually.
DownloadData(uri=null, id=191, title=***.pdf, description=, uriString=https://***, mediaType=application/pdf, totalSizeBytes=-1, localUriString=null, status=16, reason=1008, bytesDownloadedSoFar=170760, lastModifiedTimestamp=1709387056565, mediaProviderUri=null)