IllegalStateException at DefaultDownloadIndex.getDownloadForCurrentRow

[iNdieboyjeff]

Issue description

The following crash is being seen in Crashlytics

Fatal Exception: java.lang.IllegalStateException
       at com.google.android.exoplayer2.util.Assertions.checkState(Assertions.java:81)
       at com.google.android.exoplayer2.offline.Download.<init>(Download.java:133)
       at com.google.android.exoplayer2.offline.DefaultDownloadIndex.getDownloadForCurrentRow(DefaultDownloadIndex.java:359)
       at com.google.android.exoplayer2.offline.DefaultDownloadIndex.access$100(DefaultDownloadIndex.java:35)
       at com.google.android.exoplayer2.offline.DefaultDownloadIndex$DownloadCursorImpl.getDownload(DefaultDownloadIndex.java:409)
       at com.google.android.exoplayer2.offline.DownloadManager$InternalHandler.initialize(DownloadManager.java:697)
       at com.google.android.exoplayer2.offline.DownloadManager$InternalHandler.handleMessage(DownloadManager.java:630)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loop(Looper.java:216)
       at android.os.HandlerThread.run(HandlerThread.java:65)

It appears that the download progress is null which is failing the assertion. From what I can see this progress is returned from the database.

Over the last 90 days: This issue has 1070 crashes affecting 110 users.

Reproduction steps

We have not been able to reproduce this issue ourselves, but it is currently our biggest crash in Crashlytics and has recently generated a velocity alert.

Link to test content

If required please let us know and we can try to provide access to a test user account

A full bug report captured from the device

As above this is an issue from Crashlytics so unable to capture a bug report ourselves

Version of ExoPlayer being used

v2.10.4

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

80% Samsung (Galaxy S8, S9, S8+)
5% Huawei (p20 lite, Y7 Prime 2019, P smart 2019)
4% OnePlus (A6000, 7T Pro, 5T)
4% OPPO (CPH1725)
56% Other

65% Android 9
23& Android 8
6% Android 7
3% Android 5
3% Other

25% In background
0% Rooted
93% Proximity On

[ojw28]

Thanks for the report. Does your app happen to call DownloadService.sendRemoveAllDownloads, DownloadService.buildRemoveAllDownloadsIntent or DownloadManager.removeAllDownloads? I think I see a possible bug along those code paths that might explain this.

[iNdieboyjeff]

I believe we do yes.

…

On Fri, 20 Dec 2019, 13:40 Oliver Woodman, ***@***.***> wrote: Thanks for the report. Does your app happen to call DownloadService.sendRemoveAllDownloads, DownloadService.buildRemoveAllDownloadsIntent or DownloadManager.removeAllDownloads? I think I see a possible bug along those code paths that might explain this. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6785?email_source=notifications&email_token=AAGP2RRMUI2AHOVUCZOLNXDQZS4NPA5CNFSM4J4766QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHM2LCA#issuecomment-567911816>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGP2RQ4LOW3GPFI4X3GW73QZS4NPANCNFSM4J4766QA> .

[ojw28]

Thanks. I think the problem occurs when removeAllDownloads is called with one or more downloads in the failed state. We will try and get a fix into 2.11.1.

[ojw28]

This is most likely fixed by the change above. It will be included in 2.11.1, which we'll push today. Please let us know here if your users still see this problem after you update.