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
I've a strange black screen problem at app restart after the app wasn't used for a while reported by users in the play store developer console with an ANR with a quite strange stack trace:
----- pid 2704 at 2013-08-15 09:08:32 -----
Cmd line: system_server
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x400281b8 self=0xd088
| sysTid=2704 nice=0 sched=0/0 cgrp=default handle=-1345006464
| schedstat=( 29713532638 35237133707 131286 )
at com.android.server.SystemServer.init1(Native Method)
at com.android.server.SystemServer.main(SystemServer.java:918)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(...)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:665)
at dalvik.system.NativeStart.main(Native Method)
...
and no thread with app code involved. I can kind of reproduce it on one of my test devices but it is quite random and takes really long to run into the error. But if I'm able to I get the following messages in the log of the device right after starting the app:
I/ActivityManager( 2704): Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.example.client.android/.ExampleMainActivity bnds=[125,494][235,632] } from pid 2908
W/ActivityManager( 2704): Receiver during timeout: BroadcastFilter{40b8b180 ReceiverList{40b8b108 32495 com.example.client.android/10107 remote:40b34b28}}
I/ActivityManager( 2704): Skipping duplicate ANR: ProcessRecord{40bfc8c0 32495:com.example.client.android/10107} Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x40000000 }
W/ActivityManager( 2704): Activity idle timeout for HistoryRecord{40578b78 com.example.client.android/.ExampleMainActivity}
I already googled around and found the following posts on StackOverflow concerning these messages:
Activity idle timeout for HistoryRecord?
Activity idle timeout for HistoryRecord
And the following post in google groups:
https://groups.google.com/forum/?fromgroups#!topic/android-developers/TfkPlN5b-ig
I checked for services, if there's anything heavy-weight in onReceive of the BroadcastReceivers but haven't found anything.
We use a OnGlobalChangeLayoutListener, which applied an View.invalidate() to work around a WebView repaint probelm which maybe could cause a draw-Looping. I removed it but still do get the problem.
Anyone maybe having the same problem and having an idea how to fix it or to isolate it? I'm pretty much out of ideas here and would love to understand what's going on here.
UPDATE
I forgot to mention: if this black screen problem happened the only way getting the app out of this is a forced stop of the application process. Otherwise the log lines get logged every time I try to start the app.
UPDATE 2
A more detailed description of what is happening as requested: The black screen occurs very randomly. It always happens at start of the app and if happened only a force stop gets the app out of this. It seems to happen only after the app wasn't used for a longer and was probably swapped out of memory. And it looks like only Android 2.x devices are affected although I'm not sure with this.
UPDATE 3
I've added a button which calls android.os.Process.killProcess(Process.myPid()); and if I call this again and again I've been able to reproduce it after some time, by starting the app and quitting it using the button. After some time (quite random), I get this right after quitting using the button:
E/JavaBinder( 2704): !!! FAILED BINDER TRANSACTION !!!
followed by a:
W/ActivityManager( 2704): Activity pause timeout for HistoryRecord{40976dd8 com.example.client.android/.ExampleMainActivity}
and next time I restart the app I just get a black screen and the log messages mentioned above. I've been unable to reproduce the same with an android 4.1 device, only with two 2.3 devices.
Googling around I found this:
http://androiddiscuss.com/1-android-discuss/42614.html
suggesting the binder transaction buffer is somewhat exhausted. We use the MediaPlayer, InApp-Billing and Google Cloud Messages which use binding. I removed all of them and still get into this error. Maybe someone knows other hidden binder related stuff to check for?
I was finally able to identify the faulty component: I recently updated the used Admob-SDK from 6.2.1 to 6.4.1 and the black screen (and the Java-Binder message) happens since the update. Rolling back to 6.2.1 solved the issue.
I got mail from a user who has a lot of apps installed that he has problems when my app gathers activity info with this code:
getPackageManager().queryIntentActivities(mAinIntent, 0)
whole source here: https://github.com/ligi/FAST
this is what happens
Caused by: java.lang.RuntimeException: Package manager has died
at android.app.ApplicationPackageManager.queryIntentActivities(ApplicationPackageManager.java:479)
at org.ligi.fast.BaseAppGatherAsyncTask.doInBackground(BaseAppGatherAsyncTask.java:34)
at org.ligi.fast.BaseAppGatherAsyncTask.doInBackground(BaseAppGatherAsyncTask.java:1)
at android.os.AsyncTask$2.call(AsyncTask.java:287)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)
... 5 more
Caused by: android.os.TransactionTooLargeExceptionTransactionTooLargeException
at android.os.BinderProxy.transact(Native Method)
at android.content.pm.IPackageManager$Stub$Proxy.queryIntentActivities(IPackageManager.java:2230)
at android.app.ApplicationPackageManager.queryIntentActivities(ApplicationPackageManager.java:473)
... 9 more
Log:
0 D: Writing unhandled exception to: /data/data/org.ligi.fast/files/3.7-1364933885194.tracedroid
there seems to be a problem that I am running against the 1mb border, but how to get out of there? How else can I get the needed info? Is there a way to chunk up the data?
I ran into this error a while ago with the same user input. Though my thrown event was different. I ended up catching the exception and reporting back the user gracefully that there were too many apps installed with the ability to handle . Out of several hundred thousand installs I have only seen this error off-handedly less than five times for a project, I know that isn't an excuse but some devices just don't have the heap to handle indexing the intents of each application installed on the device.
I am running around ten AsyncTasks after my application starts. Sometimes the emulator takes a long time to start these tasks. When this occurs, I see the following message in the log cat:
D/dalvikvm(1983): threadid=8: still suspended after undo (sc=1 dc=1 s=Y)
When the emulator executes quickly this message doesn't appear. Strangely, this behavior changed today without any modifications. Since I have explicitly assigned 512mb ram to the emulator, it is no longer extremely slow ~5min, now ~5s. On a real device I never have execution that slow.
I would like to understand what this log cat message means. I understand that the thread with the specified id is suspended and not working while in this state. But why? After what undo? What does (sc=1 dc=1 s=Y) mean?
The message comes from dvmSuspendSelf(), which threads call when the debugger (via the JDWP thread) has asked them to suspend.
The way it's supposed to work is (where "we" are a thread):
JDWP asks us to suspend
we tell it we've suspended and go to sleep
eventually, debugger wakes us up and we resume
The message is logged when the condition variable the VM is waiting on signals, but for some reason we're still marked as suspended. The code notes:
/*
* The condition was signaled but we're still suspended. This
* can happen if the debugger lets go while a SIGQUIT thread
* dump event is pending (assuming SignalCatcher was resumed for
* just long enough to try to grab the thread-suspend lock).
*/
The expectation in this case is that we got woken up unexpectedly when a signal arrived (e.g. system_server thinks there's an ANR because the main thread isn't responding because the debugger has suspended it), and if we loop around again the debugger will get a chance to clean us up and set us on our way.
The log message is printing the values of self->suspendCount (how many times have we been told to suspend ourselves), self->dbgSuspendCount (how many of those suspend requests came from the debugger, so we can "undo" all those if the debugger disconnects), and the value of the self->isSuspended boolean.
Note the "s=Y" flag disappeared in gingerbread -- the way thread suspension works was changed.
This thread is old but this answer should provide useful for users stumbling across this question months later.
Quoting a user's reply on a google group thread
There's a weird interaction between the VM and your debugger. The
thread suspended itself and then waited to be woken. However, when it
was woken the thread was still marked as being suspended (s=1) by the
debugger (d=1).
I've come across this on the emulator and on the phone itself. If the debugger is disconnected from the device (be it emulated or real), this error condition is reset. I have found no other way of escaping the problem.
Another SO answer claims this is due to debug breakpoints being out of sync - DexFile.class error in eclipse
You can try that too.
HTH
Me too come across the problem.
Simply just because after I started a new Thread(), I tried to access the stuff in the thread that had already been suspended.
Removed that code, and the problem is resolved.
HTH
I start the app. Using it, nothing
problem.
Send it to background, using phone
for someting else.
If I come foeground the app again,
it looks like it restart the
activity, run the loader ASync task
and then it log the following lines:
06-22 15:45:02.611: WARN/dalvikvm(12735): threadid=10: thread exiting with uncaught exception (group=0x2aacc8a0)
06-22 15:45:02.611: WARN/dalvikvm(12735): threadid=12: thread exiting with uncaught exception (group=0x2aacc8a0)
06-22 15:45:02.621: INFO/ActivityManager(242): Process hu.ringier.nsof1.android (pid 12735) has died.
It occurs if the activity contains a gridview with remote images from web. App contains a tabwidget and every other activity works great after coming to foreground in the case if the activity is restart, but not the gridview one.
Have you any idea how can I find the problem? The logcat doesn't contain any stacktrace, just the warning and the died message.
I've searched abot this topic, but everybody got a stacktrace.
It is solved. There was a Log call in a catch block, but I didn't log it, so it was hidden. I reviewed every cacth block add and edit all Log calls to log the exception itself. Finally I found a NPE.
Reminder: Always log catched exceptions, it doesn't hurt!