BluetoothAdapter.getDefaultAdapter() throws RuntimeException: Can’t create handler inside thread that has not called Looper.prepare()

So I’m using some hardware SDK that attempts to scan for bluetooth devices on Android and hit into this exception below when calling: BluetoothAdapter.getDefaultAdapter()

Caused by: java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()
    at android.os.Handler.<init>(Handler.java:121)
    at android.bluetooth.BluetoothAdapter$1.<init>(BluetoothAdapter.java:984)
    at android.bluetooth.BluetoothAdapter.<init>(BluetoothAdapter.java:984)
    at android.bluetooth.BluetoothAdapter.getDefaultAdapter(BluetoothAdapter.java:329)

After researching this problem, it turns out there’s a bug in Android (which apparently still exists in Android 4.0: Ice Cream Sandwich according to the discussions I’ve been reading). The bug is during the initialization of the default adapter, there exists UI code which means it needs to be ran on the UI thread.

Update 2013/04/22: Martin has brought to my attention that as long as you call BluetoothAdapter.getDefaultAdapter() inside any thread that has already called Looper.prepare(), it should work. It doesn’t have to be the UI thread.

I was attempting to use AsyncTask to search for bluetooth devices in the background. Workaround suggest running the code in the main thread or using Handler so that code is queued in the main thread. Unfortunately both solutions block the UI thread and what you see is a progress dialog with a spinner that stops spinning.

It turns out however if you call BluetoothAdapter.getDefaultAdapter() in the main UI thread, calling it subsequently no longer crashes, even in background threads.

Hope that helps!

Twitter Weekly Updates for 2012-10-14

  • @mendkr Glad you made it back! Sounded like quite a trip. in reply to mendkr #
  • Nowadays, even if one engine fails and blows up, the rocket can still make it into space: http://t.co/4UAkaQGq #
  • A good way to find out which apps are using location services on iOS 6: Settings > General > Restrictions > Location Services. #
  • Turns out Just Landed was still tracking a 3-week old flight and Passbook was constantly checking if I'm near my favorite Starbucks. #
  • @rothgar Picture makes you look like you were face-planted into the sand ;p in reply to rothgar #
  • Not as cute as Om nom, but Petit from Contre Jour is cute and fun. Reminds me of Limbo. Now available on HTML5: http://t.co/trlW7ORn #
  • I wonder if flies and other insects feel pain when they ram into a window. If they do, they certainly don’t learn not to do it again. #
  • @fearthecowboy I know! They say the comment system should be back up soon, but not soon enough! in reply to fearthecowboy #

Twitter Weekly Updates for 2012-09-30

Twitter Weekly Updates for 2012-09-16

Xbox 360 Needs a Better Keyboard UI

Update: This post was drafted back in October 2009. I had submitted it as feedback to Microsoft/Xbox 360, but never really heard back. Steam just announced their Big Picture which featured a keyboard system (Daisywheel) very similar to mine (I know there are quite a few differences), so I decided to publish this post.

During the past Xbox 360 beta, I had made the following suggestion to the Xbox 360 team.

I’ve always found the keyboard UI to be clunky and difficult to use with the controller. I understand the chatpad or a keyboard would make it more easy, but I’m pretty sure most people using the Xbox 360 still use the controller to type in text. When I found out I could redeem codes via their website, it was a blessing. Typing those 25 character codes always took an inane amount of time. Now that they plan on releasing Twitter and Facebook and other apps that can require a lot typing, it’s ridiculous to use the existing keyboard UI with the controllers to type.

That’s what got me thinking of a better keyboard UI with the current controllers.

Currently we use the L-joystick for moving the cursor up/down/left/right and hitting A to select a character. To enter 1 character, I may have have to move the cursor up to 15 steps.

One thing I’ve been thinking of is that we have 2 joysticks, each with 4 axis with 8 degrees of control, which we do not take advantage of. 8 x 8 is a total of 64 possible characters. If you consider the center position (joystick in relaxed position) to be another state, that’s 9 x 9 = 81 possible characters.

Here’s a rough sketch of what the UI would look like:

Xbox 360 Keyboard UI Sketch

To type the number ‘1’, all I would have to do is point the L-joystick left, point the R-joystick up, and then push on R-joystick. Each letter would only take 3 actions (move L-joystick, move R-joystick, push on R-joystick).

That leaves the buttons (A, B, X, Y), bumpers and triggers to do other stuff like delete or move the cursor. You can even dedicate a button to switch back to the current keyboard mode. The D-pad would be perfect for this job.

As you may have noticed in my sketch, there’s a lot of empty spaces. I originally thought of putting every single character (symbols, numbers, both upper and lower case characters) on that, which is still a viable idea. Another option would be to drop that down to 5 circles (center, up, down, left, right), each circle having 8 possible characters like it is now, giving me 40 characters, which is about the same amount of characters on-screen today. You would then use the D-pad to toggle between upper and lower case, as well as symbols.

Of course there’s still more stuff to flush out, but I thought the idea was sound.

Also, given that the PlayStation 3 has a similar controller, I could see this being used on their console UI also.

Twitter Weekly Updates for 2012-09-09

Twitter Weekly Updates for 2012-09-02

Twitter Weekly Updates for 2012-08-26