Unexpected crash in BaseDexClassLoader

Question

This crash has happened to 1800 users of our app with 1.2 monthly active users (according to Google Developer Console). Quite rare, but it occurs.

Android 4.1 up to 6, but NO Android 7 in reports.

What might be the nature of this ClassNotFoundException in BaseDexClassLoader. Can we avoid it?

java.lang.RuntimeException: at android.app.LoadedApk.makeApplication(LoadedApk.java:572) at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4831) at android.app.ActivityThread.access$1500(ActivityThread.java:178)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1531)
at android.os.Handler.dispatchMessage(Handler.java:111) at android.os.Looper.loop(Looper.java:194) at android.app.ActivityThread.main(ActivityThread.java:5637) at java.lang.reflect.Method.invoke(Method.java:0) at java.lang.reflect.Method.invoke(Method.java:372) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:959) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:754)

Caused by: java.lang.ClassNotFoundException: at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56) at java.lang.ClassLoader.loadClass(ClassLoader.java:511) at java.lang.ClassLoader.loadClass(ClassLoader.java:469) at android.app.Instrumentation.newApplication(Instrumentation.java:985)
at android.app.LoadedApk.makeApplication(LoadedApk.java:567)

Answer 1

NOTE: The answer below could be inaccurate and not verifiable, because this Exception is pretty impossibile to simulate in a test environment. If someone has more informations on the topic or maybe a definitive solution please post it here. I apologize in advance if this informations will be proved to be false at all but they are based on my experience and understanding of the thing

There are multiple variants of the java.lang.ClassNotFoundException in Android, most of them are caused by a wrong Proguard configuration, IDE not closing correctly the previous launched instance of the device during build time etc...

All of this "normal" ClassNotFoundExceptions are distinguishable because in some part of the exception there is something related to the app itself like:

java.lang.RuntimeException: Unable to instantiate application com.my.package.CustomApplication: java.lang.NullPointerException

or

java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{com.my.package/com.my.package.MyClass}: java.lang.ClassNotFoundException: Didn't find class "com.my.package.MyClass" on path: DexPathList[[zip file "/data/app/com.my.package-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.my.package-1, /vendor/lib, /system/lib]]

While the one you are facing it's something not related at all with your application because it's clear there are no references to your app components. It's a bug in how the system load the APKs and try to execute some of your code (like a Receiver) when your app is uninstalled and reinstalled because of an update.

What i think it's happening here is:

1. The app is installed
2. The system wants to start one of your components (for example a <receiver>)
3. The app is uninstalled because of a new update (this step should last only few seconds)
4. The system is not able to find anymore your app and throw the error you posted
5. The update is installed and your app start working again

This combination of factors could explain why you have only "few" crashes considering the total active users.

What can you do about this? I think pretty nothing because it's a fault in how the system handle this special case. This comment in one of the multiple related issues has the same conclusion.

You could try to create a custom ClassLoader where you can handle the Exception by yourself and terminate the app process silently without crashing the app, in this way your users shouldn't noticing anything (i don't know if the user is really noticing this, maybe it's an internal exception handled by the system and the user doesn't see nothing)

The fact that you did not encounter reports for Android 7 could be a sign that they fixed the problem in the latest Android version of LoadedApk class

PS: Sincerely i don't think this is related to multidexing, but you can perform some tests to be sure