Android Messaging SDK Fatal Exception: lateinit property conversationScreenCoordinator has not been initialized
Posted Nov 09, 2022
Hi, we are facing the following crash in our app after integrating the Zendesk Messaging SDK, this is not happening for most users, but it's still the crash with the highest occurrence in our app right now.
SDK: zendesk.messaging:messaging-android
Version: 2.6.0
minSdkVersion: 24
targetSdkVersion: 33
Crash stack trace:
Fatal Exception: kotlin.UninitializedPropertyAccessException
lateinit property conversationScreenCoordinator has not been initialized
zendesk.messaging.android.internal.conversationscreen.ConversationActivity$onCreate$2$1.invokeSuspend (ConversationActivity.kt:159)
kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith (ContinuationImpl.kt:33)
kotlinx.coroutines.internal.DispatchedContinuation.resumeUndispatchedWith (DispatchedContinuation.java:256)
kotlinx.coroutines.internal.DispatchedContinuationKt.resumeCancellableWith (DispatchedContinuation.kt:282)
kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable (Cancellable.kt:30)
kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable$default (Cancellable.kt:25)
kotlinx.coroutines.CoroutineStart.invoke (CoroutineStart.kt:110)
...
Can your team investigate that?
4
6
6 comments
Emilio Corengia
Hi there, we're experiencing the same issue after upgraded our target SDK version and messaging version. Please find details below. Thanks, Emilio.
zendesk.messaging:messaging-android = 2.7.0
targetSdkVersion = 31
compileSdkVersion = 33
minSdkVersion = 24
Fatal Exception: java.lang.RuntimeException: Unable to stop activity {xxxx/zendesk.messaging.android.internal.conversationscreen.ConversationActivity}: kotlin.UninitializedPropertyAccessException: lateinit property conversationScreenCoordinator has not been initializedat android.app.ActivityThread.callActivityOnStop(ActivityThread.java:4947)
at android.app.ActivityThread.performStopActivityInner(ActivityThread.java:4917)
at android.app.ActivityThread.handleStopActivity(ActivityThread.java:4999)
at android.app.servertransaction.StopActivityItem.execute(StopActivityItem.java:41)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:192)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:113)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2213)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:238)
at android.app.ActivityThread.main(ActivityThread.java:7853)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:984)
2
Jacques
Just checking, any updates about this?
This issue is still happening on Messaging SDK version 2.7.0
1
Eric Nelson
Have you been able to replicate this issue yourselves? If so, are you able to provide us with an example application where you're able to replicate this issue? If not have your customers provided you with any particular action that they're doing prior to experiencing this crash?
Thanks!
0
Jacques
Hi Eric,
After some attempts, I was able to reproduce it by forcing some Device configs, but I'm not sure what exactly our users are doing since it seems to be related to the app state restoration after some config change when the user is using the Zendesk conversation.
What I did to reproduce this was:
Again, I'm not sure what exactly our users are doing, but we had more than 100 occurrences of this crash affecting 88 users in the past 7 days and we are worried it can increase once users start using more and more this new feature of our app.
Thanks!
0
Eric Nelson
That seems like expected behavior. If background processes aren't enabled. Keeping a conversation's session active isn't really possible which would cause a variety of issues. Though I've passed this info along to the dev team. Is that stack trace being provided by the logger or your app? If it's by your app can you enable to logger to allow for us to get more information about under what circumstances your users are encountering the issue?
Thanks!
0
Jacques
Hey Eric Nelson,
That's the way I was able to force the same crash, we are not yet sure what our users are doing to get this crash. I know there could be some issues related to limited background processes but the activity should be able to restore its state properly without letting the app crash because of that... The stack trace is from Crashlytics, but although I've said before it was still happening on version 2.7.0, that may not be true... I've confirmed that there are no recent occurrences of this crash on our app after we updated to this most recent SDK version, so it seems that at least for our particular scenario this has been fixed!
Thanks!
0