search

urbanairship / android-library

Urban Airship Android SDK
Other
109 stars 123 forks source link

java.lang.NoClassDefFoundError: lh.MessageDao$$ExternalSyntheticLambda0 #201

Closed darrentaft closed 2 years ago

darrentaft commented 2 years ago

❗For how-to inquiries involving Airship functionality or use cases, please contact (support)[https://support.airship.com/].

Preliminary Info

What Airship dependencies are you using?

com.urbanairship.android:urbanairship-fcm:16.1.1 com.urbanairship.android:urbanairship-automation:16.1.1 com.urbanairship.android:urbanairship-message-center:16.1.1

What are the versions of any relevant development tools you are using?

N/A

Report

What unexpected behavior are you seeing?

Another crash from background Airship activity:

Fatal Exception: java.lang.NoClassDefFoundError: lh.h
       at com.urbanairship.messagecenter.MessageDao.deleteMessages(MessageDao.java:68)
       at com.urbanairship.messagecenter.MessageDao_Impl.access$001(MessageDao_Impl.java:23)
       at com.urbanairship.messagecenter.MessageDao_Impl.deleteMessages(MessageDao_Impl.java:225)
       at com.urbanairship.messagecenter.InboxJobHandler.updateInbox(InboxJobHandler.java:264)
       at com.urbanairship.messagecenter.InboxJobHandler.updateMessages(InboxJobHandler.java:202)
       at com.urbanairship.messagecenter.InboxJobHandler.onUpdateMessages(InboxJobHandler.java:136)
       at com.urbanairship.messagecenter.InboxJobHandler.performJob(InboxJobHandler.java:117)
       at com.urbanairship.messagecenter.Inbox.onPerformJob(Inbox.java:204)
       at com.urbanairship.messagecenter.MessageCenter.onPerformJob(MessageCenter.java:228)
       at com.urbanairship.job.JobRunnable$1.run(JobRunnable.java:90)
       at com.urbanairship.util.SerialExecutor$1.run(SerialExecutor.java:41)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
       at com.urbanairship.util.AirshipThreadFactory$1.run(AirshipThreadFactory.java:50)
       at java.lang.Thread.run(Thread.java:818)

(Proguard enabled - lh.h maps to lh.MessageDao$$ExternalSyntheticLambda0)

This has absolutely destroyed our crash stats - 45692 crash events affecting 603 users in the last 12 hours since the update was released, and going up by thousands every hour.

99% of crashes are from Android 5 or 6, with < 1% from newer versions.

This hasn't affected our nightly or test builds (using a different Airship project).

What is the expected behavior?

No crash. We would never expect these background maintenance tasks to crash, and yet this is the 3rd time we've had Airship background sync crash many thousands of times.

What are the steps to reproduce the unexpected behavior?

None - happening in background after clients update to our latest app release. The previous app release used 16.1.0.

Do you have logging for the issue?

No logs available

darrentaft commented 2 years ago

117291 crash events affecting 1604 users so far, and customers have started contacting us saying they're seeing constant crash report messages appear on their device and cannot launch the app. Is there anything you can suggest? If I release an update going back to client 16.1.0 is it likely to stop the crashes? Or make it worse?

rlepinski commented 2 years ago

@darrentaft It has to do with the SDK pulling in a class that requires desugaring to be setup. We resolved this in 16.2.0 or you can setup desugaring https://developer.android.com/studio/write/java8-support#library-desugaring. I recommend updating to 16.2.0

darrentaft commented 2 years ago

OK great, thanks. I've set off a test run overnight with 6.2.0 and will push first thing tomorrow assuming all goes well.

rlepinski commented 2 years ago

Let me know if you find any issues and we can try to resolve them ASAP. Sorry for the hassle. The class in question is https://developer.android.com/reference/java/util/function/Consumer, so its limited to API 23 and older.

darrentaft commented 2 years ago

Thanks - we've confirmed that it has fixed our issue, and the app update is now live. Are you able to offer any assistance in explaining why this only affected our production project, and not our pre-production one? Is there something we need to turn on in our pre-prod project to trigger this same code path? As far as we are aware, the projects are configured the same.

rlepinski commented 2 years ago

I have no idea why it only showed up in prod for you. i would need more details on the differences on your app, what devices, etc... It should only occur on devices running Android 5, if thats not the case then let me know and I can try to dig deeper