DownloadManager: understand retry policy and error codes

Question

According to the documentation, if download is failed due to http error - the COLUMN_REASON should hold the specific http error code.

the problem I'm having is that in practice, the only reason value I see when download fail is ERROR_HTTP_DATA_ERROR

also, I see in logcat the actual failure http code in runtime, when the download is being stopped and re-try, but I don't see any way to get it from the download manager.

is it possible to get somehow this http code?

I'm using broadcast receiver to handle ACTION_DOWNLOAD_COMPLETE , but I don't see any way to listen to download paused, and I'm getting a feeling that if I'll query download manager failure reason between the retry attempts it does - then I'll get the actual status code.

is it possible to listen to "download pause" event without querying constantly the download manager?

I would expect that will be such broadcast.

the questions that I'd love to finally get answers to are:

• is it possible to listen to "download pause" event without querying constantly the download manager, and without active listener to the content resolver?
• is download manager (on API level 16+) supports https (ssl) ?
• what exactly is download manager retry policy? can I change it default retry policy?

Answer 1

is it possible to get somehow this http code?

Currently, no. The DownloadManager reports a STATUS_SUCCESSFUL even when a download failed, for example because the url/file was not found (HTTP 404) (this is a bug).
Also see DownloadManager sends STATUS_SUCCESSFUL for failed download

I know it's a relatively old thread but that issue still remains. I tested it 5 minutes ago and it still doesn't work properly.

---

is it possible to listen to "download pause" event without querying constantly the download manager?

Weirdly, no. The only available "events" to listen for are:

To get around this, you have to query the status yourself every X time by checking

if (cursor.getInt(cursor.getColumnIndex(DownloadManager.COLUMN_STATUS)) == DownloadManager.STATUS_PAUSED) {
    // Do stuff
}

---

is download manager (on API level 16+) supports https (ssl) ?

It used to not support https (read more in Android DownloadManager and SSL (https)), however it does now. You can simply verify by trying to retrieve a file from a https origin, for example https://mdn.mozillademos.org/files/3794/mixed_content_webconsole.jpg. You will see that it retrieves the file fine.

---

what exactly is download manager retry policy? can I change it default retry policy?

It is currently not possible to change the retry 'policy'. See the docs and you will find there are no methods or properties regarding this functionality.

Regarding the default retry policy, useful information can be found in the following package: com.android.providers.downloads.Constants. This links to the 5.1.1 version, if you need the information for another version you can manually navigate to that. For example here is the information for android 4.0.1 (the retry policy values are the same as in 5.1.1).

It states:

The number of times that the download manager will retry its network operations when no progress is happening before it gives up.

public static final int MAX_RETRIES = 5;

The minimum amount of time that the download manager accepts for a Retry-After response header with a parameter in delta-seconds.

public static final int MIN_RETRY_AFTER = 30; // 30s

The maximum amount of time that the download manager accepts for a Retry-After response header with a parameter in delta-seconds.

public static final int MAX_RETRY_AFTER = 24 * 60 * 60; // 24h

As you might have guessed, these are final (constant) and thus cannot be changed.

---

Conclusion: DownloadManager is pretty useful to do some basic downloading, but it's functionality is pretty limited.

_{I can suggest an alternative: there's a downloadmanager in the android-common libary over at https://github.com/Trinea/android-common I have not used it myself, but 2k+ stars on github usually means it's worth checking out.}