NoClassDefFoundError: android.app.ANRManagerProxy

Question

Czy ktoś wie, dlaczego tak się dzieje? Widzę tę awarię zgłoszoną przez moją aplikację, ale nie mam pojęcia, co to jest.

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

Ten błąd może być postrzegany na małej grupy urządzeń (nie mam listę, ale na ogół są one marki no-name), którego firmware deweloperzy, z nieznanych powodów, usunięto z ANRManagerProxy framework urządzenia (potwierdziłem to, polując na oprogramowanie układowe i samemu je dekompilując).

Najlepsze, co można zrobić, to upolować dowolny możliwy kod, który mógłby zablokować wątek i spowodować, że urządzenie przestanie reagować, i spróbować użyć asynchronicznie kodu AsyncTask lub podobnego i uniknąć ANR. Urządzenia, o których mowa, zawsze mają niski poziom, więc Twój kod będzie trwał dłużej i będzie miał większą szansę na spowodowanie tego.

Proponuję Hugo jako świetną bibliotekę do debugowania czasu wykonania metody, aby ograniczyć skupienie na tym, gdzie spędza się najwięcej czasu. Pomoże to ulepszyć kod dla wszystkich użytkowników, a także zmniejszyć ryzyko wystąpienia tej awarii.

Answer 2

Dzieje się tak, ponieważ

• aplikacja id jakiejś ciężkiej pracy w Main (GUI) gwint

i

• urządzenie docelowe ma pomieszane firmware

Oto lista urządzeń, gdzie wystąpiły częściej bug - więc nie tylko urządzenia low end, uważać można zignorować :-)

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 , Karta Galaxy SM-T700C ...

Jedyne, co możesz zrobić, to sprawić, by Twoja aplikacja była responsywna. Najlepszym sposobem, aby to zrobić jest użycie w trakcie rozwoju i testowania trybie ścisłym, czyli zrobić coś takiego:

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