Signing and Publishing Application

Writing and running Android applications for your own amusement is all well and
good, but the point of creating new applications is to share them with others, whether
you charge money for them or give them away for free. Google has created Android
Market just for that purpose. Anyone with a connected Android phone can open the
Android Market application and immediately download any of hundreds (soon to be
thousands) of applications expressly designed for Android. These applications range
from the very practical (Navigation, Timesheets, File Managers, etc.) to the downright
silly (applications that make rude noises for the fun of it). There are a number of steps
any application developer will go through in preparing and submitting an application
to Android Market:
1. Thoroughly test the application—at least with the Android emulator, but also with
as many actual Android devices as you can lay your hands on. There is no substitute
for testing applications on real phones under real mobile network conditions to
prove that they work as you intend. The last thing you want is thousands of people
upset with you because your application doesn’t work the way they expect it to.
2. Decide whether you’d like to add an End User License Agreement (EULA) to your
application. This is normal practice in the industry (it’s the “click to accept” license
that you see when you download an application, even on desktops), and is strongly
advised. You can create your own license using one you’ve seen that you like, or
you can have a lawyer create a new one for you. Again, you don’t have to have a
EULA to submit your application, but it is strongly advised.
3. Create the icon and label you want displayed for your application in the Application
Launcher, and attach them to your application.
4. Clean up the application for release: turn off debugging, get rid of any extraneous
print or logging statements that you had in for debug, and take a final look at the
code to clean it up.
5. Make sure you’ve included a version number and a version name in your manifest
file, and of course, bump the version number if this is a new version of a previously
released application.
6. Create a signing certificate, and, if needed, a Map API Key, as described in this
chapter.
7. Recompile your application for release using Android Tools.
8. Sign your application using jarsigner and your signing certificate.
9. Retest your signed application to be sure no errors were entered during the process.


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 multi gigahertz 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 (see “DDMS: Dalvik Debug Monitor
Service” on page 74 for more about DDMS). But again, it is important to stress that
nothing can replace testing on real Android devices.