Release Process
This document covers the steps to prepare, generate, and deploy an Android release to Google Play.
In order to create a new release within Google Play, you will need to update the versionCode found within the build.gradle file:
defaultConfig {
applicationId "org.mozilla.webmaker"
minSdkVersion 14
targetSdkVersion 22
versionCode 9
versionName "1.2.0"
}In the example shown above, you would want to increment the versionCode to 10 and likely update the version name to reflect the scope of the changes. For example, if this was a bug hotfix, you would change the versionName to "1.2.1". For more information on the methodology used to update the versionName, please see the Semantic Versioning specification.
Once the build.gradle file is updated and saved, the project will sync. Any subsequent releases will create two APKs (one for x86 and one for ARM) using the versionCodes of "X00003" and "X00001" respectively. This is because Google Play requires a unique version code for each APK, regardless of the the APK being "split". You can learn more about multiple APK support here.
In order to create a valid release build, the APK will need to be "signed" using the Mozilla Foundation's signing keys. These keys are stored in a Java Key Store (JKS) file and only available to authorized staff that are responsible for releasing to Google Play. In addition the JKS file itself, you will need a password to unlock it as well as the password for the "Webmaker" key. List of requirements:
- JKS file
- Password to unlock the JKS file
- Password to unlock the "Webmaker" signing key
Once you have updated the gradle configuration and obtained access to the JKS file, you are ready to generate a release APK. To do so, go to Build -> Generate Signed APK... in Android Studio. In the "Key store path" field, choose "Select Existing" and select your JKS file. Once selected, you will be prompted to provide a password to unlock the key store. Once unlocked, select the key "Webmaker" and enter the password specific to that key. Once complete, your configuration should look similar to this:
Select "Next". Here you will define a build path and select which APK "flavors" to export:
APK Destination Folder: [Any path that you desire]
Build Type: Release
Flavors: Select both armv7 and x86
Select "Finish" and wait for your APKs to be generated. Once complete, Android Studio will present a dialog allowing you to open your destination folder as specified in the previous step. You should see two files: app-armv7-release.apk and app-x86-release.apk.
Once your APKs have been generated, you are ready to create a new production release within Google Play. Navigate to the Google Play Developer Console and select "Webmaker" from the list of available apps. If you do not see a list of apps upon logging in using your Mozilla or Mozilla Foundation email address, you will need to contact the Webmaker product and/or engineering manager to be added to the list of authorized "Release Managers" for Webmaker.
Once you have selected "Webmaker", navigate to the "APK" tab and select "Upload new APK to Production":
From the dialog, upload the X86 APK. Once prompted, you can provide user-facing release notes that users will see when prompted to update their existing installation. Once complete, repeat the process using the ARM APK. Once you have uploaded each new APK, you will need to deactivate the old versions before publishing. To do so, click on the button that says "Deactivate" next to each old APK from the list.
You can either publish your new release immediately or select "Phased" publishing from the small drop-down menu next to the "Publish" button. Phased deployment can be helpful when releasing major changes as to ensure that you do not have any regressions. An additional benefit of using phased deployment is if you do find a problem you can rollback to the prior release almost immediately (minutes instead of hours). In either case, once you have published your new APK it will be available on Google Play in 12 to 24 hours.