Cannot thank you enough for this - exactly what we needed to know. Using the shell command we found out that our service hosting the playing mediaplayer was marked with an oom_adj of 2 - and would be killed after opening several other apps or extended phone idle.
After changing the service to a foreground service using setForeground (true), it was marked with an oom_adj of 0 or 1 - and stays alive! Thanks again, - John On Dec 11, 9:45 pm, "Dianne Hackborn" <hack...@android.com> wrote: > 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#set...) > > 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 -~----------~----~----~----~------~----~------~--~---
