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.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. >>>>>>>> >>>>>>>> I'm seeing this in the logs >>>>>>>> >>>>>>>> 07-19 21:47:42.213: I/ActivityManager(307): Killing >>>>>>>> 834:com.example.android.**appnam****e/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@ >>>>>>>> **41a****42020com.example.android.**appna****me.service.** >>>>>>>> MainRunningService$****1@41963ec0<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.**app****name/.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_**ACTIVIT****Y_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@** >>>>>>> googlegroup**s.com <android-developers@googlegroups.com> >>>>>>> To unsubscribe from this group, send email to >>>>>>> android-developers+**unsubscribe**@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> >>>>>>> For more options, visit this group at >>>>>>> http://groups.google.com/**group**/android-developers?hl=en<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 <android-developers@googlegroups.com> >>>> To unsubscribe from this group, send email to >>>> android-developers+**unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> >>>> For more options, visit this group at >>>> http://groups.google.com/**group/android-developers?hl=en<http://groups.google.com/group/android-developers?hl=en> >>>> >>> >>> >>> >>> -- >>> Dianne Hackborn >>> Android framework engineer >>> hack...@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+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en >> > > > > -- > Dianne Hackborn > Android framework engineer > hack...@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
