Production Signing Keys

Beyond the debug keystore, though, you will need one for production use. Distribution channels like the Play Store do not accept apps signed with the debug signing key. So, you will need to create a key that is acceptable to those channels, plus arrange to use that key when creating your production apps.

How long your production signing key is valid for is important. Once your key expires, you can no longer use it for signing new applications, which means once the key expires, you cannot update existing Android applications.

Note that both the debug signing key and its production counterpart are self-signed certificates — you do not have to purchase a certificate from Verisign or anyone. These keys are for creating immutable identity, but are not for creating confirmed identity. In other words, these certificates do not prove you are such-and-so person, but can prove that the same key signed two different APKs.

Creating a Production Signing Key

The mechanics of creating a production signing key depend on whether you will use Android Studio or will create one outside of any IDE.

Android Studio

Android Studio has support to create a production signing key as part of its overall process for creating a production-signed APK, which is covered later in this chapter.

Manually

To manually create a production signing key, you will need to use keytool. This comes with the Java SDK, and so it should be available to you already.

The keytool utility manages the contents of a “keystore”, which can contain one or more keys. Each “keystore” has a password for the store itself, and keys can also have their own individual passwords. You will need to supply these passwords later on when signing an application with the key.

Here is an example of running keytool:

keytool -genkey -v -keystore cw-release.keystore -alias cw-release -keyalg RSA -validity 10000 -keysize 2048

The parameters used here are:

1. -genkey, to indicate we want to create a new key
2. -v, to be verbose about the key creation process
3. -keystore, to indicate what keystore we are manipulating (cw-release.keystore), which will be created if it does not already exist
4. -alias, to indicate what human-readable name we want to give the key (cw-release)
5. -keyalg, to indicate what public-key encryption algorithm to be using for this key (RSA)
6. -validity, to indicate how long this key should be valid, where 10,000 days or more is recommended
7. -keysize, for indicating the length of the signing key (2,048 bits recommended, or go higher if you prefer)

If you run the above command, you will be prompted for a number of pieces of information. If you have ever created an SSL certificate, the prompts will be familiar:

$ keytool -genkey -v -keystore cw-release.keystore -alias cw-release -keyalg RSA -validity 10000 -keysize 2048
Enter keystore password:  
Re-enter new password: 
What is your first and last name?
  [Unknown]:  Mark Murphy
What is the name of your organizational unit?
  [Unknown]:     
What is the name of your organization?
  [Unknown]:  CommonsWare, LLC
What is the name of your City or Locality?
  [Unknown]:  
What is the name of your State or Province?
  [Unknown]:  PA
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=Mark Murphy, OU=Unknown, O="CommonsWare, LLC", L=Unknown, ST=PA, 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=Mark Murphy, OU=Unknown, O="CommonsWare, LLC", L=Unknown, ST=PA, C=US
Enter key password for <cw-release>
  (RETURN if same as keystore password):  
[Storing cw-release.keystore]

Signing with the Production Key

How you will apply this production signing key to sign your production app again varies by your tool chain. Here, we will focus on using Android Studio itself, though note that there are options for signing your app via Gradle tasks.

Start by opening up your project and going to “Build” > “Generate Signed Bundle/APK…” from the main menu. This brings up the first page of a signing wizard:

You have two options: an “Android app bundle” or an APK. While Google would like you to go with the “app bundle” route:

• You will be limited to distributing your app through the Play Store and nowhere else
• Google can modify your app as they see fit

This chapter will focus on the APK option. Choosing it and clicking “Next” will advance you in the wizard to where you can choose what to sign:

The drop-down at the top will let you choose a module from which to build your app. In most projects, there will be only one option, such an an app module.

The rest of the dialog is focused on getting your signing key, from a keystore file.

If this is the first time you are going to sign a production app, you will need to create your production signing key, which you can do by clicking the “Create new…” button in the wizard. This brings up a separate dialog for describing the new signing key:

You will need to provide a path to the keystore, manually or via the folder button to pick a location via a dialog. You will also need to provide a password (twice) for the keystore.

You can then supply information for the signing key within the keystore, including:

• “Alias” to indicate what human-readable name we want to give the key
• “Password” and “Confirm”, to specify a password for this specific key in the keystore (independent of the keystore’s own password)
• “Validity”, to indicate how long this key should be valid, where 25 years or more is recommended
• Details about you and your organization, asking for the standard information used in generating SSL-style keys

Clicking “OK” will generate the keystore file and save it where you specified. Be sure to back up this keystore file and safely record the passwords that you used.

If you already have a keystore file, though, back on the first page of the “Generate Signed APK” wizard, you can click “Choose existing” to bring up a file-open dialog where you can choose your keystore file. Then, fill in the keystore password, the key alias, and the key password in the dialog.

Clicking Next in the wizard brings up a page allowing you to determine what will be generated:

You can indicate where the APK file should be written and what build type to use (e.g., release).

You can also choose which signature versions that you want to use. You have two options:

1. V1, which is the way APKs have been signed since Android 1.0
2. V2, which is an improved signature format, offering stronger protection and faster app installs, but only works on Android 7.0+

Ideally, check both signature versions. If for some reason the V2 signature format causes build problems, uncheck that version and only use V1.

Clicking “Finish” will have Android Studio begin generating the APK files. This may take some time. When it is done, a popup will appear indicating that the work is completed. In the directory that you specified, Android Studio will create a subdirectory based on your build type (e.g., release/), and in there will place your signed APK file.

Two Types of Key Security

There are two facets to securing your production key that you need to think about:

• You need to make sure nobody steals your production keystore and its password. If somebody does, they could publish replacement versions of your applications — since they are signed with the same key, Android will assume the replacements are legitimate.
• You need to make sure you do not lose your production keystore and its password. Otherwise, even you will be unable to publish replacement versions of your applications.

For solo developers, the latter scenario is more probable. There already have been many cases where developers had to rebuild their development machine and wound up with new keys, locking themselves out from updating their own applications. As with everything involving computers, having a solid backup regimen is highly recommended. In particular, consider a secure off-site backup, such as having your production keystore on a thumb drive in a bank safe deposit box.

For teams, the former scenario may be more likely. If more than one person needs to be able to sign the application, the production keystore will need to be shared, possibly even stored in the revision control system for the project. The more people who have access to the keystore, the more likely it is somebody will wind up doing something evil with it. This is particularly true for projects with public revision control systems, such as open source projects — developers might not think of the implications of putting the production keystore out for people to access.