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?
Related
In my Android application I am getting a very strange crash randomly. When I open the application I am fetching data from server on splash screen. When the application land on home page suddenly whole application is closed and here is what gets printed in the log:
ANR in com.test (com.test/.activities.SplashActivity)
PID: 16020
Reason: Input dispatching timed out (49abf6 com.test/com.test.activities.SplashActivity (server) is not responding. Waited 5004ms for FocusEvent(hasFocus=false))
Parent: com.test/.activities.SplashActivity
Load: 29.87 / 30.79 / 30.77
----- Output from /proc/pressure/memory -----
some avg10=0.00 avg60=0.00 avg300=0.00 total=3115344
full avg10=0.00 avg60=0.00 avg300=0.00 total=1338179
----- End output from /proc/pressure/memory -----
The cause of this exception is that UI thread is blocked and your application is not responding for more than 5 seconds.
Double check that the code fetching data from server is not executed on main thread. Also if you are using a braodcast receiver to do any logic that could take 10 seconds will lead to this issue.
Something else to check is the exception handling in the code fetching data from server.
You can take a look at the following page also:
https://developer.android.com/training/articles/perf-anr.html#anr
Has anyone see this in the logs, once the app loads the following fires off until you close the app, preventing it from sleeping. (Only attached a small clip but it just keeps repeating this until you close the app.)
11710 D Camera-JNI Using callback buffer from queue of length 3
11633 - I CameraFramework handleMessage: 16
11633 - D Camera-JNI Adding callback buffer to queue, 3 total
11658 I BufferQueueProducer [unnamed-11633-0](this:0xef0c7c00,id:0,api:4,p:290,c:11633) queueBuffer: slot 6 is dropped, handle=0xd67aa660
11633 11710 D Camera-JNI Using callback buffer from queue of length 3
11633 - I CameraFramework handleMessage: 16
11633 - D Camera-JNI Adding callback buffer to queue, 3 total
11633 11658 I BufferQueueProducer [unnamed-11633-0](this:0xef0c7c00,id:0,api:4,p:290,c:11633) queueBuffer: slot 0 is dropped, handle=0xdbc50d80
11633 11710 D Camera-JNI Using callback buffer from queue of length 3
11633 - I CameraFramework handleMessage: 16
11633 - D Camera-JNI Adding callback buffer to queue, 3 total
Using Cordova version 6.2.0 with Cordova android version 5.1.1
Happens with or without the use of plugins.
The only way I have found to stop it is to not include the android camera permission.
I have a MusicService for MediaPlayback, wich uses a MediaPlayer with the settings:
player.setWakeMode(getApplicationContext(), PowerManager.PARTIAL_WAKE_LOCK);
player.setAudioStreamType(AudioManager.STREAM_MUSIC);
and those Listeners are set:
OnPreparedListener, OnCompletionListener, OnErrorListener, OnSeekCompleteListener
The MediaPlayer is used for mp3-Playback. When one Song is finished, onCompletion is called. Then PlayNext is called, wich resets the MediaPlayer, then sets the Datasource with the URI of the next Track. Uri is loaded with:
Uri trackUri = ContentUris
.withAppendedId(android.provider.MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, songId);
Then the Player is prepared, then the player is started. This is working fine, but only sometimes, when the Device is locked and played about 1-3 Songs while it was locked and the next Song should start, the Player doesn't prepare until i hit the power button. Figured out, that if I don't hit the PowerButton it takes the Player about 2 Minutes to prepare.
I've Logged everything now and made a few custom outputs with Log.e(...).
This is put out before prepare() (prepareAsync() delivers the same result) is called:
E/MusicService: Preparing now...
This is put out, when onPrepared is called:
E/MusicService: Player prepared.
So this is the full Device-Output after "Preparing now..." is put out:
04-02 13:54:55.506 12517-12517/at.htlleonding.musync E/MusicService: Preparing now.
04-02 13:54:55.525 811-888/? E/libsuspend: Error writing to /sys/power/state: Device or resource busy
04-02 13:54:55.544 246-14756/? D/offload_visualizer: thread exit
04-02 13:54:55.546 246-14754/? V/offload_effect_bundle: offload_effects_bundle_hal_stop_output output 1879 pcm_id 9
04-02 13:54:55.546 246-14754/? D/hardware_info: hw_info_append_hw_type : device_name = speaker
04-02 13:54:55.549 246-14752/? E/audio_hw_primary: offload_thread_loop: Compress handle is NULL
04-02 13:54:55.549 246-924/? D/audio_hw_primary: adev_close_output_stream: enter:stream_handle(0xb5bfa640)
04-02 13:54:55.549 246-924/? D/audio_hw_primary: out_standby: enter: stream (0xb5bfa640) usecase(3: compress-offload-playback)
04-02 13:54:55.555 246-924/? W/AudioFlinger: moveEffectChain_l() effect chain for session 0 not on source thread 0xb59fa000
04-02 13:54:55.611 246-15030/? I/FFmpegExtractor: android-source:0xb1834060
04-02 13:54:55.820 811-888/? E/libsuspend: Error writing to /sys/power/state: Device or resource busy
04-02 13:54:55.972 246-15030/? I/FFMPEG: [mp3 # 0xae2f4400] Skipping 0 bytes of junk at 2177007.
... Then theres no output until i hit the PowerButton. Then the Song is prepared.
If someone is interested in the full output after I hit the PowerButton until "Player prepared" is called, I created a Gist here.
Sidenote:
While the App is used, a few Album-Covers are displayed in some Fragments. They are loaded with Picasso, so I don't need to worry about memory caching. Some ImageViews are filled without Picasso (for example the ImageViews that hold the drawables of my PlayerControls). Maybe there are Problems with the memory/resources?
I might have found the answer in another thread where some faced the same problem while streaming music here.
My final solution is to use a WakeLock, wich I require before preparing a Song and release again onPrepared and onError and onDestroy of my Service. It's important to release it again to save Battery. Make sure to check if the WakeLock is held before releasing it.
I create my WakeLock like this in onCreate of my Service:
PowerManager pm = (PowerManager) getApplicationContext().getSystemService(Context.POWER_SERVICE);
wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MusicService");
aquire:
wakeLock.acquire();
release:
if(wakeLock.isHeld())
wakeLock.release();
Tested the Playback now for about 10 Minutes and didn't stop until now. I don't know if this is a very battery-saving solution
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.
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.