Develop Reference

do we have to interrupt the background thread in ondestroy method?

I am running a background thread that runs all through out the life cycle of application. Do we need to interrupt this thread in onDestroy method? or is it handled by android system? If we don't interrupt manually, will it lead to memory leaks?

It's a good practice to finish your pending tasks when the activity is gone, since basically whatever the thread does will not have impact for the user as it won't modify the UI.
Regarding memory leaks, android apps run in a linux process, so the context of the threads is the application, not the activity, that is why, when an activity is gone, your thread will keep running and you may update a death object. It's a good practice to stop it to avoid a memory leak because you keep a reference to what you want to update (of course, unless you use a WeakReference).

How long do Android worker threads last?

I have seen some postings on this subject, but none of them have satisfactory answers.
Assume that I start a worker thread from my main (one-and-only) Activity, in its onCreate() method. Then I call finish() to cause the Activity to terminate.
At that point, the task it belongs to gets destroyed (since there are no longer any Activity in it). The app (and the process running it) may continue to exist, however, in empty "skeleton" form, so that it can be restarted quickly if desired (although it would be highly susceptible to being killed by the system).
Assuming the above is correct -- when is the worker thread killed? Is it only killed when the system actively destroys the process?
In my case, my worker thread exists as a listener for a Bluetooth connection; when received, it will fire up the desired Activity again. In this situation there is no actively running component (Activity, Service, ContentProvider or BroadcastReceiver). It seems to me that this should work, except that something is killing my worker thread.
I am aware that I could do this (and with less pain) by using a background Service. However, I'm curious about why this isn't working.
Thanks,
Barry

when is the worker thread killed? Is it only killed when the system actively destroys the process?
-> the worker thread is skilled after all its code in run function executed. It still run even when your activity is destroyed.
In my case, my worker thread exists as a listener for a Bluetooth connection; when received, it will fire up the desired Activity again. In this situation there is no actively running component (Activity, Service, ContentProvider or BroadcastReceiver). It seems to me that this should work, except that something is killing my worker thread.
To make it works, You need to have a background service in this case and make a soft/weak reference to your service from your worker thread or more simple, using EventBus to start any component from your Service as:
EventBus.getDefault().post(new BlueToothEvent()); // call in your worker thread
// do something in your service
onBlueToothEventFired(BlueToothEvent e);

Android App lifecycle has a nice example that is very on topic:
A common example of a process life-cycle bug is a BroadcastReceiver
that starts a thread when it receives an Intent in its
BroadcastReceiver.onReceive() method, and then returns from the
function. Once it returns, the system considers the BroadcastReceiver
to be no longer active, and thus, its hosting process no longer needed
(unless other application components are active in it). So, the system
may kill the process at any time to reclaim memory, and in doing so,
it terminates the spawned thread running in the process.
In short, its really not very predictable if you thread would get a chance to run until termination or process will be killed beforehand, you should NOT definitely rely on any order/behavior.
Worth mentioning separately that its fairly easy to leak your activity along with thread even if you finish() it, but if its your last/only activity it does not change the picture

When you start a thread, it is independent of the parent that started it. In your case, it is your application activity. This means that until the Run method has been fully executed, your thread will live.
If you exit the application (and therefore call the activity's onStop method), the thread will still exist, and you will cause a memory leak. It will eventually get killed by the system if you run out of memory.
Since you mentioned that you created a listener to listen for a Bluetooth connection, your thread probably dies before it receives any event (It is impossible for me to know without any code snippet). It might also crash which would be ending the thread.

There is one main (also called UI) thread in Android. That is the only thread your app uses, unless it starts one explicitly via Thread.start(), AsyncTask.execute() etc. All Activities, Services, BroadcastReceivers, etc run all of their lifecycle methods on that main thread. Notice I included Services- a Service runs on the main thread unless it starts its own Thread (the exception to that is an IntentService, which does run on its own Thread).
A Thread you create continues until the Runnable its passed returns from its run function (or of course the process is terminated). This can live past the end of the Activity/Service it was created by. However such a Thread would still live in the original instance of the component, and would not be able to access variables of a new instance if one was restarted without a lot of special work (see Loader pattern).

understanding Android Services and threads

I have doubts when it comes to Services.
I know the service runs in the background, but I thought you necessarily needed to create a thread within the service, otherwise it would block the main thread and you would get an ANR error.
I thought I got it! But then I read this in the Android Developer guide:
…if your service performs intensive or blocking operations while the user interacts with an activity from the same application, the service will slow down activity performance. To avoid impacting application performance, you should start a new thread inside the service.>
The paragraph mentions "intensive or blocking operations", but doesn’t mention an ANR error, it mentions performance. So how a service works?
Supposing an Activity starts a Service. Does the Service run by default in the background of the main thread? Meaning that you can still use your activity while the service is running, but since your Activity and the Service are sharing the main thread’s resources, it would slow down the performance of your activity, and if Service is doing CPU intensive work, it could leave no resources for the activity to use, and eventually you would get an ANR error.
The best practice (but not necessarily, if the service is doing light work) would be to start a new Thread within the Service, now the Activity and the Service are using their own thread’s resources. Then you could close your activity, but Android keeps the service thread alive.
Is that it? Thanks =)

I thought you necessarily needed to create a thread within the service, otherwise it would block the main thread and you would get an ANR error.
Correct.
The paragraph mentions "intensive or blocking operations", but doesn’t mention an ANR error, it mentions performance.
Feel free to file a bug report at http://b.android.com to get them to improve this portion of the documentation. :-)
Does the Service run by default in the background of the main thread?
The lifecycle methods of a Service, such as onCreate() and onStartCommand(), are called on the main application thread. Some services, like IntentService, will provide you with a background thread (e.g., for onHandleIntent()), but that is specific to that particular subclass of Service.
and eventually you would get an ANR error.
Yes.
The best practice (but not necessarily, if the service is doing light work) would be to start a new Thread within the Service, now the Activity and the Service are using their own thread’s resources. Then you could close your activity, but Android keeps the service thread alive.
Basically, yes. Here, "light work" should be less than a millisecond or so. Also, some things that you might do are naturally asynchronous (e.g., playing a song via MediaPlayer), so it may be that the Service itself does not need its own thread, because something else that it is using is doing the threading.

Necessary to quit a HandlerThread?

My application makes use of a HandlerThread for a few operations shared across components that need to run on a background thread. Most of the time this thread will be in its wait state.
Can I leave this HandlerThread running (waiting) in my application, sending messages to it whenever necessary, but never quitting it via HandlerThread.getLooper().quit()? This could mean that this HandlerThread would continue to exist in its wait state even after all of my application components have been destroyed.
Initially this seemed like a big no to me—something I definitely would not want to do—but I'm not sure now. When Android kills my process, like it will do when it needs to free up CPU time or memory, it'll end this thread along with my UI thread. Additionally, the thread will be waiting, so it wont be consuming any CPU time. And beyond that, my application makes use of many AsyncTasks, which I know utilize a thread pool. From my understanding, AsyncTask utilizes ThreadPoolExecutor, which does not adhere to any application lifecycle callbacks (the threads in the pool when not in use, just sit waiting).
So my question is, can I use a HandlerThread across multiple application components, never (or rarely) quitting it, and leaving it waiting when not in use, without suffering terrible ill effects?

My personal preference is to create a new thread whenever there is a need for it and clean it up when it's done. This way I don't have any problems with multiple components trying to use the same thread at the same time and I keep a "clean ship". Also Android has the nice AsyncTask which makes this easy for you.
That being said, I see no reason why you can't reuse your handlerthread for multiple components, provided you regulate access to the thread AND clean it up properly when your activities are destroyed. If I understand this post correctly, your thread may keep running even if all your activities are terminated because your process may keep on running. To solve this, you can set your thread as a daemon thread. Daemon threads are automatically destroyed when the last non-daemon thread in your application is finished.
BTW, alternatively you also might want to consider using a ThreadPoolExecutor

Android Thread Pool has runnables building up without execution after background state

My application has a thread pool that creates 3 simultaneous threads. As I invoke runnables, they are added to my thread pool.
My problem happens when the application goes to the background for a while. Eventually, my threads stop executing the runnables in my pool and the pool just continues to grow. Even if I bring my application back to the foreground, my threads do not start running again.
My theory is that when my application goes to the background that my threads are being killed. I'm not sure by what and I'm also not sure of a good way of determining whether my threads are killed so that I can start them again.
Do you have any suggestions as to something I can look for to determine whether or not a thread has been killed?

You can't use a thread pool to execute code in the background because the Android activity lifecycle won't consider your app to be active, and will kill your process (including all threads) eventually after you lose UI focus. What you want is an Android Service which has a different lifecycle. To do things like this we use a local service with a Handler and a HandlerThread that we can post Runnables into. You'll probably want something similar.
Note: Every time I do this I feel like there must be an easier way, so it might be worth searching if someone has simplified this pattern.