Error inesperado en BaseDexClassLoader

Este accidente ha ocurrido a 1800 usuarios de nuestra aplicación con 1,2 usuarios activos mensuales (de acuerdo con Google Developer Console). Muy raro, pero ocurre.

Android 4.1 hasta 6, pero NO Android 7 en los informes.

¿Cuál podría ser la naturaleza de este ClassNotFoundException en BaseDexClassLoader. ¿Podemos evitarlo?

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

Causado por: java.lang.ClassNotFoundException: at dalvik.system.BaseDexClassLoader.findClass (BaseDexClassLoader.java:56) en java.lang.ClassLoader.loadClass (ClassLoader.java:511) en java.lang.ClassLoader.loadClass (ClassLoader. Java: 469) en android.app.Instrumentation.newApplication (Instrumentation.java:985)
En android.app.LoadedApk.makeApplication (LoadedApk.java:567)

One Solution collect form web for “Error inesperado en BaseDexClassLoader”

NOTA: La respuesta a continuación puede ser imprecisa y no verificable, ya que esta excepción es bastante imposible de simular en un entorno de prueba. Si alguien tiene más información sobre el tema o tal vez una solución definitiva, publícala aquí. Pido disculpas por adelantado si estas informaciones resultaran ser falsas en absoluto, pero se basan en mi experiencia y comprensión de la cosa

Existen múltiples variantes de la java.lang.ClassNotFoundException en Android, la mayoría de ellas son causadas por una configuración incorrecta de Proguard, IDE no cerrando correctamente la instancia anterior lanzada del dispositivo durante el tiempo de construcción, etc …

Todos estos "normal" ClassNotFoundException s se distinguen porque en alguna parte de la excepción hay algo relacionado con la propia aplicación como:

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

o

 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]] 

Mientras que el que se enfrenta es algo no relacionados en absoluto con su aplicación, ya que está claro que no hay referencias a los componentes de la aplicación. Es un error en la forma en que el sistema carga los APK e intenta ejecutar parte de su código (como un receptor) cuando su aplicación se desinstala y vuelve a instalar debido a una actualización.

Lo que creo que está sucediendo aquí es:

  1. La aplicación está instalada
  2. El sistema desea iniciar uno de sus componentes (por ejemplo un <receiver> )
  3. La aplicación se desinstala debido a una nueva actualización (este paso debe durar sólo unos segundos)
  4. El sistema no puede encontrar más tu aplicación y echar el error que publicaste
  5. La actualización está instalada y la aplicación empieza a funcionar de nuevo.

Esta combinación de factores podría explicar por qué sólo tiene "pocos" accidentes considerando el total de usuarios activos.

¿Qué se puede hacer al respecto? Creo que nada bonito, porque es una falla en cómo el sistema manejar este caso especial. Este comentario en una de las múltiples cuestiones relacionadas tiene la misma conclusión.

Usted podría intentar crear un ClassLoader personalizado donde usted puede manejar la Excepción por usted mismo y terminar el proceso de la aplicación silenciosamente sin estrellarse la aplicación, de esta manera sus usuarios no deben notar nada (no sé si el usuario realmente está notando esto , Tal vez es una excepción interna manejada por el sistema y el usuario no ve nada)

El hecho de que no haya encontrado informes para Android 7 podría ser una señal de que arreglaron el problema en la última versión de Android de la clase LoadedApk

PD: Sinceramente no creo que esto esté relacionado con el multidexado, pero puede realizar algunas pruebas para estar seguro

  • Ninguna actividad encontrada para manejar Intent, Android
  • Manejar "No mantener actividades" en la aplicación Android
  • La aplicación se bloquea al iniciar Debido a java.lang.IllegalArgumentException: la columna '_id' no existe
  • ¿Cómo desactivar la interacción con los vídeos html5 en webview o capturar correctamente sus excepciones?
  • Servicios de Google Play 7.5.0 AnalyticsService NPE onStartCommand
  • Actualización de Android 6.0 que causa DB sqlite falla durante init
  • Java.lang.VerifyError en la clase Application para un pequeño porcentaje de usuarios
  • Comprensión de bloqueos y ANR con Proguard habilitado
  • Android Surfaceview Crash sin salida de error
  • Android java.lang.AssertionError: java.lang.NoSuchMethodException - Proguard
  • Se produjo un error en la aplicación firmada de Android. Trabajó antes de firmar
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.