Friday, July 30, 2010

Re: [android-developers] Re: Froyo -- How to detect that my application has been killed?

Oh wait I take that back...  what has changed is that task killers no longer go through the full force stop path -- *ALL* they can do is kill processes, and further only processes that are good or moderate candidates for the out of memory killer (pure background processes up to services running in the background).

So to look at API demos -- if I use that and "Remote Service Controller" to start the remote service, then use a task killer to kill API demos, what I'll see in the log is that the two processes are simply killed, just like the OOM killer would do:

I/Process (  101): Sending signal. PID: 668 SIG: 9
I/Process (  101): Sending signal. PID: 641 SIG: 9
W/ActivityManager(  101): Scheduling restart of crashed service com.example.android.apis/.app.RemoteService in 5000ms
I/WindowManager(  101): WIN DEATH: Window{44ea7520 com.example.android.apis/com.example.android.apis.ApiDemos paused=false}
I/WindowManager(  101): WIN DEATH: Window{44d500f8 com.example.android.apis/com.example.android.apis.ApiDemos paused=false}
I/WindowManager(  101): WIN DEATH: Window{44d994d0 com.example.android.apis/com.example.android.apis.ApiDemos paused=false}
I/WindowManager(  101): WIN DEATH: Window{44eae490 com.example.android.apis/com.example.android.apis.app.RemoteService$Controller paused=false}
D/dalvikvm(  291): GC_EXPLICIT freed 484 objects / 24352 bytes in 61ms

And then a little later I correctly see that the remote service is restarted, just as happens if the process is killed by the OOM killer:

I/ActivityManager(  101): Start proc com.example.android.apis:remote for service com.example.android.apis/.app.RemoteService: pid=695 uid=10062 gids={3003, 1015, 1006}

Compare that with the output of an actual force stop which the task killers can no longer do:

I/ActivityManager(  101): Force stopping package com.example.android.apis uid=10062
I/Process (  101): Sending signal. PID: 695 SIG: 9
I/Process (  101): Sending signal. PID: 712 SIG: 9
W/ActivityManager(  101): Scheduling restart of crashed service com.example.android.apis/.app.RemoteService in 5000ms
I/ActivityManager(  101):   Force finishing activity HistoryRecord{44f23740 com.example.android.apis/.app.RemoteService$Controller}
I/ActivityManager(  101):   Force finishing activity HistoryRecord{44d43428 com.example.android.apis/.ApiDemos}
I/ActivityManager(  101):   Force finishing activity HistoryRecord{44d91560 com.example.android.apis/.ApiDemos}
I/ActivityManager(  101):   Force finishing activity HistoryRecord{44d2e2c8 com.example.android.apis/.ApiDemos}
I/ActivityManager(  101):   Force stopping service ServiceRecord{44eacb00 com.example.android.apis/.app.RemoteService}


For the behavior you are seeing, are you using the bind server instead of the start service UI?  If you do that then yes your service will not be restarted -- because the process that is bound to it is in the background, so free to be killed, and once it gets killed the binding goes away and the service does not need to run any more.

But this exact behavior is expected to happen when the device is low on memory, so it is something apps need to deal with correctly anyway.


On Fri, Jul 30, 2010 at 12:20 PM, Dianne Hackborn <hackbod@android.com> wrote:
Um yeah the check for process priority does let it kill service processes (not visible or foreground service processes though).  Whoops.  I'll fix that.

That said, the service *does* restart like it always did, and I have confirmed it does.  That code path hasn't changed at all.  So basically the behavior is still like it was pre-2.2, except there are still some processes that can unintentionally be killed.


On Fri, Jul 30, 2010 at 10:15 AM, tomei.ningen45@gmail.com <tomei.ningen45@gmail.com> wrote:
Dianne, here's the reproduction step on Froyo:

[1] Run on Froyo - start ApiDemos, start the RemoveService sample. You
will now see two processes
   com.example.android.apis
   com.example.android.apis:remote

[2] You will notice that "Sample Remote Service" appears on status
bar.

[3] write an app with KILL_BACKGROUND_PROCESSES permission. Call


ActivityManager.killBackgroundProcesses("com.example.android.apis");

[4] Both processes created at step [1] are killed.

[5] RemoveService is never restarted, even though you see something
like

W/ActivityManager( 2426): Scheduling restart of crashed service
com.example.android.apis/.app.RemoteService in 20000ms

[6] "Sample Remote Service" message still stays on status bar. This is
because StatusBarService expects a ACTION_PACKAGE_RESTARTED broadcast,
but
this braodcast is never delivered.

What's the best way to handle this -- we need to clean up some
resources if
the app process is killed.

Thanks!

On Jul 29, 8:15 pm, Dianne Hackborn <hack...@android.com> wrote:
> Applications can't kill services with this.  They can only kill background
> processes, which the OOM killer is free to kill at any time anyway.
>
> On Thu, Jul 29, 2010 at 6:37 PM, tomei.ninge...@gmail.com <
>
>
>
>
>
>
>
> tomei.ninge...@gmail.com> wrote:
> > On Froyo, we found that some new "Task Manager" apps are now using the
> > ActivityManager.killBackgroundProcesses() to kill apps. When this
> > happens, Intent.ACTION_PACKAGE_RESTARTED is no longer fired.
>
> > How can I find out that my application has been killed?
>
> > I tried to start a service, and I do see this message printed in
> > logcat:
>
> > W/ActivityManager( 2426): Scheduling restart of crashed service
> > com.example.android.apis/.app.RemoteService in 20000ms
>
> > However, the service is never restarted as advertised, if the app is
> > killed using the killBackgroundProcesses API.
>
> > (If I go into adb shell and kill the service process, the service will
> > indeed be restarted ...)
>
> > This looks like a bug anyway, because the notification created by the
> > app is no longer removed like in eclair (the StatusBarService, and a
> > bunch of other system services, depend on the
> > Intent.ACTION_PACKAGE_RESTARTED broadcast).
>
> > Thanks
>
> > --
> > 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<android-developers%2Bunsubscribe@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+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.




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

No comments:

Post a Comment