Android DownloaderManager
is a system service. It is supposed to be running always. But there are some cases when it can't run.
The download happens via the HTTP persistent connection. It means the same established connection is used for successive HTTP request/response. The connection break means error occurs, and thus, you can't track the status by reference id.
You track via Android DownloadManager
service, where Android DownloadManager
service gets STATUS
code from the server.
Android DownloadManager uses the content-length
based download from the server. The Content-Length
header will not allow streaming (link). The content-length based download has the advantage of resume, pause, partial download -- see the link1 above. So, even when you reboot the system, again it restarts (increments) the download.
The content-length
based download is store and forward
(link). You should forward the buffered content to the persistent storage because you have limited fixed buffers.
The Android DownloadManager
has ERROR_CANNOT_RESUME int
flag (link). The ERROR_CANNOT_RESUME
is based on the COLUMN_STATUS
flag. There are two types of COLUMN STATUS: STATUS_PAUSED
or STATUS_FAILED
. Before system turns off, the system via the BroadcastReceiver
sends Android DownloadManager
service about turn off. The Android DownloadManager
then activates STATUS_PAUSED
flag. And, when next time you restart the device, the system service runs automatically, checks if STATUS_PAUSED then starts downloading again.
Answer: so until there happens error (in client side, connection or server-side) or you are not done downloading the file (it means until STATUS_SUCCESSFUL
), you keep getting status from the Android DownloadManager
. You can't get status when there happens STATUS_FAILED
-- it says download will not be retried (link).
How STATUS_FAILED
happens?
Client's DownloadManager
service detects HTTP status code 4XX (Server guesses client is erred) and 5XX (Server detects server is erred) (link), now STATUS_FAILED
becomes true.
Some other situations:
When Clients keeps turned-off and based on server-logic, the server can terminate the connection with the timeout. So, this control is explicitly based on different HTTP server. We can't ask these many days here. We don't know the server-side logic. The status_codes are based on the server. When server decides client has failed, and the server then does timeout
the connection making STATUS_FAILED
active at the server-side. clients must be prepared for TCP connections to disappear at arbitrary times, and must be able to re-establish the connection and retry the HTTP request. A prematurely closed connection should not be treated as an error; an error would only be signaled if the attempt to re-establish the connection fails.
Your question doesn't have an exact answer.
Note: TCP connections to disappear at arbitrary times
(link) is the main logic here that can resume your connection after a certain number of days of your device turned off.
1) On STATUS_FAILED
, you can't continue track further data.
2) On If COLUMN_STATUS
is neither STATUS_FAILED
nor STATUS_PAUSED
, this column's value is undefined, here you may not be able to track further data.
-- Anything in other than above two conditions, the download is in progress.