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_**
>>>>>> 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 <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>
>>>>>
>>>>
>>>>  -- 
>> 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

Reply via email to