You’ve probably been developing your application using the Android Emulator that is part of the Android Developers Kit. If you haven’t already done so, take the time to load your application on a real Android device (such as the T-Mobile G1 phone), and test the application again. The emulator is very good, but there are a number of things that can be different between the desktop emulation and a real device:

The emulator is quite flexible, and some of these things can be tested to some degree by manipulating the emulator setup in DDMS (see DDMS: Dalvik Debug Monitor Service for more about DDMS). But again, it is important to stress that nothing can replace testing on real Android devices.

Virtually every application that you download onto a desktop or notebook computer will contain an End User License Agreement. You should seriously consider whether you want to attach such a license to your application and have users agree to it before they install the application on their phone. Typically it limits what users are allowed to do with the application, defines whether it can be used for commercial purposes, specifically does not allow reverse engineering, and tries to protect you, the author, should something go wrong and someone has reason to bring a lawsuit against you. There are many such EULAs available on the Internet. You can either adopt one of those as your own or hire a lawyer to create a unique one for you, but the use of a EULA is strongly advised.

When your application is installed (on either the emulator or a real device), an icon and a label are placed on the Application Launcher that is part of your Android Desktop. This is how most users will launch your application, so you need a small graphic (in the form of a PNG file) for the icon, and a short label for your program. Icons are small square (64×64 pixel) pictures. Figure 7-1 shows the one we used for MJAndroid.

Figure 7-1. MJAndroid icon

The icon and the label are both assigned in the AndroidManifest.xml file. Here is the section of the file for MJAndroid that defines the icon (in the file icon2.png, located under the res/drawable directory) and the label (from the strings.xml file under res/values):

    <application android:icon="@drawable/icon2" android:debuggable="true">
      <uses-library android:name="com.google.android.maps" />
        <activity android:name=".MicroJobs" android:label="@string/app_name">
            <intent-filter>
...

If you’re like most developers, your path to completing your application was not linear. You tried some things, kept some, stopped using others, put in diagnostics when things didn’t work quite right, named some things that you later wished you’d named differently, and so forth. Now is the time to clean all that up. Once your application is out in the real world, you’ll have to support this version, and it would be good for you if the code were as clean as possible:

All applications submitted to Android Market must be versioned and named. You do that with simple statements in AndroidManifest.xml, as shown in the following segment of MJAndroid’s manifest:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.microjobsinc.mjandroid" android:versionCode="1" 
      android:versionName="1.0">

Obviously you want the version numbering and naming to make sense. Android Market really only cares about the versionCode, which needs to be monotonically increasing for each release of your application, so a downloading device will know when to upgrade to new versions.

Before you can publish your application to Android Market and have every Android user in the world download it, you first must sign your application. In fact, you’ve been signing your application all along, because the Android Software Development Kit generates a debug signature that is used every time you run your application from Eclipse. The catch is that you cannot use the debug signature to publish your application to the world at large; you must generate a new signature.

If you’re familiar with other mobile development environments (J2ME, Symbian, BREW, etc.), you’re probably an old hand at signing applications. But if you’re new to developing mobile applications, you may be asking yourself what all this signing stuff is for, anyway. Android uses application signing for only one purpose: to ensure that applications that claim to be from the same developer actually are. Applications from the same developer have special capabilities, discussed in the next section.

Google has stated that one of its intentions with Android was to minimize the hassle of getting applications signed. You don’t have to go to a central signing authority to get a signing certificate; you can create the certificate yourself. Once you generate the certificate, you can sign your application using the jarsigner tool that comes with the Java JDK. Once again, you don’t need to apply for or get anyone’s approval. As you’ll see, it’s about as straightforward as signing can be.

$ keytool -genkey -v -keystore microjobs.keystore -alias mjkey -keyalg RSA 
  -validity 10000

$ keytool -list -alias androiddebugkey -keystore ~/.android/debug.keystore -storepass 
   android -keypass android

debug:
[echo] Packaging bin/samples-debug.apk, and signing it with a debug key...
[exec] Debug Certificate expired on 8/4/08 3:43 PM

$ keytool -list -alias mjkey -keystore microjobs.keystore

<com.google.android.maps.MapView
    android:id="@+id/mapmain"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:clickable="true"
    android:apiKey="0P18K0TAE0dO2GifdtbuScgEGLWe3p4CYUQngMg"
/>

We’re almost ready to sign your application, but first you need to create an unsigned version that you can sign with your signature certificate. To do that, in the Package Explorer window of Eclipse, right-click on your project name. You’ll get a long pop-up menu; toward the bottom, click on Android Tools. You should see another menu that includes the item you want: “Export Unsigned Application Package...”. This item takes you to a File Save dialog box, where you can pick the place to save the unsigned version of your apk file. It doesn’t matter where you put it—just pick a place you can remember.

Now that you have an unsigned version of your apk file, we can go ahead and sign it using jarsigner. Open a terminal or command window in the directory where you stored the unsigned apk file. Here’s the line we used to sign MJAndroid, using the key we generated earlier in the keystore microjobs.keystore:

$ jarsigner -verbose -keystore microjobs.keystore MJAndroid.apk mjkey

Congratulations! You now have a signed version of your application that can be loaded and run on any Android device. But before you send it in to Android Market, there’s one more intervening step....

If everything went smoothly, your application is now signed and will function just as well as it did before you went through this process. But to be sure things went smoothly, it is wise to retest your application, again testing on real Android devices where possible. You really don’t want thousands of people downloading a broken application attributed to you, so just to be safe, retest on as many Android devices as you can get your hands on.

After you’re satisfied that your application runs as expected on real Android devices, you’re ready to upload to Android Market, Google’s service for publishing and downloading Android applications. The procedure is pretty straightforward: