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

It isn't being called because the app is NOT being restarted.

As I said, the ONLY thing app killers can do now is the same thing that the OOM killer does when it needs memory, and this NEVER involved a broadcast.

You have lost nothing here from previous versions of the platform.

On Fri, Jul 30, 2010 at 1:27 PM, tomei.ningen45@gmail.com <tomei.ningen45@gmail.com> wrote:

Hi Dianne,

Our main problem is that Intent.ACTION_PACKAGE_RESTARTED is no longer
called in Froyo.

(Sorry I digressed to Service ... I thought that I can implement
something similar to Intent.ACTION_PACKAGE_RESTARTED by running a
service from my app. If the app is killed, the Service can detect that
the app is killed -- by checking the length of its callback list --
and then take appropriate clean up actions.)

Anyway, we used to listen to Intent.ACTION_PACKAGE_RESTARTED to do
clean ups. But on Froyo, when an app is killed using
killBackgroundProcesses, we don't get any notification.

This is a pretty big incompatible change (as I mentioned above, you
see left-over icons in the status bar from killed apps).

Is this an intentional change in Froyo?

Thanks

On Jul 30, 12:38 pm, Dianne Hackborn <hack...@android.com> wrote:
> 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 <hack...@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.ninge...@gmail.com <

> > tomei.ninge...@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>

> >> <android-developers%2Bunsubscribe@googlegroups.com<android-developers%252Bunsubscribe@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<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.
>
> --
> 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.

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