Stuck downloads when changing network conditions

[daveoxley]

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]

This is probably a duplicate of #6733. Marking as such, but please do test with the dev-v2 branch to confirm that the issue is fixed.

[daveoxley]

@ojw28 Unfortunately this issue still exists on the latest dev-v2 branch (Tested on 826083d). The below patch fixes the issue and I'll put together a better change and submit a pr later. Any chance you could reopen this issue please?

diff --git a/library/core/src/main/java/com/google/android/exoplayer2/offline/DownloadService.java b/library/core/src/main/java/com/google/android/exoplayer2/offline/DownloadService.java
index db10517b6..8c4220c35 100644
--- a/library/core/src/main/java/com/google/android/exoplayer2/offline/DownloadService.java
+++ b/library/core/src/main/java/com/google/android/exoplayer2/offline/DownloadService.java
@@ -32,6 +32,8 @@ import com.google.android.exoplayer2.util.Assertions;
 import com.google.android.exoplayer2.util.Log;
 import com.google.android.exoplayer2.util.NotificationUtil;
 import com.google.android.exoplayer2.util.Util;
+
+import java.util.ArrayList;
 import java.util.HashMap;
 import java.util.List;
 
@@ -856,6 +858,7 @@ public abstract class DownloadService extends Service {
     @Nullable private final Scheduler scheduler;
     private final Class<? extends DownloadService> serviceClass;
     @Nullable private DownloadService downloadService;
+    private final List<Download> list = new ArrayList<>();
 
     private DownloadManagerHelper(
         Context context,
@@ -877,6 +880,10 @@ public abstract class DownloadService extends Service {
     public void attachService(DownloadService downloadService) {
       Assertions.checkState(this.downloadService == null);
       this.downloadService = downloadService;
+      for (Download download : list) {
+        downloadService.notifyDownloadChanged(download);
+      }
+      list.clear();
     }
 
     public void detachService(DownloadService downloadService, boolean unschedule) {
@@ -891,6 +898,8 @@ public abstract class DownloadService extends Service {
     public void onDownloadChanged(DownloadManager downloadManager, Download download) {
       if (downloadService != null) {
         downloadService.notifyDownloadChanged(download);
+      } else {
+        list.add(download);
       }
     }
 

[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.