-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IllegalStateException at DefaultDownloadIndex.getDownloadForCurrentRow #6785
Comments
Thanks for the report. Does your app happen to call |
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>
.
|
Thanks. I think the problem occurs when |
The Download constructor considers it invalid to have a failure reason if the download isn't in the failed state. Unfortunately, calling DefaultDownloadIndex.removeAllDownloads when there's a failed download will change the state without clearing the reason. If the downloads are then read back from the DefaultDownloadIndex we end up violating the Download constructor assertion. This change clears the failed reason for any existing rows in the invalid state, and also fixes the root cause that allows invalid rows to enter the table in the first place. Issue: #6785 PiperOrigin-RevId: 286576242
This is most likely fixed by the change above. It will be included in |
The Download constructor considers it invalid to have a failure reason if the download isn't in the failed state. Unfortunately, calling DefaultDownloadIndex.removeAllDownloads when there's a failed download will change the state without clearing the reason. If the downloads are then read back from the DefaultDownloadIndex we end up violating the Download constructor assertion. This change clears the failed reason for any existing rows in the invalid state, and also fixes the root cause that allows invalid rows to enter the table in the first place. Issue: #6785 PiperOrigin-RevId: 286576242
Issue description
The following crash is being seen in Crashlytics
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
The text was updated successfully, but these errors were encountered: