Peter_vdL

App Validator and Developer Sanity

by Peter_vdL Motorola on 02-16-2012 12:02 PM

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

Comments
by lalitha on 02-16-2012 08:47 PM

For ant users

 

Delete the Android debug keystore:

rm ~/.android/debug.keystore
Build again:

 ant debug

Post a Comment
Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
MOTODEV for Enterprise
Welcome...

Comment on our blog and tell us how we can help you build and distribute enterprise mobile applications on Motorola devices.

Subscribe to our RSS feed Subscribe via RSS

Follow Us

Our Blog & Comment Policy
Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Motorola. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Motorola or any other party.

Remember, when you comment, please stay on topic and avoid spam, profanity, and anything else that violates our user guidelines. All comments require approval by Motorola and can be rejected for any reason.

For customer support issues with your Motorola phone go to the Motorola customer support website.
Blogroll