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.


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

Figure 7-1

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

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.


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

Obtaining a Signing Certificate and API Key
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.