What are the practical differences between putting a service in a separate process or keeping it in the app's main process? What would each scenario be used for?
When a service is running in the main process it will be stopped in case your application crashes for whatever reason. Put a service into it's own process is reasonable for some services which can be used from different applications or services which should run independently from your main app.
The only reasons I see for putting a service in another process is
The application is resource heavy and likely going to be killed quickly by the OS. Putting the service in a separate process will distribute the resources and if you application dies your service won't.
JUST in case your application has errors and dies your service will keep going.
However if you create a good application and use good programming you should not run into either of these issues. By having your service in a separate process it causes trouble with things like SharedPreferences and concurrent DB access... I would recommend not doing it.
Not to mention... another process means another DVM. This will take more resources than running in one DVM and slow things down.
Also putting service in another process makes your changes of static variables invisible for main process. You can get situation, when you assign a variable with some value, and it is not changed!! I spent whole day for this issue!
Following is a quote from Android Developer's web site.
Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work.
Jake points out that you can, thru manifest, control the Name of the process it is running. But following findings from Documentatioin:
Most confusion about the Service class actually revolves around what it is not:
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
This is interesting, what is said Here is:
The name of the process where the service is to run. Normally, all components of an application run in the default process created for the application. It has the same name as the application package. The element's process attribute can set a different default for all components. But component can override the default with its own process attribute, allowing you to spread your application across multiple processes.
But anyway, if you need Service to be exposed to other applications, for example, you need to provide content (like phonebook) to other applications, setting service to run in different process is the reason.
Using the process attribute of a service is rejected by the manifest parser so it is rather misleading!
Related
I have a Service running in the same process as my Application.
Sometimes the Android OS decides to kill my service (probably due to low memory).
My question is: does my Application get killed along with the Service? or how does it work exactly?
Thanks!
First be sure to read: http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle
The key to this is that on Android a process is just a container for code -- or specifically one or more components (activities, services, receivers, providers). By default all components in a .apk get their own, dedicated process, that they all run in together. This is almost always what you want.
When the user is directly interacting with a component of that process (that is an activity) Android will try very hard to keep that process running, and you won't see it killed except under extraordinary circumstances.
When the user is no longer directly interacting with the process, then it becomes expendable relative to other processes as described in the referenced documentation. That is, empty processes (no interesting components) will be killed before processes holding activities that the user had been using, which will be killed before processes with running services. So having a running service will tend to keep your process around at the expense of other processes.
At the same time, we need to deal well with more and more applications leaving services running, often indefinitely, and often with memory leaks. So has a service runs for an increasingly long time, Android will try less and less hard to keep its process going. Effectively this means moving it down to the background bucket until the out of memory killer takes it out. After that, if the service still wants to run, then a new process will be created for it to be restarted in.
The upshot is that for normal services that are running a long time, it is expected behavior that their process will get killed after a while. This doesn't need to stop the service; a service that wants to continue running will do so, it will just need to be instantiated in a new process.
Of course as long as the user is interacting with an activity in your process, the process won't be killed, since this pulls it to the foreground category regardless of what is going on with any services in it.
Processes are killed by the low memory killer, not Applications. So unless you do extra work to get your Service running in a different process, then your Activities are killed along with your Service.
The low memory killer doesn't try to destroy any objects in your process, although the activity manager may call onDestroy on Activity objects that are no longer needed. But that happens as part of the regular activity lifecycle, not due to low memory conditions.
(By the way, I'm unclear whether you mean "application" in general, or your object that extends Application, or whether you mean your Activities that show the UI.)
An application is something that has a user interface and if you have included a service along with it, then definitely it will be killed since Applications are terminated once the cached application queue becomes full
so create Service separate from application or in other words create an other project for it :)
btw, i'm not an experienced Android developer but thats i think what i learned by watching the Android development life cycle videos by Google
I want to know what is the difference between a process and a service in an android app?
I tried to study about this topic a lot, but did not clear my basics yet...please help?
A process and a service are two different things:
What is a Service?
Most confusion about the Service class actually revolves around what it is not:
A Service is not a separate process. The Service object itself does not imply it is running in its own process; unless otherwise specified, it runs in the same process as the application it is part of.
A Service is not a thread. It is not a means itself to do work off of the main thread (to avoid Application Not Responding errors).
Thus a Service itself is actually very simple, providing two main features:
A facility for the application to tell the system about something it wants to be doing in the background (even when the user is not directly interacting with the application). This corresponds to calls to Context.startService(), which ask the system to schedule work for the service, to be run until the service or someone else explicitly stop it.
A facility for an application to expose some of its functionality to other applications. This corresponds to calls to Context.bindService(), which allows a long-standing connection to be made to the service in order to interact with it.
source: http://developer.android.com/reference/android/app/Service.html
What is a Process
When an application component starts and the application does not have any other components running, the Android system starts a new Linux process for the application with a single thread of execution. By default, all components of the same application run in the same process and thread (called the "main" thread). If an application component starts and there already exists a process for that application (because another component from the application exists), then the component is started within that process and uses the same thread of execution. However, you can arrange for different components in your application to run in separate processes, and you can create additional threads for any process.
source: http://developer.android.com/guide/components/processes-and-threads.html#Processes
When an android application starts a service, does it runt in a different process or same process? I think it is run in the same process as the android application. Is that correct?
But from the O'Reilly Efficient Android Threading book , page 9, it said
"The Activity offloads work to a Service that runs in process P2, which starts the
Service and the associated Application instance. Therefore, the application has split
the work into two different processes. The P1 Activity can terminate while the P2
Service keeps running."
I just dont' understand how can 'the application has split
the work into two different processes'?
I think it is run in the same process as the android application. Is that correct?
By default, yes.
I just dont' understand how can 'the application has split the work into two different processes'?
Well, I don't have that book, so I cannot state specifically what they are referring to.
However, it is entirely possible to have an android:process attribute in a <service> to indicate that the service should run in another process. This usually is not necessary.
I'm fairly certain that it's standard practice to handle asynchronous file downloads using a Service and AsyncTask. That way, you can kill the originating activity and go on your merry way. However, when you don't need the lifecycle management, remote process communication, or other major features of a Service, it seems a bit overkill.
Since a Service is still a part of the same process and lifecycle of the overall Application, why not simply run a background thread within the context of the Application (vs Activity, although not necessarily within the extended Application class)? Is there any reason why this would be a particularly bad idea?
I'm fairly certain that it's standard practice to handle asynchronous file downloads using a Service and AsyncTask.
An AsyncTask is useless in a Service, as you have no reason to do anything on the main application thread in a Service. Use an IntentService for downloads, as it gives you a background thread, plus automatically stops itself when there is no more work to be done.
why not simply run a background thread within the context of the Application... Is there any reason why this would be a particularly bad idea?
Because your app will be unreliable.
While a lot of people focus on the independent lifecycle of the service, that's not why you use a service for something like this. You use a service as a flag to the OS that your process is still doing something.
Once you are no longer in the foreground, Android can terminate your process, at will, at any moment. Particularly if there is a lot of memory pressure, this can be within milliseconds of your app leaving the foreground.
However, Android generally prioritizes terminating empty processes (ones with no running activities or services) and activity-only processes, ahead of processes that contain a running service. Here, "generally" means that processes with services will not live forever, but they are far less likely to be terminated quickly.
Hence, using an IntentService is signalling to the OS that you are still delivering value to the user (downloading the file) and that it should leave your process alone, until either your IntentService stops (because the download completed) or your service runs so long that it's probably lost its virtual marbles.
An Application is not a Service. Every process has an Application instance. Having a download be "managed" by an Application is pointless -- you may as well run a bare thread outside of any Context. And, most importantly, nothing tells the OS that you are doing anything meaningful, and so your process can be terminated as soon as you leave the foreground.
However, when you don't need the lifecycle management, remote process communication, or other major features of a Service, it seems a bit overkill.
Writing an IntentService, outside of the manifest entry, is not significantly more complicated than writing an AsyncTask. Invoking an IntentService is not significantly more complicated than invoking an AsyncTask.
I am confused with android services and java thread.
Please help me to understand in which scenario i should use them.
As per my understanding
Service run in background ,so do thread.
Service is to be used for activities like network operation or playing mp3 in background,so do threads.
So whats actual difference between them and when to use each of them.
Let me give an analogy.
Activities and Service are like projects.
Activities are like external projects. This is what the clients(users) see.
Services are like internal projects. There might be several internal projects for 1 external project or none at all.
You can "pause" external project but the internal project that supports it can still continue.
Main Thread is like the boss in a company
The boss should never be held up by too much work since he shouldn't be late to meetings (UI freezing) or the client(user) will be unhappy.
Threads are like employees in a company.
The more you have, the more things you can do at the same time provided you have enough equipment(CPU speed) for all of them.
Multiple employees can work on the same project at the same time but the boss should really work only on the Activities.
Always: A service of your application is usable not only by other components of your application, but by other applications, too.
A service is for use in not-GUI parts of program.
Mostly: A service is something more independent, than a thread. Service is something more long-living than a thread. Service is something more complex than a thread.
BTW, threads do not run in background only. What runs in foreground, is a thread, too.
I believe the main difference is about Android system attitude. Service is a part of android infrastructure, so android recognizes service as a working part of application and considers killing service as a last option. Moreover, if your service is killed (e.g. because of memory lack) you can say system to restart it automatically, whenever resources available again. Moreover, you can tune up service priority in order to do it as important as foreground activity. As for threads, android does not recognize a thread as important part which must be kept. So usual threads has much more chances to be killed eventually.
For instance If you have an activity which start a working thread and then go background, as android do not recognize thread as a working part, it may think that application do nothing, because no activity or service running and kill the whole app, including the working thread.
Thus when you start a Service, you are telling system something like: "Hi. I'm doing some business here, don't kill me until I finish, please." and Android pay attention to your request.
Services are more analogous to a headless Activity.
The the important piece to understand is that a Service is about managing application lifetime and the ability to keep work running when your Application is not in the foreground (no UI visible). It is also about providing the ability to expose functionality to other apps.
http://developer.android.com/reference/android/app/Service.html#WhatIsAService
Typically when starting a Service you will also start a worker Thread. There are settings in the manifest that can cause a Service to be started in a new Process but generally you do not need to do this, it makes communication with your service more difficult.
Use a just Thread in your Activity when you need to offload work from the UI thread while the application is in the foreground, but this work can stop when you are no longer in the foreground. (It is possible that your app will continue to run when not it foreground but there is no guarantee depending on a number of factors) Generally speaking Android is free to kill your Activity if it is not in the foreground, and if your App process has no Activities or Services it can be killed.
Use a Service with a Thread to do work that will take place while your app is in the background and you want better guarantee about the lifetime.
Use a Service to expose non-UI functionality to other applications.
Android Service don't run in a separate process (by default) and even don't run in a separate thread! It runs in the main thread(UI thread) of the application, therefore if you would like to do something time consuming task in the Service start a separate thread yourself, or use IntentService.
As per Android Developer Guide (http://developer.android.com/guide/components/services.html#Basics) :
A service is simply a component that can run in the background even when the user is not interacting with your application. Thus, you should create a service only if that is what you need.
If you need to perform work outside your main thread, but only while the user is interacting with your application, then you should probably instead create a new thread and not a service. For example, if you want to play some music, but only while your activity is running, you might create a thread in onCreate(), start running it in onStart(), then stop it in onStop(). Also consider using AsyncTask or HandlerThread, instead of the traditional Thread class. See the Processes and Threading document for more information about threads.
Remember that if you do use a service, it still runs in your application's main thread by default, so you should still create a new thread within the service if it performs intensive or blocking operations.
Why we need service is to avoid resource crunch.
For example you opening an application after opening an another application so at the time your app added to the background task.
While opening multiple application, ur app may killed by android system. So if ur app has service it won't be killed by the system because service is higher priority , even it may killed the app has service so that we using constant return type in onStartCommand(). Method. That's START_STICKY,START_NOT_STICKY and DELIVER_INTENT.