I've just started work with Koltin and my question might be a little strange to someone who have more experience,
but how can i see fatalExceptions in logcat? For example, i have an app that is already developed by another dev,
there is an error in one activity - after pressing the button apps crash and restart to main activity.
I don't see any usefull informations in logcat(in fabric also!), moving on trough whole code from listener to fragment and many classess is very time consuming. There must be some way to figure it out quicker, right?
Exceptions should be shown/thrown in logcat, same as with Java.
If the exception is thown within rxjava or a kotlin coroutine, make sure you have defined an error handler, otherwise the exception might get swallowed.
Then make sure you have selected the right app in logcat and that no filter is active.
Also make sure there is no other global Exception handler defined besides fabric.
My Android app currently uses a custom UncaughtExceptionHandler that aims to capture any crash, and schedules an app restart for several seconds in the future with AlarmManager before manually calling Process.killProcess(Process.myPid()) to avoid Android's Force Close popup as in my app's use case, the user will not be able to interact with the device to tap "ok" on the FC dialog and restart the app.
Now, I'd like to integrate with Firebase Crash reports, but I fear wrong behaviors, so here are my questions:
How should I make my code so my custom UncaughtExceptionHandler passes the exception to Firebase Crash Report before killing it's process? Would calling Thread.getDefaultUncaughtExceptionHandler() give me the Firebase Crash report UncaughtExceptionHandler so I can just call uncaughtException(...) on it?
May Process.killProcess(Process.myPid()) prevent Firebase Crash reporting library to do it's reporting work? Would Firebase have started it's crash report in a separated process before it's uncaughtException(...) returns? Does Firebase own UncaughtExceptionHandler calls back to Android default's UncaughtExceptionHandler, showing the FC dialog?
May Process.killProcess(Process.myPid()) kill Firebase Crash Reporting process in addition to the default process?
How can my custom Application class detect if it is instantiated in Firebase Crash Reporting process? Treating both processes the same way would probably lead to inconsistent states.
Thanks to anyone that tries to help me!
If you kill the process in your exception handler, you will not be able to receive crashes. It will interfere with the ability to persist the crash for either immediate or delayed transmission. It will possibly interfere with any library that has registered uncaught exception handlers that behave well.
In fact, Process.killProcess(Process.myPid()) is very much an anti-pattern for Android development. Android apps should not be concerned at all with the overall lifecycle if the process that hosts the app. The fact that Android manages the process for you is an optimization designed for the benefit of the users.
I strongly recommend, for uncaught exceptions in your app, to simply let the app die as it normally would. Masking the proper effect of the crash is like sweeping dirt under a rug. You might be resolving a short term problem, but what really needs to happen is the normal logging and handling of the error so you can fix it.
Don't depend on the fact that Firebase Crash Reporting transmits exceptions in another process. That other process will be removed in the full non-beta release.
The best situation for your Application subclass is to not depend at all which process it's operating. In fact, the Android team at Google does not recommend use of Application subclasses at all since it only leads to trouble for multi-process apps. If you must use an Application subclass, it should expect to run within multiple processes.
After some testing, I finally found a way to both ensure my app restarts properly after an UncaughtException.
I attempted three different approaches, but only the first, which is my original code, with just a little tweak to pass the uncaught Throwable to `FirebaseCrash, and ensure it is considered as a FATAL error.
The code that works:
final UncaughtExceptionHandler crashShield = new UncaughtExceptionHandler() {
private static final int RESTART_APP_REQUEST = 2;
#Override
public void uncaughtException(Thread thread, Throwable ex) {
if (BuildConfig.DEBUG) ex.printStackTrace();
reportFatalCrash(ex);
restartApp(MyApp.this, 5000L);
}
private void reportFatalCrash(Throwable exception) {
FirebaseApp firebaseApp = FirebaseApp.getInstance();
if (firebaseApp != null) {
try {
FirebaseCrash.getInstance(firebaseApp)
.zzg(exception); // Reports the exception as fatal.
} catch (com.google.firebase.crash.internal.zzb zzb) {
Timber.wtf(zzb, "Internal firebase crash reporting error");
} catch (Throwable t) {
Timber.wtf(t, "Unknown error during firebase crash reporting");
}
} else Timber.wtf("no FirebaseApp!!");
}
/**
* Schedules an app restart with {#link AlarmManager} and exit the process.
* #param restartDelay in milliseconds. Min 3s to let the user got in settings force
* close the app manually if needed.
*/
private void restartApp(Context context, #IntRange(from = 3000) long restartDelay) {
Intent restartReceiver = new Intent(context, StartReceiver_.class)
.setAction(StartReceiver.ACTION_RESTART_AFTER_CRASH);
PendingIntent restartApp = PendingIntent.getBroadcast(
context,
RESTART_APP_REQUEST,
restartReceiver,
PendingIntent.FLAG_ONE_SHOT
);
final long now = SystemClock.elapsedRealtime();
// Line below schedules an app restart 5s from now.
mAlarmManager.set(ELAPSED_REALTIME_WAKEUP, now + restartDelay, restartApp);
Timber.i("just requested app restart, killing process");
System.exit(2);
}
};
Thread.setDefaultUncaughtExceptionHandler(crashShield);
Explanation of why and unsuccessful attempts
It's weird that the hypothetically named reportFatal(Throwable ex) method from FirebaseCrash class has it's name proguarded while being still (and thankfully) public, giving it the following signature: zzg(Throwable ex).
This method should stay public, but not being obfuscated IMHO.
To ensure my app works properly with multi-process introduced by Firebase Crash Report library, I had to move code away from the application class (which was a great thing) and put it in lazily loaded singletons instead, following Doug Stevenson's advice, and it is now multi-process ready.
You can see that nowhere in my code, I called/delegated to the default UncaughtExceptionHandler, which would be Firebase Crash Reporting one here. I didn't do so because it always calls the default one, which is Android's one, which has the following issue:
All code written after the line where I pass the exception to Android's default UncaughtExceptionHandler will never be executed, because the call is blocking, and process termination is the only thing that can happen after, except already running threads.
The only way to let the app die and restart is by killing the process programmatically with System.exit(int whatever) or Process.kill(Process.myPid()) after having scheduled a restart with AlarmManager in the very near future.
Given this, I started a new Thread before calling the default UncaughtExceptionHandler, which would kill the running process after Firebase Crash Reporting library would have got the exception but before the scheduled restart fires (requires magic numbers). It worked on the first time, removing the Force Close dialog when the background thread killed the process, and then, the AlarmManager waked up my app, letting it know that it crashed and has a chance to restart.
The problem is that the second time didn't worked for some obscure and absolutely undocumented reasons. The app would never restart even though the code that schedules a restart calling the AlarmManager was properly run.
Also, the Force Close popup would never show up. After seeing that whether Firebase Crash reporting was included (thus automatically enabled) or not didn't change anything about this behavior, it was tied to Android (I tested on a Kyocera KC-S701 running Android 4.4.2).
So I finally searched what Firebase own UncaughtExceptionHandler called to report the throwable and saw that I could call the code myself and manage myself how my app behaves on an uncaught Throwable.
How Firebase could improve such scenarios
Making the hypothetically named reportFatal(Throwable ex) method non name-obfuscated and documented, or letting us decide what happens after Firebase catches the Throwable in it's UncaughtExceptionHandler instead of delegating inflexibly to the dumb Android's default UncaughtExceptionHandler would help a lot.
It would allow developers which develop critical apps that run on Android to ensure their app keep running if the user is not able to it (think about medical monitoring apps, monitoring apps, etc).
It would also allow developers to launch a custom activity to ask users to explain how it occurred, with the ability to post screenshots, etc.
BTW, my app is meant to monitor humans well-being in critical situations, hence cannot tolerate to stop running. All exceptions must be recovered to ensure user safety.
I've created a bindings project, hooked everything up in my onCreate etc. Everything works except for unhandled exceptions. Let me elaborate on "Everything works" - I can see via crittercism's live stats page that there is indeed an app load, I can also send up "ManagedExceptions" using the "LogHandledException" interface.
I have implemented the ICritterCallback interface and the "CrashedOnLastLoad" boolean is always false. This is wierd cos I can see the app crashes.
I have used these 3 ways to try and get my logs sent to Crittercism. (All 3 crash the app)
Java exception
throw new Java.Lang.IllegalArgumentException("This is a test for critter");
Background exception
.Click += delegate { ThreadPool.QueueUserWorkItem(o => { throw new Exception("Crashed Background thread."); } ); };
Simple .net exception
throw new Exception("Crashed UI thread.");
None of the above are registering as crashes on the next load... weird right?
Maybe the .net runtime is swallowing all the unhandled exceptions then calling exit gracefully on dalvic's runtime... is this possible..?
As a hack for now im implementing the exception handlers for android as per this blog post then calling Crittercism.LogHandledException(Throwable.FromException(e.Exception)); from inside both the events.
It works, but im using Crittercism's handled exceptions for unhandled exceptions.. So when I want to send up real "HandledExceptions" they will be lost in the mess.
So is there any way to send an unhandled exception to Crittercism??
Or is there a way to simulate a crash on android from .net that will send it to Crittercism??
Any help would be much appreciated!
Cheers,
Sam
Co-founder of Crittercism here. We just released an official plugin for Xamarin which should automatically log javascript exceptions (and any other crashes) as unhandled exceptions so you won't run into this problem anymore. You can download the latest version from the Xamarin asset store here:
http://components.xamarin.com/view/crittercism
I got an android app where I set a global exception handler as described here:
Using Global Exception Handling on android
When I'm forcing an exception then I see that it is catched by the handler.
But from time to time I'm still experiencing device freezes when running the app.
The app uses a lot of different threads. But as far as I understand, this should have no influence.
Are there some known limitations on android regarding global exception handling, where exception are not handled by the global handler?
Thanks
In my android app I need a global exception handling mechanism. That is an exception handler which works when an exception occurs from any activity of my app. Is this possible? How?
if you have access to your own web server with PHP installed, you might have a look at this
http://code.google.com/p/android-remote-stacktrace/
The Google Groups thread they're pointing you to is a good reference. I have a helper class in my app that offers the user the option of sending a failure report to me with the details of the crash. Basically, when the failure is caught it writes the details out to the SD card and on next run of the app it displays a pop-up.
It won't keep your app from crashing, but it will let you do something intelligent with result.