Noclassdeffonderror: android.App.ANRManagerProxy

est ce que quelqu'un sait pourquoi cela se produit? Je vois cet incident rapporté par mon application, mais je n'ai aucune idée de ce que c'est.

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.create(ANRManagerNative.java:94) 
at android.app.ANRManagerNative.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)
25
demandé sur mattfred 2015-03-27 00:56:49
la source

2 ответов

cette erreur peut être vue sur un petit groupe de périphériques (Je n'ai pas de liste, mais ils ont tendance à être des marques sans nom) dont les développeurs de firmware, pour des raisons inconnues, ont supprimé le ANRManagerProxy à partir du cadre de l'appareil (j'ai confirmé ceci en traquant un firmware et en le décomposant moi-même).

le mieux que vous pouvez faire est d'essayer de traquer n'importe quel code possible qui pourrait verrouiller le thread et causer l'appareil à devenir non-responsive, et essayer d'utiliser un AsyncTask ou similaire pour exécuter le codez de façon asynchrone et évitez L'ANR. Les appareils en question sont toujours bas de gamme, et donc votre code prendra plus de temps à fonctionner et aura une plus grande chance de provoquer cela se produire.

je suggère Hugo comme une excellente bibliothèque pour les temps d'exécution des méthodes de débogage, afin de vous concentrer sur l'endroit où le plus de temps est passé. Cela permettra d'améliorer votre code pour tous les utilisateurs, ainsi que de réduire le risque de la panne en question.

13
répondu Kane O'Riley 2015-09-13 08:14:28
la source

cela arrive, parce que

  • votre application id de faire certains travaux lourds en main (GUI) thread

et

  • périphérique cible a foiré firmware

Voici une liste d'appareils, où j'ai expérimenté plus fréquemment le bug -ainsi, non seulement les bas de gamme de périphériques, attention à l'ignore :-)

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

La seule chose que vous pouvez faire à ce sujet est de rendre votre app responsive. La meilleure façon de le faire est d'utiliser pendant le développement et l'essai du mode Strict, c'est-à-dire de faire quelque chose comme ceci:

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();
}
3
répondu tpcz 2016-03-11 16:22:46
la source