NoClassDefFoundError: android.app.ANRManagerProxy

Question

Qualcuno sa perché questo accade? Vedo questo crash segnalato dalla mia app ma non ho idea di cosa sia.

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

Questo errore può essere visto su un piccolo gruppo di dispositivi (non ho un elenco, ma tendono ad essere no-name brand) i cui sviluppatori del firmware, per ragioni sconosciute, ha rimosso il ANRManagerProxy dal framework del dispositivo (l'ho confermato cercando un firmware e decompilandolo da solo).

Il meglio che puoi fare è cercare di rintracciare ogni possibile codice che potrebbe bloccare il thread e far sì che il dispositivo non risponda e provare a usare un AsyncTask o simile per eseguire il codice in modo asincrono ed evitare l'ANR. I dispositivi in ​​questione sono sempre di fascia bassa, quindi il tuo codice impiegherà più tempo per essere eseguito e avrà una maggiore possibilità che ciò accada.

Suggerirei Hugo come una grande libreria per il debug dei tempi di esecuzione dei metodi, al fine di restringere l'attenzione su dove viene trascorso il maggior tempo. Ciò contribuirà a migliorare il codice per tutti gli utenti e a ridurre il rischio di arresto anomalo in questione.

Answer 2

Questo accade perché

• tuo ID applicazione facendo qualche lavoro pesante in main (GUI) filo

e

• dispositivo di destinazione ha incasinato firmware

Ecco un elenco di dispositivi, in cui ho sperimentato più spesso il bug - quindi non solo i dispositivi di fascia bassa, fare attenzione si ignorarlo :-)

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

L'unica cosa che puoi fare al riguardo è rendere la tua app reattiva. Il modo migliore per farlo è quello di utilizzare durante lo sviluppo e la sperimentazione modalità Strict, vale a dire, a fare qualcosa di simile:

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