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.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 <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
>
--
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
