Develop Reference

ANR and Activity reported stop, but no longer stopping

I have this problem on some devices and on some occasions, and I can't reproduce it 100%. Sometimes when the user switches away from my activity they get this error: Activity reported stop, but no longer stopping: ActivityRecord and usually it's followed by an ANR like:
02-26 19:43:31.187 I/InputDispatcher( 1062): Application is not responding: Window{8f7e457 u0 gb.xxy.hr/gb.xxy.hr.player}. It has been 5000.8ms since event, 5000.6ms since wait started. Reason: Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Wait queue length: 14. Wait queue head age: 6964.8ms.
02-26 19:43:31.208 I/WindowManager( 1062): Input event dispatching timed out sending to gb.xxy.hr/gb.xxy.hr.player. Reason: Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Wait queue length: 14. Wait queue head age: 6964.8ms.
02-26 19:43:31.270 E/ActivityManager( 1062): ANR in gb.xxy.hr (gb.xxy.hr/.player)
02-26 19:43:31.270 E/ActivityManager( 1062): PID: 14732
02-26 19:43:31.270 E/ActivityManager( 1062): Reason: Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago. Wait queue length: 14. Wait queue head age: 6964.8ms.)
02-26 19:43:31.270 E/ActivityManager( 1062): Load: 0.0 / 0.0 / 0.0
02-26 19:43:31.270 E/ActivityManager( 1062): CPU usage from 179169ms to 0ms ago (2019-02-26 19:40:32.074 to 2019-02-26 19:43:31.243):
My activity onstop has no code in it, but I do have some code which releases the surface:
#Override
public void surfaceDestroyed(SurfaceHolder holder) {
myLog.d(TAG,"Surface Destroyed.");
try {
holder.removeCallback(this);
holder.getSurface().release();
}
catch (Exception e)
{
myLog.e(TAG,e.getMessage());
}
videoexecutor.shutdownNow();
visible=false;
m_codec.stop();
m_codec.release();
m_codec=null;
}
I did had a look at a similar question: Android onStop times out despite doing no work and I do think that this is somehow caused by the surface but I cannot figure it out what is actually causing it, and why not on all devices and not all the time....
Any thoughts?

i am getting keydispatching timed out error on button click in my activity [duplicate]

In my Android application I am getting a very strange crash, when I press a button (Image) on my UI the entire application freezes and after a couple of seconds I getthe dreaded force close dialog appearing.
Here is what gets printed in the log:
WARN/WindowManager(88): Key dispatching timed out sending to package name/Activity
WARN/WindowManager(88): Dispatch state: {{KeyEvent{action=1 code=5 repeat=0 meta=0 scancode=231 mFlags=8} to Window{432bafa0 com.android.launcher/com.android.launcher.Launcher paused=false} # 1281611789339 lw=Window{432bafa0 com.android.launcher/com.android.launcher.Launcher paused=false} lb=android.os.BinderProxy#431ee8e8 fin=false gfw=true ed=true tts=0 wf=false fp=false mcf=Window{4335fc58 package name/Activity paused=false}}}
WARN/WindowManager(88): Current state: {{null to Window{4335fc58 package name/Activity paused=false} # 1281611821193 lw=Window{4335fc58 package name/Activity paused=false} lb=android.os.BinderProxy#434c9bd0 fin=false gfw=true ed=true tts=0 wf=false fp=false mcf=Window{4335fc58 package name/Activity paused=false}}}
INFO/ActivityManager(88): ANR in process: package name (last in package name)
INFO/ActivityManager(88): Annotation: keyDispatchingTimedOut
INFO/ActivityManager(88): CPU usage:
INFO/ActivityManager(88): Load: 5.18 / 5.1 / 4.75
INFO/ActivityManager(88): CPU usage from 7373ms to 1195ms ago:
INFO/ActivityManager(88): package name: 6% = 1% user + 5% kernel / faults: 7 minor
INFO/ActivityManager(88): system_server: 5% = 4% user + 1% kernel / faults: 27 minor
INFO/ActivityManager(88): tiwlan_wifi_wq: 3% = 0% user + 3% kernel
INFO/ActivityManager(88): mediaserver: 0% = 0% user + 0% kernel
INFO/ActivityManager(88): logcat: 0% = 0% user + 0% kernel
INFO/ActivityManager(88): TOTAL: 12% = 5% user + 6% kernel + 0% softirq
INFO/ActivityManager(88): Removing old ANR trace file from /data/anr/traces.txt
INFO/Process(88): Sending signal. PID: 1812 SIG: 3
INFO/dalvikvm(1812): threadid=7: reacting to signal 3
INFO/dalvikvm(1812): Wrote stack trace to '/data/anr/traces.txt'
This is the code for the Button (Image):
findViewById(R.id.endcallimage).setOnClickListener(new OnClickListener() {
public void onClick(View v) {
mNotificationManager.cancel(2);
Log.d("Handler", "Endcallimage pressed");
if(callConnected)
elapsedTimeBeforePause = SystemClock.elapsedRealtime() - stopWatch.getBase();
try {
serviceBinder.endCall(lineId);
} catch (RemoteException e) {
e.printStackTrace();
}
dispatchKeyEvent(new KeyEvent(KeyEvent.ACTION_DOWN,KeyEvent.FLAG_SOFT_KEYBOARD));
dispatchKeyEvent(new KeyEvent(KeyEvent.ACTION_UP, KeyEvent.KEYCODE_BACK));
}
});
If I comment the following out the pressing of the button (image) doesn't cause the crash:
try {
serviceBinder.endCall(lineId);
} catch (RemoteException e) {
e.printStackTrace();
}
The above code calls down through several levels of the app and into the native layer (NDK), could the call passing through several objects be leading to the force close? It seems unlikely as several other buttons do the same without issue.
How about the native layer? Could some code I've built with the NDK be causing the issue?
Any other ideas as to what the cause of the issue might be?

You must be as fast as possible in your onClick implementation. Expensive operations should be, in general, offloaded to a background thread.
In onClick, try:
Thread t = new Thread(){
public void run(){
your_stuff();
}
};
t.start();
instead of just
your_stuff()

You can encounter this error when you block the main thread (a.k.a. the UI thread) for a few seconds. Expensive operations should be, in general, offloaded to a background thread. AsyncTask is very helpful in these cases.
In your case you could do the following:
new AsyncTask<Void, Void, Void>() {
#Override
protected Void doInBackground(Void... params) {
try {
serviceBinder.endCall(lineId);
} catch (RemoteException e) {
e.printStackTrace();
}
}
}.execute();

Do your long Operation in a seperate thread or use AsyncTask to get rid of ANR.
An ANR(Activity Not Responding) 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.
Your activity took to long to say to the Android OS 'hey i'm still alive'! (This is what the UI thread does).
http://developer.android.com/guide/practices/design/responsiveness.html
Basically if you make the UI thread do some complex task it's too busy doing your task to tell the OS that it is still 'alive'.
http://android-developers.blogspot.co.uk/2009/05/painless-threading.html
You should move your XML Parsing code to another thread, then use a callback to tell the UI thread you have finished and to do something with the result.
http://developer.android.com/resources/articles/timed-ui-updates.html
Detecting where ANRs happen is easy if it is a permanent block (deadlock acquiring some locks for instance), but harder if it's just a temporary delay. First, go over your code and look for vunerable spots and long running operations. 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
If Logcat doesn't output anything usefull, try to pull traces.txt from /data/anr/traces.txt
adb pull /data/anr/traces.txt .
as it may give more information on where the ANR Exception occurrred
And this link may also helpful for creating AsyncTask and Threads

If you are doing a resource intensive task then it might happen. While resuming the Activity.
1. Try stopping all your intensive work on onPause and then restarting it on onResume.
2. If you are showing map on Activity drawing overlay on it then stop refreshing the overlays while on sleep. And then restart it on onResume.

Android error ANR when I make a lot of buttons

I don't understand about this problem. My android application need to generate Custom button.
It can work if I have less than 144 buttons but if I generate button more over 144 buttons.
it can't work(Forcse Closed) and show error in log cast like this.....
ANR in com.Sanuk.mahjongandroid (com.Sanuk.mahjongandroid/.MainActivity)
Load: 0.92 / 1.0 / 0.83
CPU usage from 21998ms to 0ms ago:
98% 3225/com.Sanuk.mahjongandroid: 98% user + 0% kernel
0% 1141/com.android.voicedialer: 0% user + 0% kernel / faults: 30 minor
I'm sure, It 's not error in my code. What wrong?

The answer here is that you are freezing the UI Thread by doing too much thing. The UI Thread is the thread that is responsible for view painting on screen and intercepting touches from users. It should be as free as possible to get a fluid app.
If you have heavy processing to do like creating a lot of buttons, here are some alternatives :
use an AsyncTask, although here, you should take care of creating the button in the background, but adding them in the UI Thread.
why don't you use a list ?

App takes too long to start-up

I have and android app which takes >=5 seconds to show up after it's icon is clicked.
As soon as I click the icon, I get the black screen with name of the app in status bar. After 5+ seconds, the home screen appears.
I referred this post on SO which and I got following result from stack trace
16:13:14.915: I/ActivityManager(59): Starting activity: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=packageName/.SelectType }
16:13:14.954: I/SurfaceFlinger(59):
16:13:14.954: I/SurfaceFlinger(59): SurfaceFlinger::createSurface() : layer->mIdentity=176, LayerName= Starting packageName
16:13:14.954: I/SurfaceFlinger(59): SurfaceFlinger::createSurface() : layer->clientIndex=2, surfaceHandle->mToken=0x2
16:13:16.026: D/AnrParser(184): Waiting kernel log . . .
16:13:16.614: D/dalvikvm(6890): GC_FOR_MALLOC freed 12274 objects / 785016 bytes in 135ms
16:13:17.784: D/dalvikvm(133): GC_EXTERNAL_ALLOC freed 415 objects / 21624 bytes in 1285ms
16:13:17.914: D/dalvikvm(6890): GC_FOR_MALLOC freed 5762 objects / 339024 bytes in 90ms
16:13:18.174: D/AnrParser(184): Waiting kernel log . . .
16:13:18.344: E/keystore(6966): chdir: /data/misc/keystore: Permission denied
16:13:19.693: D/dalvikvm(6890): GC_FOR_MALLOC freed 5994 objects / 372624 bytes in 93ms
16:13:20.173: D/AnrParser(184): Waiting kernel log . . .
16:13:22.173: D/AnrParser(184): Waiting kernel log . . .
16:13:22.743: I/SurfaceFlinger(59):
16:13:22.743: I/SurfaceFlinger(59): SurfaceFlinger::createSurface() : layer->mIdentity=177, LayerName= packageName/packageName.SelectType
16:13:22.743: I/SurfaceFlinger(59): SurfaceFlinger::createSurface() : layer->clientIndex=0, surfaceHandle->mToken=0x0
16:13:22.983: D/dalvikvm(6890): GC_FOR_MALLOC freed 21467 objects / 1097728 bytes in 119ms
16:13:23.403: E/keystore(6973): chdir: /data/misc/keystore: Permission denied
16:13:24.173: D/AnrParser(184): Waiting kernel log . . .
16:13:24.923: W/ActivityManager(59): Launch timeout has expired, giving up wake lock!
16:13:25.264: W/ActivityManager(59): Activity idle timeout for HistoryRecord{47f56388 packageName/.SelectType}
16:13:25.403: I/ActivityManager(59): Displayed activity packageName/.SelectType: 10206 ms (total 10206 ms)
As you can see in above log, 1st statement is 16:13:14.915: I/ActivityManager(59): Starting activity and last one is 16:13:25.403: I/ActivityManager(59): Displayed activity.
So there is a gap of approx. 10 to 11 seconds.
Any help appreciated.

You might be executing something heavy on the onCreate() or onResume() of the activity...try to debug it to see if you are performing database or I/O operations in these methods directly. You can also activate the StrictMode for a better overview of what is slowing your app down.

In my case, this happens when I use the custom theme in the application tag and with app launcher Activity in Manifest File
Such that i use this custom theme
android:theme="#style/Theme.MyAppTheme"
But when I remove the theme from the application tag and change the app launcher Activity theme to the default theme my problem is Solve
I Change the app launcher Activity theme with
android:theme="#style/Theme.AppCompat.Light.NoActionBar"

Getting low memory warning but I don't appear to be leaking memory

My application is closing without any error messages and re-launching automatically after switching activities approximately 20 or 30 times. I'm testing this by tapping a button that relaunches the current activity with different data (and cycles back around to the beginning once the end of the data is reached). The activity is launched with the FLAG_ACTIVITY_CLEAR_TOP flag so there should only ever be one instance of the activity in memory at a time. If I set FLAG_ACTIVITY_NO_HISTORY the problem still occurs.
This appears in the logcat output when the app crashes:
06-28 19:32:10.472: I/ActivityManager(115): Process com.mypackage.myapp (pid 3718) has died.
06-28 19:32:10.476: I/WindowManager(115): WIN DEATH: Window{406d06e0 com.mypackage.myapp/com.mypackage.myapp.welcome.LoginActivity paused=false}
06-28 19:32:10.480: E/InputDispatcher(115): channel '406ade20 com.mypackage.myapp/com.mypackage.myapp.matchup.MatchUpActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x8
06-28 19:32:10.480: E/InputDispatcher(115): channel '406ade20 com.mypackage.myapp/com.mypackage.myapp.matchup.MatchUpActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
06-28 19:32:10.535: I/WindowManager(115): WIN DEATH: Window{406ade20 com.mypackage.myapp/com.mypackage.myapp.matchup.MatchUpActivity paused=false}
06-28 19:32:10.539: I/WindowManager(115): WIN DEATH: Window{407a8230 com.mypackage.myapp/com.mypackage.myapp.fightcard.FightCardActivity paused=false}
06-28 19:32:10.566: I/ActivityManager(115): Start proc com.mypackage.myapp for activity com.mypackage.myapp/.fightcard.FightCardActivity: pid=3915 uid=10053 gids={3003}
06-28 19:32:10.574: I/ActivityManager(115): Low Memory: No more background processes.
Normally this would tell me that the app is leaking memory, however if I perform this test while watching the DDMS perspective in Eclipse, I can see that the allocated memory is stable, and in fact the app will often crash even when the % used is sitting around 50% (which is where it sits most of the time). The heap size and allocated memory are not increasing.
I have extensively used MAT on the app and while I did find memory leaks previously, I have solved them and can no longer find any other problems with that tool.
I've been able to recreate this problem on a Nexus S running Gingerbread, but it doesn't appear to be reproducible on a Galaxy Nexus running 4.0.4 (however that might be due to the fact that the heap is larger on the Galaxy).
What am I missing?

David Wasser's suggestion above led me to the solution. I noticed when I ran the command mentioned, I was getting a whole bunch of custom font asset allocations:
zip:/data/app/com.mypackage.myapp-2.apk:/assets/DINNextLTPro-MediumCond.otf: 98K
These allocations appeared to be increasing very quickly as I changed activities. Some googling led me to this link: http://code.google.com/p/android/issues/detail?id=9904
So it appears that there is an Android bug related to using custom fonts. The following workaround was taken from the link above:
public class Typefaces {
private static final String TAG = "Typefaces";
private static final Hashtable<String, Typeface> cache = new Hashtable<String, Typeface>();
public static Typeface get(Context c, String assetPath) {
synchronized (cache) {
if (!cache.containsKey(assetPath)) {
try {
Typeface t = Typeface.createFromAsset(c.getAssets(),
assetPath);
cache.put(assetPath, t);
} catch (Exception e) {
Log.e(TAG, "Could not get typeface '" + assetPath
+ "' because " + e.getMessage());
return null;
}
}
return cache.get(assetPath);
}
}
}
Essentially we're caching the instances of the custom font asset so each one only needs to be instantiated a single time.