Android Application Signing For Fun and Profit

I am currently enrolled in a awesome series of classes involving developing Android applications for mobile in which over 140,000 students are enrolled in the first class.  The whole series is a groundbreaking example of Massive Open Online Courses (MOOC).  I predict that this series will really turn out to be historical in the fact with so many students interacting the course is going to go from 'Semi-Contolled Chaos" to 'Nuclear Ignition'.  For example, one student tried to run and an example and received a weird application signing error. He then posts the error where everyone (in Google+ group for the course) including the instructor can share his 'pain'.  So I decided to investigate the error and it lead me to the application signing process.  Most people (including me) might think that the signing process will be bridge that cross when your application is done.  As it turned out what I discovered is that the process is one that really needs to covered 'early and often' especially in a day in a day where some people worry about their credit cards going through a metal detector.  Google has excellent page discussing the subject of application signing.

This post is about what I feel I need to know and should not be viewed as complete discussion of the issue.  I literally am switching back and forth from multiple documents on the subject and I am going to paste entries from them that I feel are germane to my situation.  My goal is to present a 'readers' digest' version so fellow students can quickly understand what they need to know about application signing.

First up "Why do applications need to be signed?" It might seem to be an obvious question with an obvious answer but I will posit that it is little more complex than one might sense at first glance.

According to Google:

The Android system requires that all installed applications be digitally signed with a certificate whose private key is held by the application's developer. The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications. The certificate is not used to control which applications the user can install. The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates.

 So I have to sign all applications but I could sign them as "Elvis Presley"?  What I infer from their statement is that all applications have some manner of tracking software with a unique identifier that will ultimately be able to differentiate varying applications and varying authors.  What happens if 'Elvis' tries to write an application named the same as one written by 'Sigmund'? The answer is a big fat peanut butter and banana error! Android will tell you it can't install the 'Elvis' authored app without first uninstalling the 'Sigmund' authored app.

I been have told that I can supersede Google applications that are included in the top layer of the Android stack but I wonder about the mechanism of doing so it avoids the signature process.  I think that Google might take offense if I go around signing my apps as "Sincerely yours, Google".

So what's an honest programmer to do? No problem, Google has a few tricks up it sleeves for the artist in training.

To test and debug your application, the build tools sign your application with a special debug key that is created by the Android SDK build tools

"Honey, Have you seen my keys, I can't find my special debug key?"  It turns out that there are different signatures which allow a programmer to write code and have them automatically signed in a debug mode. When you are ready to cash in on your application you will have to rebuild it with a suitable private key. So for the beginning programmer all you need to know is that there is a process involved in tracking application authorship and that there is a thing called a 'debug certificate' that should automatically be generated for you when are developing an application. Down the road you will have to replace the debug certificate with a private certificate before deploying your application. If you start getting certificate errors it is because something has gone wrong with the automatic creation of the debug certificate or some reasonably expected error such as you were trying to install the same application name on a device that you previously used a different development system so the same application has a different 'debug certificate'.  Fix it: Read the error and follow the instructions... yeah!

There is a lot of valuable information about the whole process that falls outside the scope of this article. Google is the replacement for the looking glass from Alice in Wonderland.  Start with the page that I listed at the top of this article and follow the links contained therein down the rabbit hole of application signing in android.  If you see the Cat in the Hat ask him if he got his hat from the Mad Hatter?

One last important thing from Der Google:
(make note of the 'skip to' sorta reminds me of the GOTO command)

Signing in Release Mode

---

When your application is ready for release to other users, you must:

1. Obtain a suitable private key
2. Compile the application in release mode
3. Sign your application with your private key
4. Align the final APK package

If you are developing in Eclipse with the ADT plugin, you can use the Export Wizard to perform the compile, sign, and align procedures. The Export Wizard even allows you to generate a new keystore and private key in the process. So if you use Eclipse, you can skip to Compile and sign with Eclipse ADT.