http://commonsware.com/blog/2012/01/24/be-careful-asynctask.html
I was writing a sample app to run on the WIMM One wearable Android device, and I ran into a strange error. The flow was:
-
Run an activity, which detected that we had no data, raised a dialog, and finished once the dialog closed.
-
Along the way, the activity sent a command to an
IntentService
to go get the data. -
The next time you would launch the activity, you would get a warning about “sending message to a Handler on a dead thread”, and the activity would not fully start.
I, being a bit cocky, assumed that the problem was something with the WIMM environment.
Ummmm… not so much. I screwed up. In fact, I had seen reference to this problem before, but never fully appreciated what it meant until I ran into it myself.
The problem was that the load-the-data logic for the activity was using an AsyncTask
. That, on its own, is not a problem — in fact, it’s desirable (particularly on environments where you can’t use loaders).
However, AsyncTask
has static data members. And one of the limitations of those static data members is that they need to be initialized on the main application thread.
Normally, this is not a problem, as you usually only reference the AsyncTask
class on the main application thread, when you go to create your first instance of the task to execute.
In my case, though, I had moved some common logic into a static method on my AsyncTask
subclass… and I was calling that static method from theIntentService
in onHandleIntent()
. That was the first time I referenced my AsyncTask
subclass, and it was on a background thread. That initialized a staticHandler
used by AsyncTask
on the background thread, not the main application thread.
The error message was pointing out that the AsyncTask
static Handler
was associated with a thread (the one from onHandleIntent()
), which was now dead.
The solution: simply move the static method elsewhere.
The moral of this story is to be very careful about when you first use AsyncTask
. Some people have resorted to using a custom Application
object and touching an AsyncTask
subclass in onCreate()
, just to make sure that it is properly initialized. While IMHO that is not necessary, you do have to pay attention.
Many thanks to the WIMM team for pointing out my error. You can find out more about this issue on the Android issue tracker.