It is very likely that the other services are also being killed and restarted. If you look at the uptime in Running Services, this is the time since the service was *originally* started. That is, how long it has been *wanting* to run without break. If it gets killed and restarted by the system, that time doesn't break.
In fact in the current implementation, after a service has been running continually for around 1/2 hour, it gets dropped down into the background process LRU list to make sure it eventually gets killed and restarted. We don't want services sitting there running for days with memory leaks and eventually eating away all of the RAM that we'd like to use for caching background processes. :) On Tue, Jul 26, 2011 at 1:18 PM, Indicator Veritatis <mej1...@yahoo.com>wrote: > Your advice is certainly sound, but I can sympathize with the OP's > "Service envy", thinking that his Service should also be able to > persist for days like certain others. > > Then again, since he is talking about taking up as much as 10MB, he > should not be surprised that his gets killed more often than the > others. Any service that is going to persist for so long has to be > MUCH more lightweight than that, unless it is a system service. > > BTW: there has got to be a better way to do this than wait forever for > incoming TCP PDUS: somebody in this group once mentioned WebTCP, > though it was never clear to me how that solves the problem. > > On Jul 26, 8:39 am, TreKing <treking...@gmail.com> wrote: > > On Fri, Jul 22, 2011 at 10:03 PM, scmailon <scmai...@gmail.com> wrote: > > > Any idea suggestion is very wellcome :) > > > > Don't attempt to keep you service alive indefinitely - it can and will be > > killed when necessary. Instead, code it to take this reality into > account. > > > > > ------------------------------------------------------------------------------------------------- > > TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago > > transit tracking app for Android-powered devices > > -- > 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 > -- 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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
