Re: [android-developers] Re: Froyo -- How to detect that my application has been killed?
On Mon, Aug 2, 2010 at 5:44 PM, tomei.ninge...@gmail.com < tomei.ninge...@gmail.com> wrote: > I could wait a little time after going in BG, and then clear cache. > But what if the app gets killed before my timer expires? > The alarm manager would allow you to wake up. > I can't clear cache immediately on going to BG, or else the app > performance will suck. > Is there a solution to this dilemma? > Your requirement is not something I've seen an app need before (not even the browser), and you aren't giving any information about what is driving this, so it is hard to give much help. -- 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
Re: [android-developers] Re: Froyo -- How to detect that my application has been killed?
Correct, onDestroy() is not called when it is killed. This is the same as
activity -- the kernel kills processes when needed, not waiting for the app.
The status bar is correctly keeping the icon. The service will later be
restarted; it has not been stopped.
It is normal for background services to be killed regularly. This is
intentional, because generally background services are not something the
user is directly aware of, and restarting their processes every now and then
avoids issues with such services consuming increasing amounts of RAM.
If your service is something the user is actually aware of (such as music
playback), consider Service.startForeground().
On Sat, Jul 31, 2010 at 2:08 AM, Happy C. wrote:
> Hi Dianne,
> I have the same issue with the froyo.
>
> I use the start service UI as the following code.
>
> //CurrentActivity.java (extend from ListActivity)
> Intent intent_start_service=new
> Intent(CurrentActivity.this,MyRunningService.class);
> intent_start_service.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
> startService(intent_start_service);
>
> I always get the following log message after starting the service
> around 30 mins~2hours, and the service is not working anymore.
>
> 07-31 15:03:00.001: INFO/ActivityManager(85): No longer want
> com.Myapplication (pid 4726): hidden #16
> 07-31 15:03:00.091: WARN/ActivityManager(85): Scheduling restart of
> crashed service com.Myapplication/.MyRunningService in 5000ms
> 07-31 15:03:05.131: INFO/ActivityManager(85): Start proc
> com.Myapplication for service com.Myapplication/.MyRunningService:
> pid=5045 uid=10077 gids={}
>
> The MyRunningService seems to be killed by the OOM, and the
> notification icon on the status bar with "Ongoing" is also shown to
> the user. Besides, I don't see any message from my customized log
> message in the onDestroy() of this service.
>
> //MyRunningService.java
>
>public void onDestroy()
>{
> Log.e(TAG,"Oh!!MyRunningService was killed ");
> }
> //
>
> The issues:
> 1. Why MyRunningService is always killed by the OOM? Can I prevent it
> or can I detect the killing behavior by the service itself and restart
> the service automatically with some good solution?
> 2. Is there any way to clean the notification icon as the service is
> been killing ?
>
> Thank you very much!
>
>
> On 7月31日, 上午3時38分, Dianne Hackborn wrote:
>
> > 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.
>
> --
> 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
>
--
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
Re: [android-developers] Re: Froyo -- How to detect that my application has been killed?
Everything in the system that handles RESTARTED is to clear its state when
the app is force stopped. It is all correct. Task managers can no longer
force stop.
Again, task managers can no longer do anything more than the low memory
killer does. There is not a problem here that apps haven't already had to
deal with since 1.0.
As far as a cache -- you shouldn't count on your process being evicted to
clear a cache. This has problems the other way -- there is no guarantee
your app will be killed *ever* while in the background, since it may never
clear its cache. You should use other policies for this. For example,
after a certain amount of time (via the alarm manager maybe), etc.
On Mon, Aug 2, 2010 at 12:21 PM, tomei.ninge...@gmail.com <
tomei.ninge...@gmail.com> wrote:
> Hi Dianne,
>
> I understand that we need to handle app killed by LMK. If we can
> handle LMK, we can also handle the new Froyo kill-by-task-manager
> behavior.
>
> Do you have any suggestion about this:
>
> For example, let's say our app creates a 10MB cache file. When the app
> exits, we want to delete this cache file. How to do this in the case
> of killed-by-LMK?
>
> Is there any suggestion better than "just don't use a large cache
> file"?
>
> BTW, there are a lot of code in Froyo system services that rely on
> Intent.ACTION_PACKAGE_RESTARTED (such as StatusBarService). I think
> these probably need to be fixed.
>
> Thanks!
>
>
> On Jul 30, 2:30 pm, Dianne Hackborn wrote:
> > 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 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
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.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 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 >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. Th
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 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 2ms
>>
>> [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 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.
>> >
>
Re: [android-developers] Re: Froyo -- How to detect that my application has been killed?
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 2ms
>
> [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 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 2ms
> >
> > > 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
>
> >
> > > 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
>
--
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
