Signing an Android Application for Real Life Mobile Device Usage / Installation

Android Certificate
If you want to publish an Android application you first need to write it 🙂

The result of your programming will be an .APK file which is the actual program binary of your application. However, the .APK file your compiler creates can only be used with the emulator on your desktop PC or Mac. You cannot use the same .APK file to install and run your app on your Android phone (like the G1, Kogan Agora, or else).

Why is that? Well, Google wants to protect its phone users from installing and running fraudulent software on their devices. Therefore, each and every application needs to be signed with a valid certificate that ensures where the application comes from. Meaning: the developer (you!) signs the application with his/her certificate to make sure it is always traceable where the application comes from. There are a bunch of more reasons to this so lets check out what Google is saying about this topic:

The important points to understand about signing Android applications are:

  • All applications must be signed. The system will not install an application that is not signed.
  • You can use self-signed certificates to sign your applications. No certificate authority is needed.
  • When you are ready to publish your application, you must sign it with a suitable private key. You can not publish an application that is signed with the default key generated by the SDK tools.
  • The system tests a signer certificate’s expiration date only at install time. If an application’s signer certificate expires after the application is installed, the application will continue to function normally.
  • You can use standard tools — Keytool and Jarsigner — to generate keys and sign your application .apk files.

3 Easy Steps for getting what you need to sign Applications
(this needs to be done once only)

  1. Create a keystore with your own keys and certificates
    First of all you need to create a keystore which stores your certificate. A certificate is always created by the developer himself without any interaction from Google. This actually means that Google does not approve certificates before you can use them for signing your application. (Note: other companies like RIM, Nokia/Symbian, Windows Mobile do such things.)

    Once you installed a Java SDK you can use the default keytool application to create your own keystore. A Java SDK is installed by default on Mac OS X machines and can also be installated additionally on your Windows PC or Linux machine. If you have Java SDK running on your system just go to any prompt and type in the following:

    Windows: START»Command
    $ keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -validity 10000

    Windows: Mac: Terminal
    $ keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -validity 10000

    You will be asked to enter a password for your keystore. Choose it wisely and remember it! You will need it every time you sign an APK file. Follow the instructions and finalize the creation of your keystore.

  2. Place the keys at a location that makes sense
    Choosing the right place for your keystore is quite important. Let’s imagine you write more than one application so it would not make that much sense to put this keystore into the project directory of the application you are currently working with. As I am using Mac OS X Leopard and Eclipse I got a project directory like /Users/YOUR_NAME/Documents/workspace/DialANumber. However, as mentioned before a more global approach might make so I copied the keystore to the directory:


    So we got our keystore prepared for signing now.

  3. Write a short script to make your life easier
    Just to make the life easier I wrote a short script which can be used each time to sign your Android APK file. You can download it below and place it in the same directory you placed the keystore at (see point 2).

    Download: Signing Script for Easy .APK Signing

Once you have done this we are ready for signing our application!

3 Easy Steps for getting your Application signed
(this needs to be done each time you build a binary that is going to be published)

  1. Build your application

    Right click your Android project in Eclipse and select Android Tools » Export Unsigned Application Package.... Follow the instructions and remember the directory your placed the .APK file at. E.g. cd /Users/YOUR_NAME/Documents/workspace/DialANumber/deploy/

  2. Go to your keystore & script directory

    cd /Users/YOUR_NAME/Documents/workspace/androidkeys/

  3. Sign your application
    In your androidkeys directory you need to execute:

    ./ ../DialANumber/deploy/DialANumber.apk
    Enter passphrase:

    After you entered your passphrase the application should be signed.

You can now upload your app to your server and install it on an Android phone or you can even publish it on the Android Market!


P.S.: The complete signing process (the part you need to do each time you sign an app) could be integrated better into Eclipse. I hope Google improves this in future. They could add an entry like Android Tools » Export Signed Application Package... so the developer just needs to enter the passphrase in a GUI dialog. This would make everyone’s life much easier. Perhaps a bored Eclipse PlugIn developer might want to write a plugin for this? It would make many people happy I guess 🙂

Please follow and like us:

23 thoughts on “Signing an Android Application for Real Life Mobile Device Usage / Installation”

  1. Having a plugin for that sure would make my life easier!!!
    I’ve simplified it by having a notpad document with the dos commands to sign my apk. When I’m ready to sign, I just copy + paste a couple of lines, put in my passcode and upload… but still… that could have been better.

  2. Thanks so much for this tutorial!

    Just a note – if one changes the keytool “alias_name”, he/she must also do it in the “” script.


  3. I keep getting the error “file ‘appname.apk’ does not contain AndroidManifest.xml”.
    I have no idea why, any help would be appreciated.

  4. I am also getting the .apk does not contain AndroidManifest.xml when installing via adb to my G1

    it signs properly, but when i check inside the .apk it does contain the AndroidManifest.xml

  5. Good tutorial, looks like someone at google/a eclipse plugin guru read your article… as there is an export signed option in eclipse under android tools (just like you suggested).


  6. Pingback: installated
  7. The below details are there on the android dev site: –

    To create a signed and aligned .apk in Eclipse:

    Select the project in the Package Explorer and select File > Export.
    Open the Android folder, select Export Android Application, and click Next.
    The Export Android Application wizard now starts, which will guide you through the process of signing your application, including steps for selecting the private key with which to sign the .apk (or creating a new keystore and private key).
    Complete the Export Wizard and your application will be compiled, signed, aligned, and ready for distribution.

  8. Thanks for sharing! As Prajakta mentioned, the feature is now available directly in Eclipse. Your how-to allowed me however to understand what I was doing.

  9. I encountered the same problem I saw other people encountered:

    I keep getting the error “file ‘appname.apk’ does not contain AndroidManifest.xml”.

    Was this issue relosved?

    I’ll be glad to get an email regarding how this problem was resoleved.



  10. i’ve published my app in the market some weeks ago. made some updates, signed the apk from the bin folder – everything worked well until today!
    when add some additional pngs into the drawable directory the jarsigner wont sign my apk. exporting an unsigned apk from eclipse will help – the problem is that google wont accept the file as update than:
    “The apk must be signed with the same certificates as the previous version.”

    i hope you can help here..

  11. They should definitely make a website where everyone could share their created apps and put them into categories that would be so nice and probably would have many visitors

  12. Is there a way to reverse engineer the .apk file to show what keystore was used for signing? I can’t locate my keystore file for this particular application, and Windows 7 isn’t finding all my files through search so I can’t locate this store.


  13. Thanks so much for this. I was struggling with a project and your detailed instructions helped. Eclipse does have a plugin for signing your apps now though, just like you suggested. Maybe some bored Eclipse plugin developer actually took the idea from your website 🙂

  14. THANK YOU! You know how hard it is to find this information? How many times the question was asked on forums and not answered? You’re a life saver.

  15. i started reading your article and immediately read something that is definitely false: “However, the .APK file your compiler creates can only be used with the emulator on your desktop PC or Mac. You cannot use the same .APK file to install and run your app on your Android phone”

    i noticed also that a lot of people are saying the same thing in stackoverflow…. it’s still not true 😉

    if i do a clean build in eclipse and then upload the resultant .apk to my server i can download it from my phone and install it w/o a problem.
    it can also be mailed and then downloaded to a phone and installed.

    maybe this has changed since you wrote the article…

  16. Hi Inor, the quote you mentioned was related to building an Android application back in January 2009. At that time, signing an APK was not built into the Eclipse SDK and therefore, a compiled APK file was not signed — which means, it did not run on real devices. Of course — and you mentioned that already — this is different 2.5 years later with much more advanced tools, like the one you are using.

    Hence, my comment was absolutely correct at the time, but is obviously outdated by now.

  17. Pingback: john thomas financial

Comments are closed.