I use ACRA in my android application. It's very useful but sometimes boring.
Sometimes, there are several asynchronous tasks running in the background. And for season, all of them failed(e.g. can't connect to internet). ACRA will show the toast message again and again, and refused to exit.
Is it able to let ACRA just catch the first exception? Or just show the toast message once?
Update
add a demo: https://github.com/freewind/android-acra-multi-reports
There are 4 activities in this project. The last one will throw exception and each previous activity will throw exception in onActivityResult. You can see ACRA will report many times before exiting.
That sounds to me like you should actually catch some exceptions and don't let all of them bubble up.
ACRA registers a Thread.UncaughtExceptionHandler on the main thread. Here all uncaught exceptions (as the handler's name suggests) get processed. Usually that means that the application is about to crash and ACRA will do its reporting magic. ACRA uses several Threads itself to do its work and will wait until everything is finished before it actually kills the application's process. So I'd guess that if there are coming a lot of exceptions, ACRA is just so busy to process them that it won't come to the point were it would kill the process.
You could register your own implementation of UncaughtExceptionHandler to catch exceptions and decide when to hand them through to ACRA and when to do something else. If I'm not mistaken, ACRA will call through to the UncaughtExceptionHandler that has been registered before the ACRA init. So you could also try to chain those handlers.
Related
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.
Do you know how ACRA - the Android Crash reporting framework - works under the hood?
How does it hook-in to catch exceptions and errors? Is it using some global try/catch block to detect errors?
And does it affect performance and battery life by doing this?
ACRA works by setting up a default exception handler on the main thread. You can see that in the source code here:
mDfltExceptionHandler = Thread.getDefaultUncaughtExceptionHandler();
Thread.setDefaultUncaughtExceptionHandler(this);
It sets itself as the default uncaught exception handler at this point. Java will call this handler if there are any Exceptions that are thrown that are never caught by any try/catch block.
Since it's not really an active daemon or process, but rather part of your code (assuming you call ACRA.init()), it doesn't actually impact performance or battery life at all.
I have Crashlytics properly configured in my app. I can see crash reports.
I tried to add a custom log to the crash reports but I do not see anything in the report.
I tried to move the log out of the uncaughtException handler and in that case I see the logs.
So if I log while the application is running properly then I see the logs in the crash report when the application crashes but if I try to add a log in my uncaughtException handler these logs are not shown.
is this the proper behaviour?
I'm on Android.
To log I just use:
Crashlytics.log(myLog);
myLog is a non-null non-empty string (I checked it)
You are right you need to move the Crashlitycs.start before registering your uncaughtException handler.
I thought that an explanation could be that the logs are sent to the server asynchronously and if the application gets killed before they are sent you don't see them in the crash report. I checked and that is not the case: even if you wait for a while before calling the default handler nothing happen.
The only explanation for now is that Crashlitycs uncaughtException handler is called before mine.
So to fix the issue it is enough to register the handler after calling Crashlytics.start
I have searched on the internet regarding what an ANR is. And I studied those references as well. But I don't get details regarding a crash in Android.
Can someone tell me the difference between ANR(Android not Responding) and a crash in Android?
ANR stands for Application Not Responding.
An ANR will occur if you are running a process on the UI thread which takes a long time, usually around 5 seconds. During this time the GUI (Graphical User Interface) will lock up which will result in anything the user presses will not be actioned. After the 5 seconds approx has occurred, if the thread still hasn't recovered then an ANR dialogue box is shown informing the user that the application is not responding and will give the user the choice to either wait, in the hope that the app will eventually recover, or to force close the app.
A crash is when an exception within the app has been thrown which has not been handled. For example, if you try to set the text of an EditText component, but the EditText is null and there is no try catch statement to catch the exception that your app will crash and will be force closed. The user will not see what caused the crash, they will be shown a dialogue telling that the app has force closed unexpectedly and will give them the option to send a bug report. In this example if you were to look in the bug report you would see the error caused by java.lang.NullPointerException.
ANR (Application Not Responding) is due to handling a long running task in the main (UI) thread. If the main thread is stopped for more than 5 seconds, the user will get an ANR.
Crashes are due to exceptions and errors like NullPointerException, ClassNotFoundException, typecasting or parsing errors, etc. ANR also causes a crash of the application.
Note: Never perform a long-running task on the UI thread.
Reference ANR
ANR and Crash Examples:
This question already has an accepted answer, but I am adding 2 simple examples to understand ANR and Crash better.
ANR:
// this will produce an ANR on your app
int i = 0;
while(true) {
i++;
}
Crash:
// this will crash your app : will produce java.lang.ArithmeticException
int value = 5, i = 0;
int result = value / i;
Application Not Responding (ANR):
ANR will display in the following conditions:
Response to the input event (such as key press or screen touch even) within 5 Sec.
A Broadcast Receiver hasn’t finished executing within 10 Sec.
How to avoid ANRs?
Create a different worker thread for long running operations like database operations, network operations etc.
Reinforce Responsiveness:
In android app usually, 100 to 200 ms is the threshold beyond which user will feel that app is slow. Following are the tips through which we can show application more responsive.
Show progress dialog whenever you are doing any background work and a user is waiting for the response.
For games specifically, do calculations for moves in the worker thread.
Show splash screen if your application has time-consuming initial setup.
Crash:
The crash is unhandled condition into the application and it will forcefully close our application. Some of the examples of crashes are like Nullpointer exception, Illegal state exception etc.
ANR stands for Application Not Responding, which means that your app does not register events on the UI Thread anymore because a long running operation is executed there
ANR: It is called when anything your application is doing in the UI thread that
takes a long time to complete (5 sec approx)
Reference: ANR
Crash: It is called when your Application gets some Error or Exception raised by the DVM
ANR also caused by-
No response to an input event (such as key press or screen touch events) within 5 seconds.
A BroadcastReceiver hasn't finished executing within 10 seconds.
ANR stands for Application Not Responding and its occurs when long operation takes place into Main thread......
Crash are due to exception and error like Nullpoint,
ANR stands for Application Not Responding.
It can occur due to many reasons like if an application blocks on some I/O operation on the UI thread so the system can’t process incoming user input events. Or perhaps the app spends too much time building an elaborate in-memory structure or computing the next move in the UI thread.
Blocking the main thread, won't result in a crash, but a popup will be displayed to let users kills the app after 5 seconds.
But For Crash, the main reason is the human errors.
Most of the time an app crashes is because of a coding/design error made by human
Human Errors
Lack of testing
Null Pointer exception
OutofMemory
Example :
This is common when a programmer makes a reference to an object or variable that does not exist, basically creating a null-pointer error.
If you have a bad connection, that can also make your apps crash. The app could also have memory management problems.
Please see my answer for the type of android specific exception which may cause the crash.
Android Specific Exception
ANR for ex: if You are downloading huge amount data in ui thread, meny other possibilities like insufficient memory etc it will come.. probably it leads to crashes in android , We can't say both are same one follows other
[ANR and Crash Different][1]
Android applications normally run entirely on a single thread by default the “UI thread” or
“main thread”. This means anything your application is doing in the UI thread that takes a long time to complete can trigger the ANR dialog because your application is not giving itself a chance to handle the input event or intent broadcasts.
ANR: Basically due to a long running task on main thread.
There are some common patterns to look for when diagnosing ANRs:
The app is doing slow operations involving I/O on the main thread.
The app is doing a long calculation on the main thread.
The main thread is doing a synchronous binder call to another process, and that other process is taking a long time to return.
The main thread is blocked waiting for a synchronized block for a long operation that is happening on another thread.
The main thread is in a deadlock with another thread, either in your process or via a binder call. The main thread is not just waiting for a long operation to finish, but is in a deadlock situation.
The following techniques can help you find out which of these causes is causing your ANRs.
CRASH:
Reason for crashs can be many. Some reasons are obvious, like checking for a null value or empty string, but others are more subtle, like passing invalid arguments to an API or even complex multithreaded interactions
This is good article at developer portal.
It gives clarity in detail about ANR.
https://developer.android.com/training/articles/perf-anr.html
What is the usual way on Android to stop my application if it has reached an unrecoverable error.
finish() will not do it, since it wont stop any running services or threads. Furthermore I would like to inform the user what has happend and please him to send an error log.
As far as I googled, it seems like there is no way to close my application and open a special crashreport activity or something else to show the user whats going on or send a crash log.
I think you should throw unhandled runtime exception. In such case android will kill all your process. Also I suggest you to use ACRA. This library will help you to get crash report (via email, google docs, etс.) and it can show customizable error dialog to a user.
You should check this out. This could be your solution.
ACRA
Check the basic setup guide to start using the library. ACRA - Basic Setup
While ACRA is an okay solution, if you want to implement your own logging of unhandled exceptions try Thread.setDefaultUncaughtExceptionHandler(). That way you can get any exceptions that are thrown and not caught, and log them the way you like. You need to implement Thread.UncaughtExceptionHandler and pass it to that method.
With an Activity, it would look something like this in onCreate():
getMainLooper().getThread().setUncaughtExceptionHandler(new MyUncaughtExceptionHandler());