Crashlytics Issue Details:
I come across this rarely found only 1 crash in last 90 days on device alps -> A3-7 PLUS DUO and on Android 4.2.2 (Android 4.2 Jelly Bean (API 17)) Operating Systems. I found detail of Crash Insights in Firebase Crashlytics and posting here.Crash Log in Details : java.lang.NoClassDefFoundError: android.app.ANRManagerProxy
Fatal Exception: java.lang.NoClassDefFoundError: android.app.ANRManagerProxy
android.app.ANRManagerNative.asInterface + 30 (ANRManagerNative.java:30)
android.app.ANRManagerNative$1.create + 94 (ANRManagerNative.java:94)
android.app.ANRManagerNative$1.create + 88 (ANRManagerNative.java:88)
android.util.Singleton.get + 34 (Singleton.java:34)
android.app.ANRManagerNative.getDefault + 37 (ANRManagerNative.java:37)
android.os.MessageLogger.dump + 253 (MessageLogger.java:253)
android.app.ANRAppManager.dumpMessageHistory + 38 (ANRAppManager.java:38)
android.app.ActivityThread$ApplicationThread.dumpMessageHistory + 1176 (ActivityThread.java:1176)
android.app.ApplicationThreadNative.onTransact + 609 (ApplicationThreadNative.java:609)
android.os.Binder.execTransact + 351 (Binder.java:351)
dalvik.system.NativeStart.run (NativeStart.java)
android.app.ANRManagerNative.asInterface + 30 (ANRManagerNative.java:30)
android.app.ANRManagerNative$1.create + 94 (ANRManagerNative.java:94)
android.app.ANRManagerNative$1.create + 88 (ANRManagerNative.java:88)
android.util.Singleton.get + 34 (Singleton.java:34)
android.app.ANRManagerNative.getDefault + 37 (ANRManagerNative.java:37)
android.os.MessageLogger.dump + 253 (MessageLogger.java:253)
android.app.ANRAppManager.dumpMessageHistory + 38 (ANRAppManager.java:38)
android.app.ActivityThread$ApplicationThread.dumpMessageHistory + 1176 (ActivityThread.java:1176)
android.app.ApplicationThreadNative.onTransact + 609 (ApplicationThreadNative.java:609)
android.os.Binder.execTransact + 351 (Binder.java:351)
dalvik.system.NativeStart.run (NativeStart.java)
Reason For Such Crash report:
This issue is triggered when your app experiences an ANR on devices running custom firmware that is missing the ANRManagerProxy class. To mitigate this issue, look for areas in your code that may block the main thread for extended periods of time. Check out the first resource for more details.I have set below code in MainActivity.java class:
So, that I can allow network calls, database read and write and other heavy work in Main (GUI) thread. See more on StrictMode.ThreadPolicy.Builder().permitAll().build()
public void onCreate() {
StrictMode.ThreadPolicy policy;
policy = new StrictMode.ThreadPolicy.Builder().permitAll().build();
StrictMode.setThreadPolicy(policy);
}
StrictMode.ThreadPolicy policy;
policy = new StrictMode.ThreadPolicy.Builder().permitAll().build();
StrictMode.setThreadPolicy(policy);
}
Solution:
So. According to below reference its suggested to use the StrictMode.ThreadPolicy.Builder for Development and testing. Only thing you can do about this is to make your app responsive. Best way to do so is to use during development and testing Strict Mode, i.e., to do something like this:
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();
}
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();
}
Best reference:
https://stackoverflow.com/questions/29289641/noclassdeffounderror-android-app-anrmanagerproxyMore on StrictMode.ThreadPolicy.Builder:
Creates ThreadPolicy instances. Methods whose names start with detect specify what problems we should look for. Methods whose names start with penalty specify what we should do when we detect a problem.
You can call as many detect and penalty methods as you like. Currently order is insignificant: all penalties apply to all detected problems.
For example, detect everything and log anything that's found:
StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder()
.detectAll()
.penaltyLog()
.build();
StrictMode.setThreadPolicy(policy);
.detectAll()
.penaltyLog()
.build();
StrictMode.setThreadPolicy(policy);
No comments:
Post a Comment