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 <andrewpmoore@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.-- KI'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.-- K2012/7/22 Dianne Hackborn <hackbod@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 <andrewpmoore@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(Applicat ionThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.BroadcastQueue.processCurBroadcastLock ed(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.BroadcastQueue.processNextBroadcast(Br oadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.ActivityManagerService.finishReceiver( ActivityManagerService.java:13 281)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.ActivityManagerNative.onTransact(ActivityManager Native.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.ActivityManagerService.onTransact(Acti vityManagerService.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).-- K2012/7/21 Andy dev <andrewpmoore@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 logs07-19 21:47:42.213: I/ActivityManager(307): Killing 834:com.example.android.appname/u0a72: remove task android.media.AudioManager@41a
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 for42020com.example.android.appna me.service.MainRunningService$ 1@41963ec0
07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of crashed service com.rageconsulting.android.appname/.service.MainRunningServi ce in 5000ms For the persistent Icon I'm doing the following:Notification foregroundNotification;
foregroundNotification = new Notification(R.drawable.iconx,"Example starting notification",System.currentTi meMillis());
Intent i=new Intent(this, MainUIActivity.class);
i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP|Intent.FLAG_ACTIVI TY_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+unsubscribe@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Dianne Hackborn
Android framework engineer
hackbod@android.com
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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment