1

I have some confusion with android service As per the documentation It will keep on running in the background on main thread . It doesn't run in a different thread.

My doubt is what is the meaning of keep on running in background . Will it execute the onStartCommand() again and again. I am really very confused with this line (Keep on running in background )

if it will not execute onStartCommand again and again then what is the benefit of Keep on running and if it executes onStartCommand again and again then it is using cpu more and more

Line which confused me is highlighted in the image please have a look enter image description here

Community
  • 1
  • 1
Naga
  • 1,931
  • 4
  • 25
  • 42
  • How did you conclude from the documentation that a "service will keep on running in the background on the man/UI thread"? That's simply not the case. – class stacker Feb 01 '13 at 11:10
  • I have developed an app in which I have implemented a service and that service was always running . Which is easily visible from running services option on phone – Naga Feb 01 '13 at 11:15
  • I have edited the question and added one image please have a look on highlighted line in the image – Naga Feb 01 '13 at 11:26
  • And you can see that your service runs as the main UI thread of your app? I highly doubt this. -- Either way, no, it's not going to run ?onStartCommand()` again and again, because it's not started again and again. But it's still a waste of resources if you implement a `Service` when an `IntentService` would be sufficient. – class stacker Feb 01 '13 at 11:28
  • Yes exactly we can use IntentService which will do the job at different thread and once its job is finished then it will die right ? ...cool but then what is use of service and where to use it – Naga Feb 01 '13 at 11:32
  • You seem to think that a service has to run on the UI thread of your app. Again, this is, of course, _not true_. But yes, IntentServices are a nice feature and they are based on worker threads which need not be explicitly created. – class stacker Feb 01 '13 at 11:53
  • I am sorry if I meant that but to be very clear I just want to know how I can utilize the service which is running ..Because it will always start when someone will call startservice() method in that case if service not running then it will get started so if service is running already then what is benefit for us – Naga Feb 01 '13 at 13:17
  • I'm not sure I understand your question. I can't tell you what your benefit of a Service as compared to an IntentService is because I don't know your scenario. If you want help with a design decision, please describe your requirements. – class stacker Feb 01 '13 at 13:22
  • Thanks for such a kind help. Suppose a user sets ringer volume to maximum so I want to detect whenever he is setting ringer volume at maximum mode then I can launch some code ..So I was thinking can I achieve this using service because we don't have any broadcast receiver for this event – Naga Feb 01 '13 at 13:33
  • 1
    I hope you'll _never_ publish an app which runs a task all the time and waste energy and cpu cycles to _poll_ for an event. Nobody will like your app anyways. Do it event driven! Of course there's a way. You want to read http://stackoverflow.com/questions/6896746/android-is-there-a-broadcast-action-for-volume-changes – class stacker Feb 01 '13 at 14:00
  • Ypu can actually mark my comment as helpful ;) – class stacker Feb 03 '13 at 09:22
  • 1
    If you found my comments and/or answer helpful, please mark them accordingly. I like to support people but I also like to be rewarded for it. Thank you. – class stacker Feb 05 '13 at 07:54

2 Answers2

1

As already noted in a comment, for your particular purpose (monitoring a setting, here: volume), you can follow a non-polling approach which is described e.g. here: Is there a broadcast action for volume changes?

In general, on a modern (though not perfect) environment like Android, there's almost never a reason to actively poll something, because nobody could afford wasting so much resources, and also, you'll always risk to miss events, so you'd be tempted to poll more frequently -- this is a race which your implementation is always going to lose.

Once more, the following statements are plain wrong:

  • A Service runs on your app's main/UI thread. If you think this is the case then you need to read about the android:process attribute of the manifest's activity tag. Also. even if you do not let your service run in a separate process, the phrase a service runs on your app's main/UI thread suggests that your main/UI thread gets blocked by your service. Of course, hopefully nobody leaves iot art that; it's easy to just process the service's events on your app's main/UI thread and delegate the tasks to worker threads, which is what every sane implementation should do.

  • With START_STICKY, you can ensure that your service will always be running after it got started. Of course, this is naive and means that whoever claims this has not completely understood the meaning of this flag in conjunction with the description of the process lifecylce for Android Services. Quote: Note this means that most of the time your service is running, it may be killed by the system if it is under heavy memory pressure. If you read the section, you will know that Android is going to kill the process with your running service at any time without notice if it needs memory for another task with higher priority and your service is not related to an app which the user currently looks at. In other words, if the system is low on memory and the user opens a spreadsheet which requires most of the system's memory, then the background internet radio media player and all fancy stuff is likely to get killed, period.

Community
  • 1
  • 1
class stacker
  • 5,357
  • 2
  • 32
  • 65
0

A Service runs on the thread of your app and after started it keeps running until it calls finish() or android needs memory.

But the running doesn't necessary means that it is processing something. onStartCommand() is called only when someone calls startService() on your service.

So the service instead of running always it's always in memory ready to be run when needed. The main use of service is to do some processing that keeps running even if you change activities, like a music player that keeps playing when you are changing activity looking for the next music to play.

Edit: On Documentation "A Service is not a separate process....A Service is not a thread. It is not a means itself to do work off of the main thread". A Service is "A facility for the application to tell the system about something it wants to be doing in the background"

"A service can be both started and have connections bound to it. In such a case, the system will keep the service running as long as either it is started or there are one or more connections to it with the Context.BIND_AUTO_CREATE flag. Once neither of these situations hold, the service's onDestroy() method is called and the service is effectively terminated."

Service Documentation

Marcio Covre
  • 4,556
  • 2
  • 22
  • 24
  • I think there are several aspects in your answer which aren't accurate enough for an answer to a newbie, really. First, what do you mean by _thread of your app_? Second, a service is not always present in memory, not even after it has been started once. Third, for processing things while you _change activities_, you don't need a service. – class stacker Feb 01 '13 at 11:47
  • By thread of the app I mean that the service running in background doesn't mean that it's on another thread or process. About the memory, if you return START_STICKY on onStartCommand() it will be on until someone kills it. And I know that you can use AsyncTasks and Loaders now, but in old versions of android you only have services to do that and the most common example of service usage was playing music. – Marcio Covre Feb 01 '13 at 12:16
  • I think you need to get your facts straight. All of your three points are wrong. – class stacker Feb 01 '13 at 12:22
  • Ahh this discussion is going somewhere else ..Okay as per documentation START_STICKY is used to run service continuously.So what we can achieve if service is running continuously . – Naga Feb 01 '13 at 13:20
  • One example I used for running a service continuously is that android has some Broadcasts that only works when registering it in code and not the Manifest, in this case I started a service that registered for this broadcast and will be running continuously, waiting for a broadcast. – Marcio Covre Feb 01 '13 at 16:38
  • @Nagendra Sorry to have to say this, but it's yet another bad suggestion; the fact that receivers for some Broadcasts can only be registered in code is _not_ a justification for implementing a continuously running Service. Of course, you can register an IntentService in this way as well. – class stacker Feb 05 '13 at 08:01
  • @Class Stacker Yes I am completely agree with you We can register an intent service as well and it will be a wise choice – Naga Feb 05 '13 at 08:51
  • @Class Stacker: I know it's not ideal to use a service for this. I need to receive the broadcast Intent.ACTION_HEADSET_PLUG, to know when the user connects the headset and start my music player (user enabled option on app). So I receive the broadcast to BOOT_COMPLETED and start a service that register the broadcast on onCreate() and unregister on onDestroy(). What would be a better way to do this? – Marcio Covre Feb 05 '13 at 11:33
  • @nininho Well, start an IntentService for it; what would be the problem with that? – class stacker Feb 05 '13 at 12:13
  • @Class Stacker: When the Service or IntentService ends the BroadcastReceiver is not valid anymore. And I want to receive the Broadcast from headset all the time. – Marcio Covre Feb 05 '13 at 13:19
  • @nininho Technically, okay. So you want to start a media player as soon as headphones are being plugged in, without the user having started the player? – class stacker Feb 05 '13 at 13:58
  • @Class Stacker: Yes. I know you could say to not do this, but this is a user choice to open the player when plugging the headset. Like this app does but specific to my player (https://play.google.com/store/apps/details?id=com.sonyericsson.extras.liveware) – Marcio Covre Feb 05 '13 at 16:04
  • @nininho Okay, +1. I'd have said that one could have the media player app as a context, but of course not if it's to be started. It's a use case where the Android design does not necessarily want something to be started upon this event I guess. Although, given that the documentation is wrong, maybe that's not even the case that this has been a design decision. – class stacker Feb 06 '13 at 12:22