NoClassDefFoundError: android.app.ANRManagerProxy

¿Alguien sabe por qué pasa esto? Veo este accidente informado por mi aplicación, pero no tengo ni idea de lo que es.

java.lang.NoClassDefFoundError: android.app.ANRManagerProxy Thread: Binder_3, Exception: java.lang.NoClassDefFoundError: android.app.ANRManagerProxy at android.app.ANRManagerNative.asInterface(ANRManagerNative.java:30) at android.app.ANRManagerNative$1.create(ANRManagerNative.java:94) at android.app.ANRManagerNative$1.create(ANRManagerNative.java:88) at android.util.Singleton.get(Singleton.java:34) at android.app.ANRManagerNative.getDefault(ANRManagerNative.java:37) at android.os.MessageLogger.dump(MessageLogger.java:253) at android.app.ANRAppManager.dumpMessageHistory(SourceFile:38) at android.app.ActivityThread$ApplicationThread.dumpMessageHistory(ActivityThread.java:1176) at android.app.ApplicationThreadNative.onTransact(ApplicationThreadNative.java:609) at android.os.Binder.execTransact(Binder.java:351) at dalvik.system.NativeStart.run(Native Method) 

    2 Solutions collect form web for “NoClassDefFoundError: android.app.ANRManagerProxy”

    Este error se puede ver en un pequeño grupo de dispositivos (no tengo una lista, pero tienden a ser marcas sin nombre) cuyos desarrolladores de firmware, por razones desconocidas, eliminaron el ANRManagerProxy del marco del dispositivo (lo confirmé por Buscar un firmware y descompilarlo yo mismo).

    Lo mejor que puedes hacer es intentar cazar cualquier código posible que podría bloquear el hilo y hacer que el dispositivo no AsyncTask , e intentar utilizar un AsyncTask o similar para ejecutar el código de forma asíncrona y evitar el ANR. Los dispositivos en cuestión son siempre de gama baja, por lo que su código tardará más en ejecutarse y tendrá una mayor probabilidad de que esto suceda.

    Sugeriría a Hugo como una gran biblioteca para depurar los tiempos de ejecución del método, con el fin de restringir su enfoque sobre dónde se gasta más tiempo. Esto ayudará a mejorar el código para todos los usuarios, así como reducir el riesgo del accidente en cuestión.

    Esto sucede porque

    • Tu ID de aplicación realiza un trabajo pesado en el subproceso principal (GUI)

    y

    • Dispositivo de destino ha desordenado el firmware

    Aquí está una lista de dispositivos, donde experimenté con más frecuencia el error – por lo que no sólo los dispositivos de gama baja , tenga cuidado de que lo ignorará 🙂

    Lenovo A316i, N5i, V769M, G3, V5, G3, X-2, F-G906, Z350, V10, G910, EVOLVEO StrongPhone D2, A70C, G9006, V13, C3000, n968, SM-T322, H9503, H9503, S5, F1, Lenovo TP-6000, Galaxy Tab SM-T700C …

    Lo único que puedes hacer al respecto es hacer que tu aplicación responda. La mejor manera de hacerlo es usarlo durante el desarrollo y la prueba de modo estricto, es decir, para hacer algo como esto:

     public void onCreate() { if (DEVELOPER_MODE) { StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() // or .detectAll() for all detectable problems .penaltyLog() .build()); StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder() .detectLeakedSqlLiteObjects() .detectLeakedClosableObjects() .penaltyLog() .penaltyDeath() .build()); } super.onCreate(); } 
    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.