Allow DownloadManager do automatic track selection

Issue description

Whenever I start a download (~by calling DownloadService.sendAddDownload()~ see this comment) while offline, I don’t see the download queued when I check the downloads in the DownloadManager (either through currentDownloads or downloadIndex). Calling isWaitingForRequirements() returns false, but as soon as the connection is back, the download starts automatically as if it was queued and waiting for requirements.

I did some debugging and was able to see within DownloadManager that notMetRequirements was correctly 1 but the downloads list was empty – it seems that’s where the issue is.

I don’t think it’s relevant, but just in case: I’m downloading HLS content and this is how my helper creation looks like:

DownloadHelper.forHls(
  uri,
  dataSourceFactory,
  DefaultRenderersFactory(context),
  null,
  DefaultTrackSelector.ParametersBuilder().setForceHighestSupportedBitrate(true).build()
)

Reproduction steps

I can try to reproduce this with the demo app or try to create another demo for this issue if it’d really be helpful, but I think the issue is pretty straightforward to reproduce and observe:

• Make sure device is not connected to the internet
• Start a download
• Observe inconsistencies:
  • There’s no downloads queued even though they’ll start automatically once connection is back.
  • notMetRequirements is 1, even though isWaitingForRequirements() is false.

Link to test content

I believe this isn’t relevant.

A full bug report captured from the device

Hopefully also not relevant.

Version of ExoPlayer being used

2.10.0 and 2.10.1

Device(s) and version(s) of Android being used

Samsung Note 8 and Pixel 2 emulator on API 26. It’s reproducible every time.

[tonihei]

On our end, that’s the enhancement tracked by this issue. So that you can add the download to the DownloadManager (or Service) and the automatic track selection using these parameters takes place once the network becomes available.

[tfcporciuncula]

what I see in Netflix and other apps, is they just show an error when user tries to download anything without connection so they don’t queue those requests.

Yup! We at Blinkist have always queued downloads, though, so whenever connection is back we start the downloads automatically – it’s definitely a nicer experience. When I first came across ExoPlayer 2.10 new download capabilities I really thought we’d be able to get that behavior by default with it which would be great, and that’s my main motivation to try to push for this here.

it shouldn’t be difficult for an app with this kind of use case to track downloads that it hasn’t managed to initialize by itself.

It’s definitely an easy thing to do, as it is to track downloads in general. But 2.10 made things even easier for consumers when it comes to tracking and this inconsistency just seems to be an important missing piece in the whole picture.

If I try to download something while connected to a metered connection and I have NETWORK_UNMETERED as a requirement, the downloads will be queued properly (and start automatically once I’m back on a Wi-Fi) but they won’t if I’m not connected at all. If we try to abstract away the technical details and see this from a perspective of a consumer of the API, it’s just inconsistent and not right. That’s why I think it could deserve some priority.