In March, I talked to the folks at Google to learn more about Android development. I recently embarked on my first foray into Android development, and while the result was a failure, I did like the experience, and I look forward to my next attempt.

The application that I wanted to make was designed to overcome a major shortcoming on my phone (a Motorola Devour): reconnecting to a paired headset that lost connection involves wading through a ton of menus. It is definitely not something you want to do while driving, and it is a hassle if you are on the phone and want to switch to the headset that had been disconnected. My application would be quite simple: enumerate all of the paired Bluetooth devices for the phone, find all of them with the Bluetooth headset profile, and try to connect to them if they are disconnected, and then exit. Here’s a walkthrough of what I did to write this app, and why the project was doomed to failure.

First, I needed to install and configure all of the software for Android development; I simply followed the directions on Google’s Android developer site. Everything went smoothly, and the directions were great.

Next, I fired up Eclipse and started a new project (Figure A). Everything here is pretty self-explanatory if you are a Java developer. If you are not a Java developer, you might be confused by some of the items like I was. The “package name” is basically like a .NET assembly name. Also, you will want to make sure that Create Activity is checked, and you fill in a name for it. This is the first class that will be made and called into when the application is started.
Figure A

Starting a new Android project in Eclipse

Once I got the project started, I felt a little bit of trepidation. I have never felt comfortable in Eclipse, and I have never used it for more than an hour or two at a time. I am not saying that it is a bad product (I really do not have enough experience in it to fairly judge it), but it is a different experience from Visual Studio, and it has just enough similarities to feel somewhat familiar while being too different to be comfortable. That said, for my small project, my personal Eclipse challenges really did not get in the way.

When the new project was made, it started off with a .java file with the same name as my activity in the src portion of the Package Explorer tree. Looking at this file, there is a method named onCreate made; this is the method that is called when the activity is first made — think of it as the entry point to your application. Because I was experimenting, and my application did not do very much, I put most of my work in this method. In a real application, you would do things a bit more rigorously.

I looked at the sample app Bluetooth Chat, which gave me some good ideas of where I needed to go with this project. But I immediately ran into a problem.

When I started my project, I set the Build Target to Android 1.6, since my phone is an Android 1.6 device. Eclipse was telling me that the android.bluetooth package could not be imported. Looking at the structure in Package Explorer of the Android 1.6 reference, there is no android.bluetooth item in there. Going to the Android SDK documentation and looking at the information on 1.6 confirmed that there is no android.bluetooth package in that level of the SDK, but it exists in 2.0.1. In other words, the version of Android on my phone does not allow programmers to work with the Bluetooth functionality. I was stunned.

Regardless, I plowed ahead. Combining the information in the Bluetooth Chat application and my own best guesses, I came up with this code:

package com.titaniumcrowbar.headsetreconnector;

import java.util.Set;


import android.bluetooth.BluetoothAdapter;

import android.os.Bundle;

import android.bluetooth.*;

import java.util.UUID;

public class ReconnectDevices extends Activity {

private static final UUID MY_UUID = UUID.fromString(“cb442466-580e-11df-bc5e-8e52e0d72085”);

private void notifyDone() {


/** Called when the activity is first created. */


public void onCreate(Bundle savedInstanceState) {



BluetoothAdapter localAdapter = BluetoothAdapter.getDefaultAdapter();

Set<BluetoothDevice> pairedDevices = localAdapter.getBondedDevices();

for (BluetoothDevice device : pairedDevices) {

int deviceClass = device.getBluetoothClass().getMajorDeviceClass();

if (deviceClass == BluetoothClass.Device.AUDIO_VIDEO_HANDSFREE) {


try {

BluetoothSocket temporarySocket = device.createRfcommSocketToServiceRecord(MY_UUID);



} catch (Exception ex) {







Yes, the notifyDone method is empty; I was not sure if I actually wanted to indicate success in any way.

I wanted to try to run it in the emulator, so I opened up the Android SDK setup tool (Figure B) to create a new device to try working with. I created an Android 2.0.1 device, but when I looked in the options for hardware, I did not see any choices for Bluetooth devices. This is not a major shock; when I started the device in the emulator, the Bluetooth system was not there at all. At this point, I called it quits. I am certainly not buying another Android phone just to develop on it, and I am not going to do a forced upgrade on my phone and lose the MotoBlur functionality. This project is going to have to sit on hold until Motorola gets its act together and gets MotoBlur working with Android 2.X.
Figure B

Using the Android SDK Setup tool to create a test device


Overall, the experience of writing my first Android application was not terrible. I think that the SDK documentation was positively awful, with zero examples or explanation of what anything was, but the tools seem just fine.

I am glad I gave it a try, and I am definitely not intimidated by it should I have an idea for any other Android applications. At the same time, it highlighted a massive problem for developers looking to write code for a quickly changing, highly fragmented technology like Android. When something is evolving this quickly, you cannot count on any given feature being available to all, or even the majority of your users. And the testing scenario is a nightmare. Looking through the Android Market confirms this; it seems like most apps have comments about how the app does not work right on one model of phone or another.

While the Android ecosystem is definitely the most open of all at the moment, it still manages to be unfriendly to developers.


Disclosure of Justin’s industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.


Get weekly development tips in your inbox
Keep your developer skills sharp by signing up for TechRepublic’s free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!