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.ninge...@gmail.com <
tomei.ninge...@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+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> <android-developers%2bunsubscr...@googlegroups.com<android-developers%252bunsubscr...@googlegroups.com>
> >
> > >> <android-developers%2bunsubscr...@googlegroups.com<android-developers%252bunsubscr...@googlegroups.com>
> <android-developers%252bunsubscr...@googlegroups.com<android-developers%25252bunsubscr...@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<android-developers%2bunsubscr...@googlegroups.com>
> <android-developers%2bunsubscr...@googlegroups.com<android-developers%252bunsubscr...@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+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@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
