Signing Your Cordova Android App
So your app is tested, and relatively bug-free – congratulations! Now it’s time to publish on Google Play. You’ll find out pretty quickly that there are a couple of modifications you’ll need to make to your app.
Unfortunately I found that I had to do quite a bit of digging to get my release process *almost* automated. There are full instructions for this here in the Cordova docs, but I’m offering a simpler explanation that will work signing into the automation.
You’ll need to change the android:versionCode property in your AndroidManifest.xml file. Google Play will treat your app as a new version every time this value is incremented. If anyone knows how to work this into the Cordova automation, please comment on this post – I would love to hear about it. My current thought is that Cordova Hooks should work for this, but at the moment I’m not going down this path.
<manifest android:hardwareAccelerated="true" android:versionCode="2" android:versionName="1.2" ....
Creating the Key for Signing
First, create a keystore, using the keygen tool. In the following example, I’m generating one for my fictitious client, NCA:
$ keytool -genkey -v -keystore nca.keystore -alias ncamobile -keyalg RSA -keysize 2048 -validity 10000 Enter keystore password: Re-enter new password: What is your first and last name? [Unknown]: Michael Mendelson What is the name of your organizational unit? [Unknown]: NCA What is the name of your organization? [Unknown]: National Client of America What is the name of your City or Locality? [Unknown]: San Francisco What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US Is CN=Michael Mendelson, OU=NCA, O=National Client of America, L=San Francisco, ST=CA, C=US correct? [no]: yes Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 10,000 days for: CN=Michael Mendelson, OU=NCA, O=National Client of America, L=San Francisco, ST=CA, C=US Enter key password for <ncamobile> (RETURN if same as keystore password): [Storing nca.keystore]
Show the Android Build Scripts Where the Keystore is
When you build in release mode using Cordova, the Android build scripts are invoked. You’ll need to add some properties to a place where the build can see them. If you’d rather not enter the passwords, you’ll be prompted during the build.
Cordova currently builds with Gradle. When the –release switch is used, Gradle scripts will look for a file called release-signing.properties in platforms/android. Create it, and add the following settings:
storeFile=../../nca.keystore storeType=jks keyAlias=ncamobile keyPassword=passwordhere storePassword=passwordhere
There are a few other ways to do this. There’s a great StackOverflow reference for that. There’s also more detail here in the Cordova docs
Properties need to be in a place where Ant can find them. I added them to my platforms/android/local.properties file.
key.store=c:\\dev\\ncamobile\\nca.keystore key.alias=ncamobile key.store.password=passwordhere key.alias.password=passwordhere
Run the Release Build
The following should do it:
cordova build android --release
If you build without the –release argument, the app will still be signed with the Debug Key.
One issue I’d like to overcome is that items in AndroidManifest.xml and local.properties are NOT checked into our code repository, and in fact are regenerated, modified or overwritten by various Cordova processes. While it would make sense that configuration properties like this one would be set-able into the config.xml, that does not appear to be the case. Of course that impedes our ability to just check out the code and run a release build.
I’ll look for ways to smooth out this process in the future, and any insights are welcome.
Storing your key passwords there defeats the objective of signing an application.
Basically tells you not to do the above.
For cordova it is probably best to release an unsigned apk and sign it manually. This can be automated with a build process outside of cordova
Point well taken, Richard. This way the key ends up in the code repository (or other places) for unscrupulous people to get hold of. Ideally someone OTHER than the developer (build manager) would sign the program.
To smoothen one step further, you can create a plugin which does nothing but copy/paste your keystore and property file in the right place
Thank you, your post was enough to solve my problem.