You shouldn't really be able to force the behavior by "opening many applications," since only one can be in the foreground at the time, and background applications are always killed before ones actively running services.
You can certainly force this by starting up a bunch of processes running services, in which case yes eventually there will be no more memory and something will need to go. The onLowMemory() callback happens a fair amount before any services are started -- currently it is sent when the system is not able to keep around any background processes. The next process to go will be a service, but there is a bit of a hump in memory use before that happens. The crashed service message is because all the activity manager knows is the process goes away -- this may be because the kernel killed it, or its process crashed, it can't tell between the two. As with everything else, there is no callback that happens before a service is killed, since this is done deep down in the kernel when it finds that it is getting low on memory. In general the management of running services is tricky because developers have a tendency to leave them running for longer than needed, or even just forgetting to stop them. They also often have memory leaks so as they continue to run they eat more and more memory, leaving no room for other things. So at this point the system is pretty heavy-handed with them. One thing in particular is that after a service has been running for a while, we will reclassify it as a background process, allowing it to be killed much more aggressively. As far as wake locks, the system automatically releases them when your process goes away so there is no need to worry about them when you are killed. Finally, if you are indeed showing an ongoing notification while your service is running, so the user is directly aware of what you are doing, and can explicitly stop your service when they want, then you have one additional facility available to you: Service.setForeground() will tell the system that you count as a foreground application, something the user is directly aware of, so your process will be killed much less aggressively. Please use this API only in this case (look at the media playback service as a the typical kind of behavior that should be associated with it). Actually I am starting to see apps abuse this API just to force themselves to run without those semantics, so we'll probably have to do something about it -- my current thought is to turn it into a no-op and add a new API that requires you have an ongoing notification to be counted as foreground. On Sat, Jul 18, 2009 at 5:47 AM, Mariano Kamp <[email protected]>wrote: > onDestroy() seems to be called regularly before the process vanishes, but > onDestroy() is not. The process is just gone. > > > On Wed, Jul 15, 2009 at 11:58 AM, Mariano Kamp <[email protected]>wrote: > >> Also, what is the best way to deal with wake locks in these situations? >> >> >> On Mon, Jul 13, 2009 at 1:44 PM, Mariano Kamp <[email protected]>wrote: >> >>> Hi, >>> >>> I often see that services are killed and then "restarted". >>> >>> I can force this behavior when opening many applications. >>> >>> "Low Memory" or "OutOfMemory" are not problems per se, are they? This >>> is just the normal behavior due to Android not closing applications, but >>> killing the least important processes when more memory is needed, right? The >>> terminology "crashed service" at least sounds very serious... >>> >>> D/dalvikvm( 112): GC freed 272 objects / 12256 bytes in 648ms >>> D/dalvikvm( 55): GC freed 4021 objects / 156072 bytes in 897ms >>> I/ActivityManager( 55): Process com.google.process.gapps (pid 1886) has >>> died. >>> W/ActivityManager( 55): Scheduling restart of crashed service >>> com.google.android.apps.gtalkservice/com.google.android.gtalkservice.service.GTalkService >>> in 5000ms >>> I/ActivityManager( 55): Low Memory: No more background processes. >>> I/ActivityManager( 55): Process com.tmobile.myfaves (pid 2156) has >>> died. >>> W/ActivityManager( 55): Scheduling restart of crashed service >>> com.tmobile.myfaves/.MyFavesService in 5000ms >>> I/ActivityManager( 55): Low Memory: No more background processes. >>> >>> >>> >>> D/LocationManager( 6830): removeUpdates: intent = PendingIntent{4318eb18 >>> target android.os.binderpr...@4318e870} >>> D/HTTPService( 5812): Calling: GET >>> http://brightkite.com/me/config.jsonHTTP/1.1 >>> W/InputManagerService( 55): Starting input on non-focused client >>> com.android.internal.view.iinputmethodclient$stub$pr...@4333df90(uid=10016 >>> pid=6825) >>> W/InputManagerService( 55): Client not active, ignoring focus gain of: >>> com.android.internal.view.iinputmethodclient$stub$pr...@43303ae0 >>> W/ActivityManager( 55): Activity pause timeout for >>> HistoryRecord{43593020 >>> {com.android.vending/com.android.vending.AssetBrowserActivity}} >>> D/dalvikvm( 5812): GC freed 1254 objects / 258832 bytes in 331ms >>> I/WindowManager( 55): WIN DEATH: Window{4348c1b8 >>> com.newsrob/com.newsrob.DashboardListActivity paused=false} >>> I/ActivityManager( 55): Process com.newsrob (pid 6207) has died. >>> W/ActivityManager( 55): Scheduling restart of crashed service >>> com.newsrob/.SynchronizationService in 5000ms >>> I/ActivityManager( 55): Low Memory: No more background processes. >>> W/InputManagerService( 55): Window already focused, ignoring focus gain >>> of: com.android.internal.view.iinputmethodclient$stub$pr...@43450e48 >>> W/System.err( 6830): OutOfMemory >>> D/dalvikvm( 5812): GC freed 181 objects / 190288 bytes in 625ms >>> D/dalvikvm(10389): GC freed 114 objects / 5184 bytes in 679ms >>> D/dalvikvm( 268): GC freed 12 objects / 368 bytes in 1096ms >>> D/InetAddress( 6825): android.clients.google.com: 74.125.43.101 (family >>> 2, proto 6) >>> >>> >>> Is there any guaranteed call back available to clean up first before >>> being killed? >>> >>> I set an ongoing notification when the service starts and clear it when >>> it finishes. Unfortunately the notification isn't cleared when the service >>> is just killed and it hangs around until the service is the next time >>> triggered. >>> >>> Why are those services restarted? Are they always restarted? And what >>> exactly happens when a service is restarted? Should I just clear the >>> notification in the service's onCreate() method. >>> To avoid the overhead of two processes I just use a >>> single process for my UI and the service. Should I rework my code (stop >>> sharing static variables) and use two separate processes? >>> >>> What are you guys doing in that situations? >>> >>> Cheers, >>> Mariano >>> >> >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
