Let's look at the options:
AsyncTask - Allows something to perform background work and publish results on a UI thread. Designed for you to use with something short that needs to happen in the background which once complete immediately updates the UI.
Loopers - Essentially is a construct that helps you implement queue processing on a thread. So, others can send your thread messages that are added to a queue which you then handle sequentially.
Services - Essentially an app that runs in the background and doesn't have a user interface. Once started, can continue running.
Threads - I think you understand this. Asyc within your app. Dies with your app.
So, to answer your question, a thread will be best. An external device is running independently of your application code, but only interacts with the phone while your app is running. So, it doesn't need to be emulated as a service (completely unnecessary) and should be not done as an AsyncTask - you're not emulating UI interactions (I assume). A Looper may be helpful, but it depends on the specific interaction between app and device. Your description suggests you want something to independently generate the events that your application handles (with potentially bidirectional traffic between the two). Using a Looper would require that you code both your application and external device as separate threads, then use Loopers on each to manage queued communication between the two.
So, whether you use the Looper construct or not, you'd still need to emulate your external device in a thread. Furthermore, a Looper would introduce a further level of indirection and abstraction between your app and actual device. I'm sure when you get to working with the actual device, you'd like to modify your application code as little as possible. Using a Looper, you'd need to write a thread that handles communication through the Looper construct. Since the actual communication will likely already be either asynchronous or through another synchronous (threaded) library, emulating it as a thread makes it easy to use the same semantics as the final implementation (you won't need to add on a Looper wrapper or remove the one from your app and test/debug a different interface layer).
