Stuck downloads when changing network conditions

Issue description

DownloadService race condition causing downloads to not resume when network requirements are met after previously not being met.

The issue appears to be that DownloadManagerHelper.onDownloadChanged is called before the new service is attached to the DownloadManagerHelper. Therefore DownloadService.notifyDownloadChanged is never called and startForeground is never called on the new service. The app process is then killed after roughly 10 seconds as the scheduler has been cancelled.

Reproduction steps

Using the exoplayer app:

• Start downloading some content
• Click back to exit the app. Downloading notification should be shown.
• Turn off network. Downloading notification should be hidden.
• Wait approximately 2 minutes.
• Turn on network. Downloading notification is not reshown when it should be.

Link to test content

Tested using WV: Clear SD & HD (MP4,H264) in the sample app.

Version of ExoPlayer being used

2.10.7. Also reproduced the issue on 2.11.1.

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

Pixel 3XL Android 10 (QQ1A.191205.008)

[ojw28]

Thanks for checking! I see what’s going on now, and yes you’re absolutely right.

What’s happening in this case is that the DownloadManager is calling DownloadManagerHelper. onRequirementsStateChanged, which is then failing to restart the service because the process is in the background (the “wait approximately 2 minutes” part of the reproduction instructions are important, else the process is still classified as being in the foreground). DownloadManagerHelper.onDownloadChanged is then called as the DownloadManager resumes its downloads. At some point later the Scheduler then restarts the service, which does work because it starts it as a foreground service.

Your PR will cause the DownloadManagerHelper.onDownloadChanged events to be processed when the Scheduler restarts the service, but it’s a relatively uncontrolled fix because there aren’t particularly strong guarantees on when this will happen. There are also some related issues, such as what happens if there’s a Scheduler and foregroundNotificationId == FOREGROUND_NOTIFICATION_ID_NONE. I’d like to spend a bit of time this week seeing if there’s a more controlled fix, that’ll also solve this type of related issue at the same time.

[ojw28]

It doesn’t appear to happen as often any more but it still happens.

We do now have reproduction steps for one case in which downloads fail to resume when network connectivity is restored. We’re tracking this using https://github.com/google/ExoPlayer/issues/7453.