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>
>> >
>> > > 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>
>> 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
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
