One of my responsibilities as an Android Technology Evangelist is to write and present training classes on Android app development. I really enjoy doing that - finding the right way to explain some awesome software, and put the “fun” back in “functions”. I usually add some hands-on coding exercises into my classes, since most students learn best by doing.
I had my latest set of lectures written, and was getting ready to
leave for class. Walter, my Teaching Assistant for this class,
was reviewing the sample code I wrote. “That’s odd,” he muttered.
There was some fast tapping on the keyboard, then Walter cleared
his throat and announced, “I can’t compile your sample apps, Peter.
None of them are compiling.”
It’s a terrible thing to learn
five minutes before you depart to teach a class, that your sample code
won’t compile. “They compile just fine on my system” won’t cut it
with students. I took a look at Walter’s laptop. Sure
enough, each of my sample apps was tainted with the little red “x” that
Eclipse uses to signify errors in a project. Doing a right click,
and “Clean selected project” made the “x”s disappear. But they
came right back as soon as Walter tried to run the project.
Eclipse gives a failing grade with a red “x” on your project
There was a confusing error message saying something was wrong
with the project properties file. Most developers won’t be
familiar with that file, because it is for the ADT, not for you.
Prior to ADT 14, it was called default.properties, and it stores a
single piece of information: the target for the project, e.g. API level
8. (And why is that info duplicated, instead of parsing it out of
the manifest file?) The project.properties file is automatically
generated, so whatever the error was, it was somewhere else.
Since the error accompanied an attempt to run the code, it
was probably related to execution, not compilation.
I planned to
take the train to the conference where I was presenting this class.
I knew the train (Amtrak’s “Capital Corridor” express) had free
onboard wifi service, so I figured I would debug the problem while
traveling. Amtrak has a web page that shows your current
position in the journey. The time pressure was on - could I solve
the problem before the train arrived at my destination?
Amtrak trip mapping - the “imperial stormtrooper” icon is the location of the train
Walter
loaned me the laptop with the problem, so I could debug during my train
ride. When you have a bug that you don’t understand, the first
step is typically to collect more information. In this case, I
analyzed one of my sample apps with App Validator. App Validator
is a free consistency-checking utility from Motorola that works on
Eclipse projects and .apk files. That’s a link to the online web
tool, and it’s also available as an Eclipse plugin and a standalone commandline tool. If you haven’t tried App Validator yet, trust me - give it a go.
There
was only one error message from App Validator, and it was nothing to do
with project properties. The message was “Debug certificate
expired”. Ah ha! All apk files have to be cryptographically
signed. When you put an app in the Android market, you have to use
a certificate that is registered to you. But for app development
and debugging, it’s convenient for the SDK to provide the certificate
for you. There is some background information about X.509
certificates here.
Upon
installation, the Android SDK generates a "debug" signing certificate
for you in a keystore called debug.keystore. The Eclipse plug-in uses
this certificate to sign each debug application build.
Unfortunately, as originally set up, the debug certificate is only
valid for 365 days. The build system will refuse to generate an
apk file using an expired debug certificate, and this was the root cause
of the problem on Walter’s laptop - Walter installed his SDK one year
and a day ago. As an anniversary present, everything stopped
working!
My train was advancing relentlessly, but luckily the fix
was simple: delete the existing debug.keystore file, and let the SDK
generate a fresh debug X.509 certificate for you. The file location is
platform dependent - you can find it in Preferences > Android >
Build > Default debug keystore. Thousands of Android
developers have hit this bug on their one year anniversary of working
with Android. The issue was filed as bug 15370
with Google, with the suggested fix “increase the certificate lifetime
to 30 years”. Google made that change in April last year, and you
can review the code here.
There are several lessons to this story, but the ones I take away are:
- Use App Validator on all your projects
- Not a bad idea to use Android Lint too
- You can do debugging on a railroad trip, but it takes a lot of training...
- You won’t hit this problem if you installed your SDK after April 2011
- But you will hit the problem in 2041 instead.
Have you tried App Validator yet? What was your experience?
Peter van der Linden
Android Technology Evangelist
