Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Hello Dianne,
Unfortunately since Android KitKat, the process is killed with its
background services, and those are not restarted as they should (when using
STICKY service). This is a serious issue for any widget app or any
background services meant to stay alive.
At the same time this happens, Android app settings shows the service as
still running whereas it is not. On the other side, I confirm that a
foreground service prevents the app from being killed at all.
See here about the mentioned issue (service not restarted):
https://groups.google.com/forum/#!topic/android-developers/H-DSQ4-tiac
Will this get fixed any time soon and does Google acknowledge the issue in
any ways? The best apps in Play Store (as marked by Google Play Store team)
are definitely affected by this as widgets no longer gets updated!
Reproducing this is fairly easy: Have an app which contains an activity and
a background sticky service. Swipe the activity, the whole process is
killed, service is not restarted, Android app settings shows service as
running. Logs confirm the service is not scheduled for restart.
On Sunday, July 22, 2012 9:19:23 AM UTC+2, Dianne Hackborn wrote:
TransactionTooLarge means that the data being sent through the IPC call is
too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrew...@gmail.comjavascript:
wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling
[android-developers] Re: Jelly bean swiping task away from task list kills service
As this issue is still present, I've tracked it down further into the broadcast receiver code. When the broadcast is being delivered it removes the service from foreground state and then kills it. Info added here, since the workaround is not good. https://code.google.com/p/android/issues/detail?id=53313#c3 On Thursday, July 19, 2012 5:19:22 PM UTC-4, Andy dev wrote: I've got a service running (an accessibility service called MainRunningService) and also use an alarmmanager within my app. On ICS when a user pulled up the task list and swiped the app away the service kept running, but the user interface was cleared from the stack. On jelly bean I'm finding this to be a little different. It seems like it kills off the service and then restarts it even if I've got an icon in the notification bar and I've got the app set to run in the foreground. This is killing off all my current app state and causing it to stop working. I'm seeing this in the logs 07-19 21:47:42.213: I/ActivityManager(307): Killing 834:com.example.android.appname/u0a72: remove task 07-19 21:47:42.236: W/AudioService(307): AudioFocus audio focus client died 07-19 21:47:42.236: I/AudioService(307): AudioFocus abandonAudioFocus(): removing entry for android.media.AudioManager@41a42020com.example.android.appname.service.MainRunningService$1@41963ec0javascript: 07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of crashed service com.rageconsulting.android.appname/.service.MainRunningService in 5000ms For the persistent Icon I'm doing the following: Notification foregroundNotification; foregroundNotification = new Notification(R.drawable.iconx,Example starting notification,System.currentTimeMillis()); Intent i=new Intent(this, MainUIActivity.class); i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP|Intent.FLAG_ACTIVITY_SINGLE_TOP); foregroundNotification.flags|=Notification.FLAG_NO_CLEAR; startForeground(9642, foregroundNotification); Is there something I'm doing wrong? I've never had a problem in the past with this code, but it's not very good on jelly bean. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
As this issue is still present, I've tracked it down further into the broadcast receiver code. When the broadcast is being delivered it removes the service from foreground state and then kills it. Bug created here since the workaround provided is no good. http://code.google.com/p/android/issues/detail?id=62091 On Tuesday, July 24, 2012 3:05:53 AM UTC-4, Dianne Hackborn wrote: Could you include a binary? I just want to see what the platform is doing; I don't need to look at the code. Thanks! -- Dianne Hackborn Android framework engineer hac...@android.com javascript: Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Could you include a binary? I just want to see what the platform is doing;
I don't need to look at the code. Thanks!
On Mon, Jul 23, 2012 at 10:40 PM, Andy dev andrewpmo...@gmail.com wrote:
Dianne, I've created a very cut down version of my app where I'm still
getting the issue. I've uploaded it to google drive here:
https://docs.google.com/open?id=0B9RsW3kcQ9jPem9PLVIxdWdlQlU
Basically, build and install the code and switch on accessibility for the
app. Run the app and then change focus to a home screen or another app etc.
Then receive a text message. You'll see the logcat line showing up for the
new text message.
Then use the tasklist to swipe away the app.
Get another text message and as it arrives the service will crash, restart
and you won't see the logcat message appear in the logs.
The code is a little hacked together just to try and minimize the code for
you to look at to try and recreate the issue. Let me know if you can't get
it working or having any questions.
On Sunday, July 22, 2012 8:19:23 AM UTC+1, Dianne Hackborn wrote:
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to ComponentInfo{com.example.**android.app/com.example.**
android.app.receiver.**SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309): android.os.**
TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.**transact(Native
Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.**
ApplicationThreadProxy.**scheduleReceiver(**
ApplicationThreadNative.java:**767)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
BroadcastQueue.**processCurBroadcastLocked(**BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
BroadcastQueue.**processNextBroadcast(**BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
ActivityManagerService.**finishReceiver(**ActivityManagerService.java:**
13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.**
ActivityManagerNative.**onTransact(**ActivityManagerNative.java:**346)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
ActivityManagerService.**onTransact(**ActivityManagerService.java:**
1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.os.Binder.**
execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(**Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of
crashed service com.example.android.app/.**service.MainRunningService
in
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Here's the apk: https://docs.google.com/open?id=0B9RsW3kcQ9jPem9PLVIxdWdlQlU
On 24 Jul 2012 08:08, Dianne Hackborn hack...@android.com wrote:
Could you include a binary? I just want to see what the platform is
doing; I don't need to look at the code. Thanks!
On Mon, Jul 23, 2012 at 10:40 PM, Andy dev andrewpmo...@gmail.com wrote:
Dianne, I've created a very cut down version of my app where I'm still
getting the issue. I've uploaded it to google drive here:
https://docs.google.com/open?id=0B9RsW3kcQ9jPem9PLVIxdWdlQlU
Basically, build and install the code and switch on accessibility for the
app. Run the app and then change focus to a home screen or another app etc.
Then receive a text message. You'll see the logcat line showing up for
the new text message.
Then use the tasklist to swipe away the app.
Get another text message and as it arrives the service will crash,
restart and you won't see the logcat message appear in the logs.
The code is a little hacked together just to try and minimize the code
for you to look at to try and recreate the issue. Let me know if you can't
get it working or having any questions.
On Sunday, July 22, 2012 8:19:23 AM UTC+1, Dianne Hackborn wrote:
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.comwrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to ComponentInfo{com.example.**android.app/com.example.**
android.app.receiver.**SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309): android.os.**
TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at android.os.BinderProxy.*
*transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.**
ApplicationThreadProxy.**scheduleReceiver(**
ApplicationThreadNative.java:**767)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
BroadcastQueue.**processCurBroadcastLocked(**BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
BroadcastQueue.**processNextBroadcast(**BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
ActivityManagerService.**finishReceiver(**ActivityManagerService.java:*
*13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.**
ActivityManagerNative.**onTransact(**ActivityManagerNative.java:**346)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
ActivityManagerService.**onTransact(**ActivityManagerService.java:**
1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.os.Binder.**
execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(**Native
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Here's a link to the binary:
https://docs.google.com/open?id=0B9RsW3kcQ9jPem9PLVIxdWdlQlU
Thanks!
On Tuesday, July 24, 2012 8:05:53 AM UTC+1, Dianne Hackborn wrote:
Could you include a binary? I just want to see what the platform is
doing; I don't need to look at the code. Thanks!
On Mon, Jul 23, 2012 at 10:40 PM, Andy dev andrewpmo...@gmail.com wrote:
Dianne, I've created a very cut down version of my app where I'm still
getting the issue. I've uploaded it to google drive here:
https://docs.google.com/open?id=0B9RsW3kcQ9jPem9PLVIxdWdlQlU
Basically, build and install the code and switch on accessibility for the
app. Run the app and then change focus to a home screen or another app etc.
Then receive a text message. You'll see the logcat line showing up for
the new text message.
Then use the tasklist to swipe away the app.
Get another text message and as it arrives the service will crash,
restart and you won't see the logcat message appear in the logs.
The code is a little hacked together just to try and minimize the code
for you to look at to try and recreate the issue. Let me know if you can't
get it working or having any questions.
On Sunday, July 22, 2012 8:19:23 AM UTC+1, Dianne Hackborn wrote:
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.comwrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the
broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in
the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to ComponentInfo{com.example.**android.app/com.example.**
android.app.receiver.**SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309): android.os.**
TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at android.os.BinderProxy.*
*transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.**
ApplicationThreadProxy.**scheduleReceiver(**
ApplicationThreadNative.java:**767)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
BroadcastQueue.**processCurBroadcastLocked(**BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
BroadcastQueue.**processNextBroadcast(**BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
ActivityManagerService.**finishReceiver(**ActivityManagerService.java:*
*13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.**
ActivityManagerNative.**onTransact(**ActivityManagerNative.java:**346)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
ActivityManagerService.**onTransact(**ActivityManagerService.java:**
1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.os.Binder.**
execTransact(Binder.java:367)
07-21
RE: [android-developers] Re: Jelly bean swiping task away from task list kills service
Date: Fri, 20 Jul 2012 14:39:12 -0700 From: andrewpmo...@gmail.com To: android-developers@googlegroups.com Subject: [android-developers] Re: Jelly bean swiping task away from task list kills service Anyone at least confirm what I'm doing looks ok - even if you don't know the reason why. Just as a sanity check? On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote:I've got a service running (an accessibility service called MainRunningService) and also use an alarmmanager within my app. On ICS when a user pulled up the task list and swiped the app away the service kept running, but the user interface was cleared from the stack. On jelly bean I'm finding this to be a little different. It seems like it kills off the service and then restarts it even if I've got an icon in the notification bar and I've got the app set to run in the foreground. This is killing off all my current app state and causing it to stop working. I'm seeing this in the logs 07-19 21:47:42.213: I/ActivityManager(307): Killing 834:com.example.android.appname/u0a72: remove task 07-19 21:47:42.236: W/AudioService(307): AudioFocus audio focus client died 07-19 21:47:42.236: I/AudioService(307): AudioFocus abandonAudioFocus(): removing entry for android.media.AudioManager@41a42020com.example.android.appname.service.MainRunningService$1@41963ec0 07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of crashed service com.rageconsulting.android.appname/.service.MainRunningService in 5000ms For the persistent Icon I'm doing the following:Notification foregroundNotification; foregroundNotification = new Notification(R.drawable.iconx,Example starting notification,System.currentTimeMillis()); Intent i=new Intent(this, MainUIActivity.class); i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP|Intent.FLAG_ACTIVITY_SINGLE_TOP); foregroundNotification.flags|=Notification.FLAG_NO_CLEAR; startForeground(9642, foregroundNotification); Is there something I'm doing wrong? I've never had a problem in the past with this code, but it's not very good on jelly bean. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Dianne, I've created a very cut down version of my app where I'm still
getting the issue. I've uploaded it to google drive here:
https://docs.google.com/open?id=0B9RsW3kcQ9jPem9PLVIxdWdlQlU
Basically, build and install the code and switch on accessibility for the
app. Run the app and then change focus to a home screen or another app etc.
Then receive a text message. You'll see the logcat line showing up for the
new text message.
Then use the tasklist to swipe away the app.
Get another text message and as it arrives the service will crash, restart
and you won't see the logcat message appear in the logs.
The code is a little hacked together just to try and minimize the code for
you to look at to try and recreate the issue. Let me know if you can't get
it working or having any questions.
On Sunday, July 22, 2012 8:19:23 AM UTC+1, Dianne Hackborn wrote:
TransactionTooLarge means that the data being sent through the IPC call is
too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of crashed
service com.example.android.app/.service.MainRunningService in 5000ms
To be honest, I've tried to read about the TransactionTooLargeException,
but I don't feel any wiser!
On Friday, July 20, 2012 11:23:11 PM UTC+1, Andy dev wrote:
Thanks. I'll keep looking for a solution
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
TransactionTooLarge means that the data being sent through the IPC call is
too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is if
the process is at an oom_adj level that is safe to kill by the OOM killer.
Just running a background service means it is safe to kill; the service
itself will be restarted if you have indicated this is what you want. This
is not a new situation that your app needs to deal with -- its process
could always have been killed while in this state if memory was needed
elsewhere (for example if the user launches a game that uses a lot of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as you
describe it -- yes your process gets killed, but this is a normal part of
operation you should be dealing with, and if you can't recover when it is
restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of crashed
service com.example.android.app/.service.MainRunningService in 5000ms
To be honest, I've tried to read about the TransactionTooLargeException,
but I don't feel any wiser!
On Friday, July 20, 2012 11:23:11 PM UTC+1, Andy dev wrote:
Thanks. I'll keep looking for a solution then!
On Friday, July 20, 2012 11:04:13 PM UTC+1, Kostya Vasilyev wrote:
Yep, I can confirm this with my own foreground service on 4.1.1 (Galaxy
Nexus).
-- K
2012/7/21 Andy dev andrewpmo...@gmail.com
Anyone at least confirm what I'm doing looks ok - even if you don't
know the reason why. Just as a sanity check?
On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote:
I've got a service running (an accessibility service called
MainRunningService) and also use an alarmmanager within my app.
On ICS when a user pulled up the task list and swiped the app away the
service kept running, but the user interface was cleared from the stack.
On jelly bean I'm finding this to be a little different. It seems like
it kills off the service and then restarts it even if I've got an icon in
the notification bar and I've got the app set to run in the foreground.
This is killing off all my current app state and causing it to stop
working.
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
I'm also seeing my application get killed even while it has a foreground
service.
It appears to happen on the next sendBroadcast() - which is an
implementation detail of how some of my components interact, and has
nothing to do with the service's startForeground() state. The service
remains in foreground state at this point (and is supposed to last about a
dozen seconds more).
Instead, the process gets killed, and I'm also seeing an
android.os.TransactionTooLargeException in the logcat.
The exception looks to me like an unfortunate and unexpected side effect of
the process getting killed.
The broadcast in question is sent farly often, its data payload is only a
few dozen bytes, and so it never triggers this exception under normal
circumstances.
-- K
2012/7/22 Dianne Hackborn hack...@android.com
TransactionTooLarge means that the data being sent through the IPC call is
too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of crashed
service com.example.android.app/.service.MainRunningService in 5000ms
To be honest, I've tried to read about the TransactionTooLargeException,
but I don't feel any wiser!
On Friday, July 20, 2012 11:23:11 PM UTC+1, Andy dev wrote:
Thanks. I'll keep looking for a solution then!
On Friday, July 20, 2012 11:04:13 PM UTC+1, Kostya Vasilyev wrote:
Yep, I can confirm this with my own foreground
[android-developers] Re: Jelly bean swiping task away from task list kills service
Oh boy, I very much don't like the sound of that. Not particularly looking forward to getting a JB OTA update anymore after all the other backwards compat problems already reported by users. Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Kostya, after tracking mine down more, it seems to be exactly the same.
It doesn't actually get killed until I get a broadcast. I'm not sending
them I'm receiving them from things like the SMS service, the battery level
the screen state etc, but any of those I've registered for cause the issue.
I'm not exactly sure which transaction is even going on at this point.
Dianne, thanks for your reply I really appriciate it, especially given your
position in the android team. I'll try and work on cutting down my code
into a manageable example as it's several hundred classes at the moment
(it's the app Light Flow in the market). I do hold quite a bit in static
variables, does any of that make a difference in this situation?
On Sunday, July 22, 2012 11:14:16 AM UTC+1, Kostya Vasilyev wrote:
I'm also seeing my application get killed even while it has a foreground
service.
It appears to happen on the next sendBroadcast() - which is an
implementation detail of how some of my components interact, and has
nothing to do with the service's startForeground() state. The service
remains in foreground state at this point (and is supposed to last about a
dozen seconds more).
Instead, the process gets killed, and I'm also seeing an
android.os.TransactionTooLargeException in the logcat.
The exception looks to me like an unfortunate and unexpected side effect
of the process getting killed.
The broadcast in question is sent farly often, its data payload is only a
few dozen bytes, and so it never triggers this exception under normal
circumstances.
-- K
2012/7/22 Dianne Hackborn hack...@android.com
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
2012/7/22 Pent supp...@apps.dinglisch.net Oh boy, I very much don't like the sound of that. Not particularly looking forward to getting a JB OTA update anymore after all the other backwards compat problems already reported by users. You can look forward to 4.1.2, 4.2 or 5.0... Pent -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
2012/7/22 Andy dev andrewpmo...@gmail.com
Kostya, after tracking mine down more, it seems to be exactly the same.
It doesn't actually get killed until I get a broadcast. I'm not sending
them I'm receiving them from things like the SMS service, the battery level
the screen state etc, but any of those I've registered for cause the issue.
Well, my code sends broadcasts between the app's components, which is very
nearly synchronous, so I could not tell the difference.
I actually created and ran a small test, and can confirm this behavior with
100% certainty.
-- K
I'm not exactly sure which transaction is even going on at this point.
Dianne, thanks for your reply I really appriciate it, especially given
your position in the android team. I'll try and work on cutting down my
code into a manageable example as it's several hundred classes at the
moment (it's the app Light Flow in the market). I do hold quite a bit in
static variables, does any of that make a difference in this situation?
On Sunday, July 22, 2012 11:14:16 AM UTC+1, Kostya Vasilyev wrote:
I'm also seeing my application get killed even while it has a foreground
service.
It appears to happen on the next sendBroadcast() - which is an
implementation detail of how some of my components interact, and has
nothing to do with the service's startForeground() state. The service
remains in foreground state at this point (and is supposed to last about a
dozen seconds more).
Instead, the process gets killed, and I'm also seeing an
android.os.**TransactionTooLargeException
in the logcat.
The exception looks to me like an unfortunate and unexpected side effect
of the process getting killed.
The broadcast in question is sent farly often, its data payload is only a
few dozen bytes, and so it never triggers this exception under normal
circumstances.
-- K
2012/7/22 Dianne Hackborn hack...@android.com
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.comwrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to ComponentInfo{com.example.**android.app/com.example.**
android.app.receiver.**SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309): android.os.**
TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at android.os.BinderProxy.*
*transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.**
ApplicationThreadProxy.**scheduleReceiver(**
ApplicationThreadNative.java:**767)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
BroadcastQueue.**processCurBroadcastLocked(**BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
I always wondered about this feature... i found out Foreground services
keep on running by accident... kinda surprised me since you then have to
make sure the code knows how to retain information the Service is
responsible of if the UI is brought back up.
Is any of this documented anywhere? i couldn't find any reference to it
(barely any reference to what swiping an app away from the Recents list
does actually)
On Sunday, July 22, 2012 10:19:23 AM UTC+3, Dianne Hackborn wrote:
TransactionTooLarge means that the data being sent through the IPC call is
too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of crashed
service com.example.android.app/.service.MainRunningService in 5000ms
To be honest, I've tried to read about the TransactionTooLargeException,
but I don't feel any wiser!
On Friday, July 20, 2012 11:23:11 PM UTC+1, Andy dev wrote:
Thanks. I'll keep looking for a solution then!
On Friday, July 20, 2012 11:04:13 PM UTC+1, Kostya Vasilyev wrote:
Yep, I can confirm this with my own foreground service on 4.1.1 (Galaxy
Nexus).
-- K
2012/7/21 Andy dev andrewpmo...@gmail.com
Anyone at least confirm what I'm doing looks ok - even if you don't
know the reason why. Just as a sanity check?
On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote:
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Kostya, is there any chance of sending me your small test? I'm hoping I can
try compare that with my code and make some progress, or at least help me
get together a small example for Dianne. If you do, could you send it to
andrew at rageconsulting dot com
Andrew
On Sunday, July 22, 2012 1:05:48 PM UTC+1, Kostya Vasilyev wrote:
2012/7/22 Andy dev andrewpmo...@gmail.com
Kostya, after tracking mine down more, it seems to be exactly the same.
It doesn't actually get killed until I get a broadcast. I'm not sending
them I'm receiving them from things like the SMS service, the battery level
the screen state etc, but any of those I've registered for cause the issue.
Well, my code sends broadcasts between the app's components, which is very
nearly synchronous, so I could not tell the difference.
I actually created and ran a small test, and can confirm this
behavior with 100% certainty.
-- K
I'm not exactly sure which transaction is even going on at this point.
Dianne, thanks for your reply I really appriciate it, especially given
your position in the android team. I'll try and work on cutting down my
code into a manageable example as it's several hundred classes at the
moment (it's the app Light Flow in the market). I do hold quite a bit in
static variables, does any of that make a difference in this situation?
On Sunday, July 22, 2012 11:14:16 AM UTC+1, Kostya Vasilyev wrote:
I'm also seeing my application get killed even while it has a foreground
service.
It appears to happen on the next sendBroadcast() - which is an
implementation detail of how some of my components interact, and has
nothing to do with the service's startForeground() state. The service
remains in foreground state at this point (and is supposed to last about a
dozen seconds more).
Instead, the process gets killed, and I'm also seeing an
android.os.**TransactionTooLargeException
in the logcat.
The exception looks to me like an unfortunate and unexpected side effect
of the process getting killed.
The broadcast in question is sent farly often, its data payload is only
a few dozen bytes, and so it never triggers this exception under normal
circumstances.
-- K
2012/7/22 Dianne Hackborn hack...@android.com
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be
killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that
is if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.comwrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the
broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in
the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION
!!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to ComponentInfo{com.example.**android.app/com.example.**
android.app.receiver.**SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309): android.os.**
TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending broadcast
to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of crashed
service com.example.android.app/.service.MainRunningService in 5000ms
To be honest, I've tried to read about the TransactionTooLargeException,
but I don't feel any wiser!
On Friday, July 20, 2012 11:23:11 PM UTC+1, Andy dev wrote:
Thanks. I'll keep looking for a solution then!
On Friday, July 20, 2012 11:04:13 PM UTC+1, Kostya Vasilyev wrote:
Yep, I can confirm this with my own foreground service on 4.1.1 (Galaxy
Nexus).
-- K
2012/7/21 Andy dev andrewpmo...@gmail.com
Anyone at least confirm what I'm doing looks ok - even if you don't know
the reason why. Just as a sanity check?
On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote:
I've got a service running (an accessibility service called
MainRunningService) and also use an alarmmanager within my app.
On ICS when a user pulled up the task list and swiped the app away the
service kept running, but the user interface was cleared from the stack.
On jelly bean I'm finding this to be a little different. It seems like
it kills off the service and then restarts it even if I've got an icon in
the notification bar and I've got the app set to run in the foreground.
This is killing off all my current app state and causing it to stop
working.
I'm seeing this in the logs
07-19 21:47:42.213: I/ActivityManager(307): Killing
834:com.example.android.**appname/u0a72: remove task
07-19 21:47:42.236: W/AudioService(307): AudioFocus audio focus
client died
07-19 21:47:42.236: I/AudioService(307): AudioFocus
abandonAudioFocus(): removing entry for android.media.AudioManager@**
41a42020com.example.android.**appname.service.**
MainRunningService$1@41963ec0android.media.AudioManager@41a42020com.example.android.appname.service.MainRunningService$1@41963ec0
07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of
crashed service
com.rageconsulting.android.**appname/.service.**MainRunningService
in 5000ms
For the persistent Icon I'm doing the following:
Notification foregroundNotification;
foregroundNotification = new Notification(R.drawable.iconx,**Example
starting notification,System.**currentTimeMillis());
Intent i=new Intent(this, MainUIActivity.class);
i.setFlags(Intent.FLAG_**ACTIVITY_CLEAR_TOP|Intent.**
FLAG_ACTIVITY_SINGLE_TOP);
foregroundNotification.flags|=**Notification.FLAG_NO_CLEAR;
startForeground(9642, foregroundNotification);
Is there something I'm doing wrong? I've never had a problem in the
past with this code, but it's not very good on jelly bean.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
[android-developers] Re: Jelly bean swiping task away from task list kills service
Anyone at least confirm what I'm doing looks ok - even if you don't know the reason why. Just as a sanity check? On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote: I've got a service running (an accessibility service called MainRunningService) and also use an alarmmanager within my app. On ICS when a user pulled up the task list and swiped the app away the service kept running, but the user interface was cleared from the stack. On jelly bean I'm finding this to be a little different. It seems like it kills off the service and then restarts it even if I've got an icon in the notification bar and I've got the app set to run in the foreground. This is killing off all my current app state and causing it to stop working. I'm seeing this in the logs 07-19 21:47:42.213: I/ActivityManager(307): Killing 834:com.example.android.appname/u0a72: remove task 07-19 21:47:42.236: W/AudioService(307): AudioFocus audio focus client died 07-19 21:47:42.236: I/AudioService(307): AudioFocus abandonAudioFocus(): removing entry for android.media.AudioManager@41a42020com.example.android.appname.service.MainRunningService$1@41963ec0 07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of crashed service com.rageconsulting.android.appname/.service.MainRunningService in 5000ms For the persistent Icon I'm doing the following: Notification foregroundNotification; foregroundNotification = new Notification(R.drawable.iconx,Example starting notification,System.currentTimeMillis()); Intent i=new Intent(this, MainUIActivity.class); i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP|Intent.FLAG_ACTIVITY_SINGLE_TOP); foregroundNotification.flags|=Notification.FLAG_NO_CLEAR; startForeground(9642, foregroundNotification); Is there something I'm doing wrong? I've never had a problem in the past with this code, but it's not very good on jelly bean. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Yep, I can confirm this with my own foreground service on 4.1.1 (Galaxy Nexus). -- K 2012/7/21 Andy dev andrewpmo...@gmail.com Anyone at least confirm what I'm doing looks ok - even if you don't know the reason why. Just as a sanity check? On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote: I've got a service running (an accessibility service called MainRunningService) and also use an alarmmanager within my app. On ICS when a user pulled up the task list and swiped the app away the service kept running, but the user interface was cleared from the stack. On jelly bean I'm finding this to be a little different. It seems like it kills off the service and then restarts it even if I've got an icon in the notification bar and I've got the app set to run in the foreground. This is killing off all my current app state and causing it to stop working. I'm seeing this in the logs 07-19 21:47:42.213: I/ActivityManager(307): Killing 834:com.example.android.**appname/u0a72: remove task 07-19 21:47:42.236: W/AudioService(307): AudioFocus audio focus client died 07-19 21:47:42.236: I/AudioService(307): AudioFocus abandonAudioFocus(): removing entry for android.media.AudioManager@** 41a42020com.example.android.**appname.service.** MainRunningService$1@41963ec0android.media.AudioManager@41a42020com.example.android.appname.service.MainRunningService$1@41963ec0 07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of crashed service com.rageconsulting.android.**appname/.service.**MainRunningService in 5000ms For the persistent Icon I'm doing the following: Notification foregroundNotification; foregroundNotification = new Notification(R.drawable.iconx,**Example starting notification,System.**currentTimeMillis()); Intent i=new Intent(this, MainUIActivity.class); i.setFlags(Intent.FLAG_**ACTIVITY_CLEAR_TOP|Intent.** FLAG_ACTIVITY_SINGLE_TOP); foregroundNotification.flags|=**Notification.FLAG_NO_CLEAR; startForeground(9642, foregroundNotification); Is there something I'm doing wrong? I've never had a problem in the past with this code, but it's not very good on jelly bean. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Thanks. I'll keep looking for a solution then! On Friday, July 20, 2012 11:04:13 PM UTC+1, Kostya Vasilyev wrote: Yep, I can confirm this with my own foreground service on 4.1.1 (Galaxy Nexus). -- K 2012/7/21 Andy dev andrewpmo...@gmail.com Anyone at least confirm what I'm doing looks ok - even if you don't know the reason why. Just as a sanity check? On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote: I've got a service running (an accessibility service called MainRunningService) and also use an alarmmanager within my app. On ICS when a user pulled up the task list and swiped the app away the service kept running, but the user interface was cleared from the stack. On jelly bean I'm finding this to be a little different. It seems like it kills off the service and then restarts it even if I've got an icon in the notification bar and I've got the app set to run in the foreground. This is killing off all my current app state and causing it to stop working. I'm seeing this in the logs 07-19 21:47:42.213: I/ActivityManager(307): Killing 834:com.example.android.**appname/u0a72: remove task 07-19 21:47:42.236: W/AudioService(307): AudioFocus audio focus client died 07-19 21:47:42.236: I/AudioService(307): AudioFocus abandonAudioFocus(): removing entry for android.media.AudioManager@** 41a42020com.example.android.**appname.service.** MainRunningService$1@41963ec0android.media.AudioManager@41a42020com.example.android.appname.service.MainRunningService$1@41963ec0 07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of crashed service com.rageconsulting.android.**appname/.service.**MainRunningService in 5000ms For the persistent Icon I'm doing the following: Notification foregroundNotification; foregroundNotification = new Notification(R.drawable.iconx,**Example starting notification,System.**currentTimeMillis()); Intent i=new Intent(this, MainUIActivity.class); i.setFlags(Intent.FLAG_**ACTIVITY_CLEAR_TOP|Intent.** FLAG_ACTIVITY_SINGLE_TOP); foregroundNotification.flags|=**Notification.FLAG_NO_CLEAR; startForeground(9642, foregroundNotification); Is there something I'm doing wrong? I've never had a problem in the past with this code, but it's not very good on jelly bean. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
