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, [email protected] < [email protected]> 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 <[email protected]> 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, [email protected] < > > > > [email protected]> 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 <[email protected]> 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 < > [email protected] > > > >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, [email protected] < > > > > > [email protected]> 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 <[email protected]> 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, [email protected] < > > > > > > >> > [email protected]> 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 > > > > >> [email protected] > > > > >> > > To unsubscribe from this group, send email to > > > > >> > > [email protected]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > <android-developers%[email protected]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > > > > >> <android-developers%[email protected]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > <android-developers%[email protected]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > > > > >> > > For more options, visit this group at > > > > >> > >http://groups.google.com/group/android-developers?hl=en > > > > > > >> > -- > > > > >> > Dianne Hackborn > > > > >> > Android framework engineer > > > > >> > [email protected] > > > > > > >> > 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 > > > [email protected] > > > > >> To unsubscribe from this group, send email to > > > > >> [email protected]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > <android-developers%[email protected]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > > > > >> For more options, visit this group at > > > > >>http://groups.google.com/group/android-developers?hl=en > > > > > > > -- > > > > > Dianne Hackborn > > > > > Android framework engineer > > > > > [email protected] > > > > > > > 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 [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
