Does Android Service run from a separated thread instead of UI?

Question

I am currently using a alarmmanager to start a service for posting of location to http. The problem is when the manager starts and run the services, the ui seems to stop for

Answer 1

Copied From Android Docs :

Caution: A service runs in the main thread of its hosting process—the service does not create its own thread and does not run in a separate process (unless you specify otherwise). This means that, if your service is going to do any CPU intensive work or blocking operations (such as MP3 playback or networking), you should create a new thread within the service to do that work. By using a separate thread, you will reduce the risk of Application Not Responding (ANR) errors and the application's main thread can remain dedicated to user interaction with your activities.

Services overview

Use IntentService if you don't want to fiddle with managing threads on your own. Or use AsyncTasks.

Answer 2

To clarify: The application's main thread is not always the UI thread. For example: If an activity is stopped, the onStop() is invoked, hence the UI thread is taken away from that activity and moved to another activity within the same or a different application.

However, it doesn't mean that this application is no longer active. Furthermore, if there is a (started) service running in the background, it may continue for a while, until it terminates or the Android OS terminates it due to lack of resources.

Who runs this service during that time? Who triggers the onStop() or the onDestroy()? It's the application's main thread doing that.

The UI thread is a kind of Singleton. It can be used by only one visible activity at a time. Either the application's main thread is joined/attached to the UI thread or another one gets it. However this does not mean, that the application doesn't have a main thread of its own.

This behavior comes from the Linux\Unix foundation of the Android System. What most developers are not aware of: The application is a "user" within the Linux\Unix OS.

Whenever an application is invoked, it is similar to a user logging into the system. In the application's case, the user id is the unique application id, while no password is required. The new logged in "user" (i.e. Android application) gets a process and resources such as an instance of the Java Virtual Machine. The process is dedicated to this user and the resources including file system quota, file descriptors and handlers allow it to communicate with the OS.

The android application's main thread is the root thread that is created from the process the Android OS hands over to that application. Any new threads created in this application will always return to the main thread.

One of system resources that the application's main thread can gain access to, is the UI thread. Hence the application can request the main thread, however the request may be refused (or granted). An example: In case the application process exceeds it's allowed memory allocation size, the Android OS may decide to refuse access to the UI thread and even destroy the application and terminate the process.

It is possible to define more than on process for an application (Unix process fork) via definition in the AndroidManifest.xml. However, bear in mind, that the resources assigned to each process will be different, i.e. each process will have its own VM, hence objects maintained in the different processes will not be able to share information via the same JVM heap.

Answer 3

From android developer:

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. When a Service component is actually created, for either of these reasons, all that the system actually does is instantiate the component and call its onCreate() and any other appropriate callbacks on the main thread. It is up to the Service to implement these with the appropriate behavior, such as creating a secondary thread in which it does its work.

Note that because Service itself is so simple, you can make your interaction with it as simple or complicated as you want: from treating it as a local Java object that you make direct method calls on (as illustrated by Local Service Sample), to providing a full remoteable interface using AIDL.