usedesk/Android_SDK

IllegalArgumentException crash when trying to send a file using chat GUI

Closed this issue · 2 comments

alex-petrakov commented

Hi, Usedesk team!

We are using Usedesk Chat GUI SDK in our app. Recently, we've updated the SDK version from 4.0.4 to 4.1.5 and our QA team started experiencing crashes on devices running Android 9 while trying to send an image or a video to the chat.

We were able to reproduce the issue on the following devices:

  • Xiaomi Redmi Note 8 Pro running Android 9
  • Xiaomi Mi A1 running Android 9

It happens for some files, but not the others. We weren't able to link the issue to a specific file. It seems that the issue manifestation depends not on the file itself, but on the way the file was saved on the device and on the internal implementation details of the ContentProvider used to retrieve the file.

Here is the stack trace 
java.lang.IllegalArgumentException: No subtype found for: "" 
    at okhttp3.MediaType$Companion.get(MediaType.kt:111)
    at ru.usedesk.common_sdk.api.multipart.MultipartConverter.convert(MultipartConverter.kt:31)
    at ru.usedesk.common_sdk.api.UsedeskApiRepository.doRequestMultipart(UsedeskApiRepository.kt:73)
    at ru.usedesk.chat_sdk.data.repository.api.ApiRepository.sendFile(ApiRepository.kt:259)
    at ru.usedesk.chat_sdk.domain.ChatInteractor$doSendFile$2.invokeSuspend(ChatInteractor.kt:462)
    at ru.usedesk.chat_sdk.domain.ChatInteractor$doSendFile$2.invoke(ChatInteractor.kt)
    at ru.usedesk.chat_sdk.domain.ChatInteractor$doSendFile$2.invoke(ChatInteractor.kt)
    at ru.usedesk.chat_sdk.domain.ChatInteractor.withFirstMessageLock(ChatInteractor.kt:515)
    at ru.usedesk.chat_sdk.domain.ChatInteractor.doSendFile(ChatInteractor.kt:445)
    at ru.usedesk.chat_sdk.domain.ChatInteractor.access$doSendFile(ChatInteractor.kt:59)
    at ru.usedesk.chat_sdk.domain.ChatInteractor$sendFileQueue$1.invoke(ChatInteractor.kt:114)
    at ru.usedesk.chat_sdk.domain.ChatInteractor$sendFileQueue$1.invoke(ChatInteractor.kt:114)
    at ru.usedesk.chat_sdk.domain.ChatInteractor$sam$kotlinx_coroutines_flow_FlowCollector$0.emit(ChatInteractor.kt)
    at kotlinx.coroutines.flow.SharedFlowImpl.collect$suspendImpl(SharedFlow.kt:382)
    at kotlinx.coroutines.flow.SharedFlowImpl$collect$1.invokeSuspend(SharedFlow.kt)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
    at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115)
    at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103)
    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)
    Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException

A little investigation on our side showed that the issue was likely introduced in version 4.1.0 when OkHttp's MediaType.parse() in MultipartConverter was replaced by String.toMediaType().

But it also seems that there might be a deeper cause. It looks like, for some files, the value for OpenableColumns.DISPLAY_NAME returned by a ContentResolver doesn't match the actual filename and is missing the filename extension, e.g. instead of cat.jpeg it is just cat. When FileLoader copies such files into the app cache, the copied files are missing the filename extension as well.

So some files in the cache end up with URIs like
file:///data/user/0/com.example/cache/1714142463651-731591104
instead of
file:///data/user/0/com.example/cache/1714142463651-731591104.jpeg.

When the cached files are sent to the server, their MIME type is determined based on the filename extension. When the extension is missing, ContentResolver.getMimeType() returns an empty string. This leads to a crash on v4.1.0 and above or the MediaType being null on v4.0.6 and below.

nichvolod commented

Hi there! Thank you for report.
Fix in progress. We will keep you updated