satya - Wednesday, May 19, 2010 10:19:58 PM

services and the main thread

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.

satya - Wednesday, May 19, 2010 10:27:51 PM

basic docs for a service

satya - Wednesday, May 19, 2010 10:32:12 PM

Processes and threads

When the first of an application's components needs to be run, Android starts a Linux process for it with a single thread of execution. By default, all components of the application run in that process and thread. However, you can arrange for components to run in other processes, and you can spawn additional threads for any process.

satya - Wednesday, May 19, 2010 10:43:20 PM

There is only one main thread of execution per process

Compare this to a website that serves web pages or does some work for you as a service. Each of those activities in a website gets its own thread with in that webserver.

However in android all calls to its components are queued as messages and delivered one by one.

So it is an event based model where commands are queued and the main thread cycles through them. This seem to be true whether the package contains activities or services or broadcast receivers.

satya - Wednesday, May 19, 2010 10:52:45 PM

I spoke too soon, here are exceptions

In a few contexts, the methods you implement may be called from more than one thread, and therefore must be written to be thread-safe.

This is primarily true for methods that can be called remotely ? as in the RPC mechanism discussed in the previous section. When a call on a method implemented in an IBinder object originates in the same process as the IBinder, the method is executed in the caller's thread. However, when the call originates in another process, the method is executed in a thread chosen from a pool of threads that Android maintains in the same process as the IBinder; it's not executed in the main thread of the process. For example, whereas a service's onBind() method would be called from the main thread of the service's process, methods implemented in the object that onBind() returns (for example, a Stub subclass that implements RPC methods) would be called from threads in the pool. Since services can have more than one client, more than one pool thread can engage the same IBinder method at the same time. IBinder methods must, therefore, be implemented to be thread-safe.

Similarly, a content provider can receive data requests that originate in other processes. Although the ContentResolver and ContentProvider classes hide the details of how the interprocess communication is managed, ContentProvider methods that respond to those requests ? the methods query(), insert(), delete(), update(), and getType() ? are called from a pool of threads in the content provider's process, not the main thread of the process. Since these methods may be called from any number of threads at the same time, they too must be implemented to be thread-safe.