Do "adb shell dumpsys activity" to see the current state of the processes and your own. Look at the oom_adj for the processes to see which ones are more important (larger is less important >= 8 is a background process that is okay to kill, 2 is a service process that we try hard not to kill).
Service processes only start to get killed when there isn't enough memory to run any background processes, which should be rare unless a bunch of third party applications are all trying to run services. There can also be some cases where the web browser uses so much memory that all of the background processes get killed, though I have never seem that result in services being killed. Making your service more efficient is not going to cause it to be a more likely candidate to be killed. Also just for you (don't tell anyone about this, it's our little secret): http://code.google.com/android/reference/android/app/Service.html#setForeground(boolean) On Thu, Dec 11, 2008 at 5:32 PM, John Spurlock <john.spurl...@gmail.com>wrote: > > Any tips on this? Or are we on our own? This is a big issue for us > right now. > > On Dec 9, 10:40 pm, John Spurlock <john.spurl...@gmail.com> wrote: > > Would you mind clarifying this a bit? What are some techniques a > > "legitimate" background service hosting a running mediaplayer can > > employ to ensure that it does not get killed by the os? > > > > We are running into this right now - our app (hosting a running > > mediaplayer) is hosted in a service, and we are seeing our process > > killed abruptly in logcat. Ironically the more efficient we make the > > service footprint (reducing gcs -> less cpu), the higher the odds that > > it becomes a candidate for removal! > > > > Thanks, > > - John > > > > On Nov 23, 7:47 pm, "Dianne Hackborn" <hack...@android.com> wrote: > > > > > Please please please be sure to stop the service when it is no longer > > > needed. For a media player, this generally means only having it in the > > > running state when it is actively playing music; otherwise it should > only be > > > needed when there are clients bound to it. > > > > > If you don't stop your services, then the system has to assume it is > needed > > > forever and can't remove your process to allow for other things the > user is > > > actually doing. I think this is actually one of our biggest third > party > > > application issues, applications that just starts a service and never > stops > > > it. This sucks for the user, and just should not be done. In fact > there is > > > already code in the system to look for services that have been running > a > > > long time without others doing things to them to let them be killed, > but > > > it's pretty clear we'll need to be even more brutal about this. :( > (Which > > > sucks for things that really do want to run for a long time, like a > media > > > player, but it's not clear at all to me what to do about them.) > > > > > Also, there was a suggestion earlier to try running the service in > another > > > process. Multiple processes is again something to be careful of, and > to > > > stay away from unless you really need them -- processes are quite > > > heavy-weight entities, so shouldn't be thrown around lightly. > > > > > On Sun, Nov 23, 2008 at 12:42 PM, G <ghack...@gmail.com> wrote: > > > > > > EUREKA! I've figured it out based on some of the documentation I > > > > missed. For those who also have trouble... > > > > > > The docs for ContextWrapper.startService(Intent service) includes the > > > > following line... > > > > "Using startService() overrides the default service lifetime that is > > > > managed by bindService(Intent, ServiceConnection, int): it requires > > > > the service to remain running until stopService(Intent) is called, > > > > regardless of whether any clients are connected to it." > > > > > > This is the trick, simply run startService() before you attempt to > > > > bind to it! So before, my onCreate contained: > > > > bindService(new Intent(MDService.class.getName()), > > > > mConnection, Context.BIND_AUTO_CREATE); > > > > > > Now this has been replaced by: > > > > Intent i = new Intent(MDService.class.getName()); > > > > startService(i); > > > > bindService(i, mConnection, Context.BIND_AUTO_CREATE); > > > > > > After that change, calling unbindService(mConnection) does NOT > destroy > > > > the service :) > > > > > > So starting a service by binding it from an activity links the > > > > service's life-cycle with that of the activity. While starting the > > > > Service first, gives it it's own lifecycle, and you can still bind to > > > > it right after. (And you still know the service will only actually be > > > > started once.) > > > > > > Also, doing this seems to have alleviated my 2nd problem that I > > > > described in my 1st post, but this requires a little more testing > > > > before i can confirm it. > > > > > > On Nov 23, 3:09 pm, G <ghack...@gmail.com> wrote: > > > > > I just realized that the in API Demo for Remote Service Binding, > the > > > > > service is destroyed when the activity is destroyed as well. So > it's > > > > > no help in this case. Can anyone point to a code sample in which a > > > > > service outlives it's binding in an activity? Do I need to use a > > > > > BroadcastReceiver or something? I'm very confused :( > > > > > > > On Nov 23, 2:46 pm, G <ghack...@gmail.com> wrote: > > > > > > > > That is what I've been trying to do, below is the service > definition > > > > > > in my AndroidManifest.xml file > > > > > > > > <service android:name=".MDService" android:process=":remote"> > > > > > > <intent-filter> > > > > > > <action > > > > android:name="com.episode6.android.carolla.MDService"></ > > > > > > action> > > > > > > </intent-filter> > > > > > > </service> > > > > > > > > And I bind the service in my activity with the following call... > > > > > > > > bindService(new Intent(MDService.class.getName()), mConnection, > > > > > > Context.BIND_AUTO_CREATE); > > > > > > > > And whenever I run unbindService(mConnection); the service still > gets > > > > > > destroyed. > > > > > > > > On Nov 23, 1:52 pm, Mark Murphy <mmur...@commonsware.com> wrote: > > > > > > > > > G wrote: > > > > > > > > 1) When my main activity is destroyed, my service is getting > > > > destroyed > > > > > > > > along with it. The service's onDestroy get's called, playback > > > > stops, > > > > > > > > the notification gets cleared. How can I avoid this? > > > > > > > > > Have you tried making your service a remote service, one that > runs in > > > > > > > its own process? > > > > > > > http://code.google.com/android/samples/ApiDemos/src/com/example/andro... > > > > > > > > > I haven't tried a remote service yet myself, so I'm not 100% > certain > > > > it > > > > > > > will resolve this problem. > > > > > > > > > -- > > > > > > > Mark Murphy (a Commons Guy)http://commonsware.com > > > > > > > > > Android Training on the Ranch! -- Mar 16-20, 2009 > > > >http://www.bignerdranch.com/schedule.shtml > > > > > -- > > > 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. 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. 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 -~----------~----~----~----~------~----~------~--~---
