Android Application Development : Signing and Publishing Your Application (part 1)

1. Test Your Application

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:

Screen resolution

The Android SDK emulates a device like the T-Mobile G1, with a half VGA screen (320×480), roughly 3.2 inches in diagonal measure. Real Android devices will have a variety of screen shapes, sizes, and resolutions, so you need to know how your application will function on those different devices.

Screen orientation

The SDK emulates only portrait mode, with the screen taller than it is wide. Many Android devices (including the T-Mobile G1) support switching screen orientation, and you need to be sure your application behaves appropriately in all orientations.

Touchscreen operation

The emulator uses mouse clicks and movements to mimic the touchscreen on a real device, but there’s nothing like a real touchscreen. On a real device you can get a much better sense of what it will be like for users to interact with your application.

CPU and network performance

On the emulator, you are using your PC or Mac to emulate an ARM processor. The application’s speed is tied to the speed of your underlying host processor, which typically consists of multiple multigigahertz multiprocessors. If your application is at all performance sensitive, you’ll want to see how it functions on real devices. Similarly, the emulator is using your host’s network connection, which may be broadband, to access the Internet. On a real device your network connection will either be WiFi or a mobile network (GPRS, EDGE, HSPA, or 3G, depending on your location), and the connection’s speed and latency will be changing as the phone moves around. You want to know how these factors affect the operation of your application, and how it appears to the user.

The emulator is quite flexible, and some of these things can be tested to some degree by manipulating the emulator setup in DDMS . But again, it is important to stress that nothing can replace testing on real Android devices.

2. Attach an End User License Agreement If Desired

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.

3. Create and Attach an Icon and Label

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 1 shows the one we used for MJAndroid.

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>
...

					  

4. Clean Up for Release

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:

• Turn off debug and logging code. You don’t really want your deployed application eating up precious mobile phone storage by generating logfiles, and the user won’t be able to understand your debug messages anyway. If you haven’t already, create a boolean to switch them off and leave them off for now. And remove android:debuggable=true from the AndroidManifest.xml file (see the earlier example) to make sure debug is turned off.

• Clean up your code wherever possible. Make the naming consistent, reorder methods in some reasonable way, and try to improve readability. Even if you’re the next person to look at it, you won’t remember what you did six months from now.

• Remove any test data that you included—particularly anything that’s private or proprietary (like your name and address in a Contacts database).

• Delete any extraneous files from the project: old logfiles, source files that you no longer include in the application, etc.

5. Version Your Application

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:

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.