Re: [android-developers] Long running Android service is getting recreated over and over
On Thu, May 10, 2012 at 1:25 AM, Johan Appelgren wrote: > Perhaps the Processes and Threads section in the Dev Guide could make it > more clear that it is up to each app to stop its background threads and > otherwise ensure they don't do anything when they're not in the foreground > then? Seems like a fairly common mistake that is difficult for most users > to understand, they just notice that their phone gets slower over time. > Using the CPU in the background will drain the battery, but unless you are explicitly doing something unusual it will not impact the foreground UI -- all threads in background processes are put into a global background scheduling group; all together all threads in that scheduling group can't use more than about 10% of the CPU. > Which is why, I guess, some games recommend that you force stop all cached > processes before playing. Not very user friendly. > That is very unlikely to be needed or useful. -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
10.05.2012 12:25, Johan Appelgren написал: Perhaps the Processes and Threads section in the Dev Guide could make it more clear that it is up to each app to stop its background threads Just to add some perspective: Every Android application has a bunch of Binder threads that are created by "the system", and stay around when the app goes into foreground or gets paused. They are not locked/suspended/prevented from running in some way, but, in absence of things to do, these threads just sit on a wait primitive, and do not consume the CPU or battery. The UI thread is the same way, its processing loop stays around ready for when/if the app is resumed or a service / receiver event. WebView also has a worker thread that stays around but is supposed to be doing nothing (which is actually not always the case, but that's a bug... very unfortunate, but a bug). So, just like "process being in memory" is not necessarily the same as "process consuming the CPU"... .. "a thread that exists within the app's process" is not necessarily the same as "a thread that's computing Pi to a million digit precision, loading all CPU cores as much as it can". and otherwise ensure they don't do anything when they're not in the foreground then? Seems like a fairly common mistake that is difficult for most users to understand, they just notice that their phone gets slower over time. Which is why, I guess, some games recommend that you force stop all cached processes before playing. Not very user friendly. It might have something to do with potential GC events in background processes, and these games trying to achieve very high frame rates, and having next to no spare cycles in their input/game/render loops. -- Kostya Vasilyev -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
On Thursday, May 10, 2012 1:30:02 AM UTC+2, Dianne Hackborn wrote: > > Yes well there is this meme spread by certain perhaps not unbiased > entities that having multitasking at all, I mean doing multitasking like > Android, is bad because it is intrinsically battery consuming. This is of > course not true -- if you create a process and it sits there doing nothing, > it ain't going to drain your battery. > > The difference between Android and some other platforms is that it does > give background code a lot more freedom to do what they want and run when > they want, so they have more freedom to do stuff that will drain your > battery. Android does have some safe-guards for this -- it looks for some > fairly clear signals like background processes using wake locks or CPU > excessively and kills them if this happens, and a UI to help the user > understand how applications are using their battery. It doesn't have such > rigid control where there are only X specific types of things that can be > done in the background. It's a different set of trade-offs, but background > processes being intrinsically more battery draining is not one of those > trade-offs. > Perhaps the Processes and Threads section in the Dev Guide could make it more clear that it is up to each app to stop its background threads and otherwise ensure they don't do anything when they're not in the foreground then? Seems like a fairly common mistake that is difficult for most users to understand, they just notice that their phone gets slower over time. Which is why, I guess, some games recommend that you force stop all cached processes before playing. Not very user friendly. -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
On Wed, May 9, 2012 at 4:02 PM, Kostya Vasilyev wrote: > I see your point about long running processes possibly fighting for RAM, > but restarting the process burns up the battery too (you'd previously given > a number of about 1 second to launch from Zygote to a running process... > maybe it's faster these days). > If the device isn't actively doing anything, service processes won't get killed. What happens is that after being in the started state after a certain amount of *uptime* (not including time the CPU is asleep) which I think is currently something like 30 minutes, the process drops into the background group. But it will still stay around until enough other processes have been put into the background for it to drop off the end of the list due to the out of memory killer. So if you have the power off and your device is relatively idle, these processes will get killed very infrequently, and lost in the noise... unless you do something like lots and lots of unneeded networking each time you are restarted. And if you are getting killed more frequently, then there is much more other stuff draining the battery, and again you should be mostly lost in the noise. As far as Zygote, our target for launching a new process and displaying a simple UI has always been about 200ms. We generally hit that (or do much better on faster devices), and most of that time is consumed with building and displaying the UI. Just launching a process is really fast -- it's just a fork() of zygote, bringing up the binder thread pool, attaching to the system process, and opening the app classes and instantiating and executing whatever is first being run in the process. Where launch is slow is if you aren't forking from Zygote. In that case we are talking about seconds usually. This is why commands like "adb shell am" are kind-of slow to run -- all of that delay is creating and initializing a fresh Dalvik process because "am" is written in Java. > There is, as far as I can tell, perception that just having a process > around somehow increases battery use, even if the device has plenty of free > RAM. > Yes well there is this meme spread by certain perhaps not unbiased entities that having multitasking at all, I mean doing multitasking like Android, is bad because it is intrinsically battery consuming. This is of course not true -- if you create a process and it sits there doing nothing, it ain't going to drain your battery. The difference between Android and some other platforms is that it does give background code a lot more freedom to do what they want and run when they want, so they have more freedom to do stuff that will drain your battery. Android does have some safe-guards for this -- it looks for some fairly clear signals like background processes using wake locks or CPU excessively and kills them if this happens, and a UI to help the user understand how applications are using their battery. It doesn't have such rigid control where there are only X specific types of things that can be done in the background. It's a different set of trade-offs, but background processes being intrinsically more battery draining is not one of those trade-offs. To some degree my answer to this claim would be, "well does the battery use UI show the app as actually draining the battery?". Ideally that would be the end of the story. In practice there are certain types of abusive behavior that we currently don't do a good job of measuring (such bringing up the cell radio often for very brief spurts of data) which it may miss. But it will catch a lot of common bad behavior. The perception is certainly helped by the multitude of various > system-info-management-optimizer apps, many of them being off the mark for > both memory and battery usage. > Yes these are frustrating. :p -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
if you keep a wake lock > and burn CPU time your users are going to basically hate your app. > For a change they could hate: - battery manufacturers for not making advance in battery technology. - WiFi chipset manufacturers for WiFi using so much battery when active (vs mobile which uses wy less) - themselves for sometimes having unrealistic expectations: wanting their phone to do all kind of crazy stuff and use 0 CPU and battery The day there is some real breakthrough in battery technology, today's devices will look really funny. -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
2012/5/10 Dianne Hackborn
> On Wed, May 9, 2012 at 2:48 PM, Kostya Vasilyev wrote:
>
>> Regarding this being an anti-pattern, I'm not sure I fully agree with the
>> widespread opinion on higher battery consumption.
>>
>
> The bigger issue is RAM use. There just isn't a lot of RAM available on
> many of these devices, and they can't afford to have tons of apps sitting
> around consuming it all of the time. We don't use paging so even if they
> are sitting there not doing anything their dirty pages can't be paged out.
>
I see your point about long running processes possibly fighting for RAM,
but restarting the process burns up the battery too (you'd previously given
a number of about 1 second to launch from Zygote to a running process...
maybe it's faster these days).
There is, as far as I can tell, perception that just having a process
around somehow increases battery use, even if the device has plenty of free
RAM.
This reasoning also ignores cached background processes.
The perception is certainly helped by the multitude of various
system-info-management-optimizer apps, many of them being off the mark for
both memory and battery usage.
So, Task Killers, Part 2: "The return of paranoia-instilling system tools".
See it in 3D at a theater near you.
:)
>
>
>> But it's the user's perception that matters here, and it's very much
>> against long running services, to the point where I'm sometimes asked why
>> there are three (!) services in my app, and wouldn't it be better to
>> use one to reduce memory usage by a factor of three, obviously (the answer
>> is no... since the services are sharing the same process).
>
>
> Wow... well hopefully that is from people seeing the older Running
> Services UI that made the separate services much more up-front, rather than
> the current one which is much more process-oriented.
>
The built-in settings UI on my GNex with 4.0.4 says something like
" Processes: 1, Services: 3".
Three is larger than one, so it wins the perception game ("What I tell you
three times is true"...)
:)
-- K
>
> --
> 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
>
--
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
Re: [android-developers] Long running Android service is getting recreated over and over
On Wed, May 9, 2012 at 2:48 PM, Kostya Vasilyev wrote: > Regarding this being an anti-pattern, I'm not sure I fully agree with the > widespread opinion on higher battery consumption. > The bigger issue is RAM use. There just isn't a lot of RAM available on many of these devices, and they can't afford to have tons of apps sitting around consuming it all of the time. We don't use paging so even if they are sitting there not doing anything their dirty pages can't be paged out. > But it's the user's perception that matters here, and it's very much > against long running services, to the point where I'm sometimes asked why > there are three (!) services in my app, and wouldn't it be better to > use one to reduce memory usage by a factor of three, obviously (the answer > is no... since the services are sharing the same process). Wow... well hopefully that is from people seeing the older Running Services UI that made the separate services much more up-front, rather than the current one which is much more process-oriented. -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
2012/5/10 Kristopher Micinski > On Wed, May 9, 2012 at 6:17 PM, Kostya Vasilyev > wrote: > > > > 10.05.2012 0:24, Kristopher Micinski написал: > > > >> consuming background memory and charging through the CPU > > > > > > Not quite the same things, are they? :) > > > > I didn't mean charging as in charging the phone, I meant charging as > in a bull... :-) > No, I got it. > > kris > > -- > 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 > -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
Though I agree it's perhaps contrived, I think there are many times when people keep persistent structures around, do processing in a light way, etc... when their apps should just die for a while. The typical perceived use case is when people have things that are polling some service at regular intervals (i.e., chat applications)... kris On Wed, May 9, 2012 at 6:22 PM, Kristopher Micinski wrote: > On Wed, May 9, 2012 at 6:17 PM, Kostya Vasilyev wrote: >> >> 10.05.2012 0:24, Kristopher Micinski написал: >> >>> consuming background memory and charging through the CPU >> >> >> Not quite the same things, are they? :) >> > > I didn't mean charging as in charging the phone, I meant charging as > in a bull... :-) > > kris -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
On Wed, May 9, 2012 at 6:17 PM, Kostya Vasilyev wrote: > > 10.05.2012 0:24, Kristopher Micinski написал: > >> consuming background memory and charging through the CPU > > > Not quite the same things, are they? :) > I didn't mean charging as in charging the phone, I meant charging as in a bull... :-) kris -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
10.05.2012 0:24, Kristopher Micinski написал: consuming background memory and charging through the CPU Not quite the same things, are they? :) -- Kostya Vasilyev -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
09.05.2012 23:17, William Kelley написал: So, if I want a long running process (logging GPS points over several hours), I would need to use START_STICKY and then maintain some knowledge of state between service restarts. If you wanted it to be invisible to, I don't know, 80% of the users (that number is a pure guess). The supported way to do this is to use startForeground, which: 1) Tells Android that your service is doing something important 2) Tells the user about it via a required status bar icon That is, save state to disk (filename that I am writing to, specifically). And since onDestroy is not called and there is no other warning that the service is about to end, I can't use any kind of buffered file writer because I can't guarantee that the buffer is written and I can't know to call flush. Am I understanding this correctly? With regards to buffering, I think yes. You will see the onCreate, then onStartCommand, possibly with null intent. Regarding this being an anti-pattern, I'm not sure I fully agree with the widespread opinion on higher battery consumption. But it's the user's perception that matters here, and it's very much against long running services, to the point where I'm sometimes asked why there are three (!) services in my app, and wouldn't it be better to use one to reduce memory usage by a factor of three, obviously (the answer is no... since the services are sharing the same process). And thanks Kostya for the info and very useful link. Thanks! -- Kostya Vasilyev -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
Because Android doesn't have many programs that should constantly be consuming background memory and charging through the CPU. The use case is things like phones, where you put it in your pocket, and you just want it to go away. Remember that you can't do computation continually if you don't have a wakelock, and if you keep a wake lock and burn CPU time your users are going to basically hate your app. If this is for development, that's one thing, but I can't really think of many services that should be eating up battery life continuously. Instead, people use an AlarmManager to occasionally wake up their app, do some work, then maybe go back to sleep (or run for a while). So, in short, no, the platform is different, this isn't the days of the unix daemon where you can just write an app and hope it will live forever, and very few apps have legitimate use cases for continually doing computation. We consistently see people who say "but my app is different it *really should* be running continuously," and all too frequently people come to a consensus that the app should not -- in reality -- be running forever. Instead, like I mentioned, look into an AlarmManager to wake up your app on occasion, do some work, and then perhaps schedule a little bit of time to run. We all know those apps you download that hold a wake lock forever, try to connect to a chat service, and then kill your device within three or four hours. kris On Wed, May 9, 2012 at 4:18 PM, William Kelley wrote: > Thanks. > > I'm not sure why long running services are frowned upon. As long as they > don't overly consume resources and are done with the user's knowledge, and > indeed the user *wants* the features of a long running service, then what is > the harm? If a user wants to log something for a long time, an everlasting > service is necessary. And if the user doesn't want this feature, they simply > don't use the app. > > > > On Wednesday, May 9, 2012 12:32:17 PM UTC-7, Kristopher Micinski wrote: >> >> Right. >> >> And in general everlasting services are an antipattern... >> >> kris >> > -- > 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 -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
Thanks. I'm not sure why long running services are frowned upon. As long as they don't overly consume resources and are done with the user's knowledge, and indeed the user *wants* the features of a long running service, then what is the harm? If a user wants to log something for a long time, an everlasting service is necessary. And if the user doesn't want this feature, they simply don't use the app. On Wednesday, May 9, 2012 12:32:17 PM UTC-7, Kristopher Micinski wrote: > > Right. > > And in general everlasting services are an antipattern... > > kris > > -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
Right. And in general everlasting services are an antipattern... kris On Wed, May 9, 2012 at 3:17 PM, William Kelley wrote: > So, if I want a long running process (logging GPS points over several > hours), I would need to use START_STICKY and then maintain some knowledge of > state between service restarts. That is, save state to disk (filename that I > am writing to, specifically). And since onDestroy is not called and there is > no other warning that the service is about to end, I can't use any kind of > buffered file writer because I can't guarantee that the buffer is written > and I can't know to call flush. > > Am I understanding this correctly? > > And thanks Kostya for the info and very useful link. > > Thanks! > > > > On Wednesday, May 9, 2012 11:35:15 AM UTC-7, Dianne Hackborn wrote: >> >> That is the expected behavior. The longer your service runs, the more >> likely it is to be killed (and then restarted if you asked for it to be >> sticky). >> >> -- >> 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 -- 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
Re: [android-developers] Long running Android service is getting recreated over and over
So, if I want a long running process (logging GPS points over several hours), I would need to use START_STICKY and then maintain some knowledge of state between service restarts. That is, save state to disk (filename that I am writing to, specifically). And since onDestroy is not called and there is no other warning that the service is about to end, I can't use any kind of buffered file writer because I can't guarantee that the buffer is written and I can't know to call flush. Am I understanding this correctly? And thanks Kostya for the info and very useful link. Thanks! On Wednesday, May 9, 2012 11:35:15 AM UTC-7, Dianne Hackborn wrote: > > That is the expected behavior. The longer your service runs, the more > likely it is to be killed (and then restarted if you asked for it to be > sticky). > > -- > 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
Re: [android-developers] Long running Android service is getting recreated over and over
That is the expected behavior. The longer your service runs, the more likely it is to be killed (and then restarted if you asked for it to be sticky). On Wed, May 9, 2012 at 3:13 AM, William Kelley wrote: > I have a simple Android Activity with one button to start and stop a long > running Android Service (which does some simple logging). As soon as I > start the service, I close the app (Activity) and the service should then > run in the background indefinitely. > > But it doesn't. At random times, the Application object this Service > belongs to is recreated by the OS and then my Service is as well. So it's > not just that the Service is getting onStartCommand called, but first it > gets onCreate called, creating a new Service. I don't know what happens to > the old one, it just goes away - onDestroy is not called or anything. > > I run the Service as START_STICKY, I am not using the main UI thread in > any way, so there should be no issues there. I am Logging all activity from > the Service, logging exceptions, etc. Nothing is out of the ordinary except > that my Service is getting recreated over and over. I just can't understand > what the problem is. > > The Service is running fine, then boom, my Application gets an onCreate, > my Service gets an onCreate and onStartCommand and the old Service, which > was in the middle of logging goes, away without any notice or warning. The > new Service starts logging. I end up with a bunch of disconnected logs > where there should be just one. > > -- > 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
Re: [android-developers] Long running Android service is getting recreated over and over
The process gets killed and then gets recreated (typically 5 seconds later) because of START_STICKY. onDestroy does not get called, along with any other callbacks, the process just goes away. There is no duplicate instance of Service object. This might help: http://android-developers.blogspot.com/2010/02/service-api-changes-starting-with.html And speaknig more broadly, "eternal services" is something that really scares some users, the ones that use various system monitoring tools more than all other apps combined, but they'll be the ones leaving one star comments in Market. -- K 2012/5/9 William Kelley > I have a simple Android Activity with one button to start and stop a long > running Android Service (which does some simple logging). As soon as I > start the service, I close the app (Activity) and the service should then > run in the background indefinitely. > > But it doesn't. At random times, the Application object this Service > belongs to is recreated by the OS and then my Service is as well. So it's > not just that the Service is getting onStartCommand called, but first it > gets onCreate called, creating a new Service. I don't know what happens to > the old one, it just goes away - onDestroy is not called or anything. > > I run the Service as START_STICKY, I am not using the main UI thread in > any way, so there should be no issues there. I am Logging all activity from > the Service, logging exceptions, etc. Nothing is out of the ordinary except > that my Service is getting recreated over and over. I just can't understand > what the problem is. > > The Service is running fine, then boom, my Application gets an onCreate, > my Service gets an onCreate and onStartCommand and the old Service, which > was in the middle of logging goes, away without any notice or warning. The > new Service starts logging. I end up with a bunch of disconnected logs > where there should be just one. > > -- > 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 -- 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
