The Mindful Coder

I was going through the official Android documentation for signing an app that you then want to send to users or to put in the market and it struck me that there’s too much information on that page for most scenarios. So here is a quick 1-2-3 on how to get it all done in 5 minutes flat.

This guide assumes you are using Eclipse for Android development (Why wouldn’t you?). I also used Windows when writing this up but the steps on mac/linux are very similar.

1. In Eclipse Package Explorer, right click on the Package of your app, go to Android Tools—>Export Unsigned Application Package
   
2. Save the apk file in an appropriate location
   
3. You will be shown a warning outlining the next steps required.

   

4. Next, we need to generate a key to sign our app with. The key is stored in a keystore file that ends with a .keystore extension. To generate a keystore we just the JDK’s keytool which is in your jdk\bin folder. If you have the jdk\bin folder added to your PATH environment variable, you can run it via command line from any location. Else, you will need to run the following steps from the <your jdk folder>\bin location.
5. Open a command prompt window and execute the following command. I have chosen to do so in the same folder where I placed MyApp.apk in step 2

   H:\scrap\SigningAppsDemo>keytool -genkey -v -keystore themindfulcoder.keystore -alias themindfulcoder -keyalg RSA -validity 20000

   Here, I have chosen to create a keystore called themindfulcoder.keystore so that I can reuse this key to sign other apps, not just my current app. I have also given it an alias themindfulcoder. You need to specify a validity period for the key starting from the day it was generated and I have given it an arbitrary value of 20000 – basically a *really* long time.

   Note (Windows users): When running the above command, if you face any exceptions, you should try to check if you have privileges to the folder you are in. Even better, to be safe just select to ‘run as administrator’ when opening command prompt.

6. When you run the above command, you will be asked several questions. Answer them based on how you want the certificate signed. You should now have a key.
   
7. Next step, we use the key to sign the app. To sign the app, we use the JDK’s jarsigner tool. Assuming you are now in the folder where your apk file and key are place, run the jarsigner tool as follows:

   H:\scrap\SigningAppsDemo>jarsigner -verbose -keystore themindfulcoder.keystore M
   yApp.apk themindfulcoder

   The “theminduflcoder” that you see at the end of that command is the alias that we used when generating the themindfulcoder.keystore.

8. When you run the above command, you will be asked for the passphrase that you used when generating the keystore. Enter it. You will have a signed app at the end of it!

   

9. Optional but just to make sure your app was signed correctly, run the jarsigner command again with the –verify option. I chose to run it with –verbose as well so as to see the details.
   After running, if you see “jar verified”, you are set.

And that’s it! You now have a signed app that you can put up somewhere for others to download, upload to the Android Market or send to your testers.

Here are some things to keep in mind when performing the above steps.

1. So as to keep it clean and simple, perform the above steps so that your apk file, your keystore etc all end up in one folder.
2. You are probably wondering about the choice the an arbitrary validity value of 20000 days when creating the key. If you are going to submit your app to the Android market, keep in mind that all apps submitted must have be valid till at least 1 day after 22 October 2033. This is from the Android documentation (Read the signing strategies part – useful):
   
   

   Market server enforces this requirement to ensure that users can seamlessly upgrade Market applications when new versions are available.

Useful? Let me know if you found this useful, too verbose, missing something subtle when you tried the steps out – anything at all. I want to hit the sweet spot of not too much, not too little next time I write a 1-2-3.

Good? It’s open

Bad? It’s open

Ugly? It’s open

Let me explain that.

I am an Android fan boy because the platform is so open that I can do anything I want with it. The U.S. Army loves it, NASA is doing things with it that are out there (literally), and most importantly I just saved 60 bucks in hotel Internet charges (boooo!) a couple of weekends ago when travelling using my Nexus One as a wifi access point – I mean what can’t it do? If you can thunk it, you can plunk it on the Android.

But as some burned soul once said evil is that which takes the good in us into the past to lesser freedom, lesser livingness, lesser intelligence, light and love. As over the top as that assessment is, that’s exactly what carriers out there do. Android is open to the extent that it allows carriers to disable all the goodness in Android and put horribly hobbled devices on the market. I bought a Nexus One a few months back and its such a dream – I can do anything with it. But I am a mobile developer and have had the opportunity (???) to play with devices that will soon be on the market from various carriers and they are horribly hobbled – you cannot download non-market place apps, the wifi hotspot function is gone, no USB tethering – everything that I take for granted on the Nexus One. Not cool.

Also not smart…and ugly as hell. Yesterday Verizon put out a statement saying that there will be no wifi hotspot or tethering on the Motorola Droid (on 2.2/Froyo) because apparently the Motorola hardware does not support it. Except that the same hardware can magically run both features when rooted. I mean come on, be outright about it and say you want to control the platform because you are afraid it will increase network load and you want to charge more for tethering and offer it as a paid-for option in the future. By lying, Verizon is saying we think you are fools who don’t know any better and forgetting that the base that goes for Android phones are usually the geekier of us.

And Google, sometimes you can be too open. Or let me put it this way – you can be artlessly open. Like when you install an Android app, the installer will show you all the permissions used by that app. This is one of the encouraging things about Android – it won’t allow me to develop an app that uses a phone feature without me explicitly declaring in the application manifest that I need those permissions. So when the end user is installing the app, he or she knows exactly what they are signing up for.

The problem is that the permissions listed for the end user state the “what” (what permissions are needed) but there is no framework to explain the “why’ (why does this app require these permissions?). The result is that an end user either gets frightened away from installing an useful app after reading the frightening text during installation that this app needs access to your phone information including your number – when in reality the app probably is using your device id to identify you as a user so if you are to accidentally delete this app and reinstall it, your data would not be lost. Agreed that there are better ways to do it but my point is that brutal transparency is not as helpful as toned transparency. The impact at the other end of this kind of openness is that users become so used to seeing the permissions page during an install that they soon become immune to it and stop reading it all together. The boy who cried wolf thing.

There has to be a solution somewhere between the Android’s brute force openness and Apple’s now clichéd walled garden. But if it was a choice, I would never give up my Android for the iPhone. Thankfully I live in a world where I can own and enjoy both .

I just finished my first Android app and I loved the experience. I did come across many many not-so-obvious quirks of Android development – both in the tooling and the platform that I wanted to write in one long post. There was all in this one sticky on my desktop. Deleted it. It even asked me to confirm I wanted to delete it and yet I went ahead and clicked yes.

I’ll just have to try to remember them going forward. For now, here’s one that might confuse you especially if you are debugging your Android app on both emulator and the device..or maybe multiple emulators.

Android debug, error,or log messages can be tracked through LogCat which looks something like this:

Now, while in the midst of happy debugging , if your log messages suddenly stop showing up in logcat – basically nothing is showing up in logcat – then it basically means that Android has for some reasons lost “focus” on your current emulator. This will most likely happen when you are triggering a debug session.

You fix this by opening up the devices view (Window->ShowView->Others->Devices) and selecting the emulator for which you want to see the debug messages. In the screenshot below, I’ve selected the device instead of the emulator. Now go back to the LogCat view and your log including what flew by before you selected the device should show up.