01-12 18:00:57.048 E/ActivityManager( 1709): ANR in com.kt.twwidget
01-12 18:01:18.700 E/ActivityManager( 1709): ANR in com.kt.twwidget
01-12 18:01:40.800 E/ActivityManager( 1709): ANR in system
01-12 18:02:59.280 E/ActivityManager( 1709): ANR in com.kt.twwidget
01-12 18:03:21.010 E/ActivityManager( 1709): ANR in com.kt.twwidget
This issue is well-known in the Android community. Using part of its terminology, this issue is called an ANR or Application Not Responding. Thus, the application “system” appears to stop working or there is something that makes it to wait for a huge period of time,that huge, that an ANR is fired by the system. Because this happens at boot time, the entire system seems to freeze and it is not until the user kills this application that the terminal finishes its booting procedure and makes itself available to the user once again. From time to time, though not always, this odd behaviour can end up in an unexpected reboot.
An ANR happens when some long operation takes place in the "main" thread. This is the event loop thread, and if it is busy, Android cannot process any further GUI events in the application, and thus throws up an ANR dialog.
Many way of ANR issue throwing -
1. Longer operation of method
2. Blocking the thread permanently
Detecting from where ANRs issues happening is easy.
1. if it is a permanent block (deadlock situation is coming from CODE) , but harder if it's just a temporary delay.
2. First, go over your code and look for vunerable spots and long running operations.
For examples may include using sockets, locks, thread sleeps, and other blocking operations from within the event thread.
You should make sure these all happen in separate threads. If nothing seems the problem, use DDMS and enable the thread view. This shows all the threads in your application similar to the trace you have. Reproduce the ANR, and refresh the main thread at the same time. That should show you precisely whats going on at the time of the ANR
The stack trace shows that the main thread is in the Looper (the message loop implementation) and doing a timed wait through Object.wait. This means the message loops does not currently have any messages to dispatch, and is waiting for new messages to come in. An ANR happens when the system realizes a message loop is spending to much time processing a message, and not processing other messages in the queue. If the loops is waiting for messages, obviously this is not happening.
You can enable StrictMode in API level 9 and above -