NoClassDefFoundError: android.app.ANRManagerProxy

Question

Weiß jemand, warum das passiert? Ich sehe diesen Absturz von meiner App gemeldet, aber ich habe keine Ahnung, was es ist.

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) 

Answer 1

Dieser Fehler kann auf eine kleine Gruppe von Geräten zu sehen (ich keine Liste haben, aber sie neigen dazu, No-Name-Marken zu sein), deren Firmware-Entwickler, aus unbekannten Gründen, entfernt, um die ANRManagerProxy aus dem Geräte-Framework (Ich habe dies bestätigt, indem ich eine Firmware aufgespürt und selbst dekompiliert habe).

Das Beste, was Sie tun können, ist versuchen, jeden möglichen Code auf der Jagd nach, die die Schraubensicherung werden könnten und was das Gerät werden nonresponsive, und versuchen, ein AsyncTask oder ähnliches verwenden Sie den Code asynchron und vermeiden Sie den ANR laufen. Bei den fraglichen Geräten handelt es sich immer um Low-End-Geräte. Daher dauert die Ausführung des Codes länger und es besteht eine größere Chance, dass dies geschieht.

Ich würde vorschlagen, Hugo als eine große Bibliothek für die Debug-Methode Ausführungszeiten, um Ihren Fokus darauf, wo die meiste Zeit verbracht wird einzuschränken. Dies wird dazu beitragen, Ihren Code für alle Benutzer zu verbessern und das Risiko des fraglichen Absturzes zu reduzieren.

Answer 2

Dies geschieht, weil

• Ihr einige schwere Arbeit in main (GUI) Thread

und

• Zielgerät hat verkorkste App id Firmware tun

Hier

ist eine Liste der Geräte, wo ich häufiger den Fehler erlebt - so nicht nur Low-End-Geräte, seien Sie vorsichtig Sie es :-)

Lenovo A316I ignorieren, 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 ...

Nur was Sie dagegen tun können, ist, dass Ihre App reagiert. Der beste Weg, dies zu tun ist während der Entwicklung und Erprobung Strict-Modus zu verwenden, das heißt, so etwas zu tun:

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(); 
}