Skip to content
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.

Crash in [@ java.lang.IllegalArgumentException: at android.app.DownloadManager.validateArgumentIsNonEmpty(DownloadManager.java)] #9821

Closed
kbrosnan opened this issue Mar 1, 2021 · 3 comments

Comments

@kbrosnan
Copy link
Contributor

kbrosnan commented Mar 1, 2021

Crash report: https://crash-stats.mozilla.org/report/index/160819c3-1b57-4902-917a-4bd130210301

Java stack trace:

java.lang.IllegalArgumentException
	at android.app.DownloadManager.validateArgumentIsNonEmpty(DownloadManager.java:1430)
	at android.app.DownloadManager.addCompletedDownload(DownloadManager.java:1388)
	at android.app.DownloadManager.addCompletedDownload(DownloadManager.java:1368)
	at mozilla.components.feature.downloads.AbstractFetchDownloadService.updateDownloadNotification$feature_downloads_release(AbstractFetchDownloadService.kt:21)
	at mozilla.components.feature.downloads.AbstractFetchDownloadService.access$updateDownloadNotification(AbstractFetchDownloadService.kt:5)
	at mozilla.components.feature.downloads.AbstractFetchDownloadService$onStartCommand$2.invokeSuspend(AbstractFetchDownloadService.kt:7)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
	at kotlinx.coroutines.AwaitKt.resume(Await.kt:7)
	at kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:18)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl(CancellableContinuationImpl.kt:6)
	at kotlinx.coroutines.CancellableContinuationImpl.resumeUndispatched(CancellableContinuationImpl.kt:3)
	at kotlinx.coroutines.android.HandlerContext$scheduleResumeAfterDelay$$inlined$Runnable$1.run(Runnable.kt:1)
	at android.os.Handler.handleCallback(Handler.java:809)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loop(Looper.java:166)
	at android.app.ActivityThread.main(ActivityThread.java:7377)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:469)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:963)

┆Issue is synchronized with this Jira Task

@Mugurell Mugurell self-assigned this Mar 3, 2021
@Mugurell
Copy link
Contributor

Mugurell commented Mar 3, 2021

Based on the stacktraces I saw the exception being thrown because of this DownloadManager check for even an empty mime type.

This seems to be a general issue, not tied to a specific device or Android version but I could not reproduce it.
Haven't saw anything immediately wrong with our current implementation of inferring the mimeType and given that the code in AC is pretty tight about nullability I think that in specific cases the mime type gets to be empty.

As a speculative fix (without actually having a broken download to verify) we can treat the cases of empty mime types the same as we treat the null ones -> replace them with a default */* one.

@Mugurell
Copy link
Contributor

Mugurell commented Mar 3, 2021

And since the exception is thrown in AC without a STRs in Fenix I'll move the ticket to AC and fix it there.

@Mugurell Mugurell transferred this issue from mozilla-mobile/fenix Mar 3, 2021
Mugurell added a commit to Mugurell/android-components that referenced this issue Mar 3, 2021
…type if otherwise empty

Speculative fix (cannot reproduce the issue) for crashes where based on the
stacktrace the download's mime type was empty.
@Mugurell Mugurell moved this from In Development (WIP limit - 15) to Dev Complete (WIP limit - 5) in Android Engineering Team Kanban board Mar 3, 2021
Mugurell added a commit to Mugurell/android-components that referenced this issue Mar 4, 2021
…type if otherwise empty

Speculative fix (cannot reproduce the issue) for crashes where based on the
stacktrace the download's mime type was empty.
Mugurell added a commit to Mugurell/android-components that referenced this issue Mar 4, 2021
…type if otherwise empty

Speculative fix (cannot reproduce the issue) for crashes where based on the
stacktrace the download's mime type was empty.
Mugurell added a commit to Mugurell/android-components that referenced this issue Mar 9, 2021
…type if otherwise empty

Speculative fix (cannot reproduce the issue) for crashes where based on the
stacktrace the download's mime type was empty.
@mergify mergify bot closed this as completed in dcc78fd Mar 10, 2021
Android Engineering Team Kanban board automation moved this from Dev Complete (WIP limit - 5) to Done Mar 10, 2021
@Mugurell
Copy link
Contributor

This were quite a lot of crashes, it should be easy to see a decline now that a patch for this was merged.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
No open projects
Development

No branches or pull requests

3 participants