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 <hack...@android.com> 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 <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
>
> ...
>
> read more »
--
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
