App Signing & Keystore (Java)

« Prev Next »

Every Android app that gets installed on a device carries a digital signature. The system checks that signature at install time and again on every update, and it will flat-out refuse to install an APK that isn't signed at all. Signing proves two things: that a specific developer built the app, and that nobody tampered with it after it left that developer's machine. For our running example, RecipeBox, this matters the moment we want to hand a build to a tester or upload it to the Play Store.

Why Signing Is Mandatory

The Android package installer verifies the certificate bundled with every APK/AAB. Two builds signed with different keys are treated as completely different apps by the system — you cannot silently swap keys between updates because the installer checks the new certificate against the one already on the device.

Build RecipeBox

Compile Java + resources

→

Sign

Attach certificate from keystore

→

Install

System verifies signature

→

Update later

Same key required to match

Debug Keystore vs Release Keystore

Android Studio auto-generates a debug keystore the first time you build, usually at ~/.android/debug.keystore, with a well-known password (android). It signs every debug build automatically so you can run RecipeBox on a device or emulator without any setup.

Never ship a release build signed with the debug keystore. Its password and alias are public knowledge, so anyone could re-sign a modified copy of your app and it would look identical to the system. A real release needs its own release keystore that only you control.

Generating a Release Keystore

You can generate one from the command line with the JDK's keytool, or use Android Studio's Build → Generate Signed Bundle / APK wizard, which calls the same tool behind a form.

/* Command line: create a new release keystore for RecipeBox */
keytool -genkey -v -keystore recipebox-release.jks ^
  -keyalg RSA -keysize 2048 -validity 10000 ^
  -alias recipebox-key

Explanation:

-keystore is the output file that holds your private key and certificate.
-alias names the key inside the keystore file (a keystore can hold several keys).
-validity 10000 keeps the certificate valid for roughly 27 years — Play Store requires a long validity period.
The tool then prompts for a keystore password, a key password, and your name/organization details for the certificate.

Guard this file like a house key. If you lose the release keystore or forget its password, there is no recovery process from Google — you can never publish an update to that same RecipeBox listing again. Your only option would be publishing a brand new app under a new package name, losing all existing installs, ratings, and reviews. Back the keystore file up in at least two secure, private locations and store its passwords in a password manager, never in source control.

Signing Configs in build.gradle

This Java-based track uses the classic Groovy DSL for Gradle files, so build.gradle (app module) defines a signingConfigs block that the release build type then references. Rather than hardcoding the keystore path and passwords in this file — which would leak them the moment the file is committed — we read them from a separate, local keystore.properties file.

// keystore.properties (NOT committed — add to .gitignore)
storeFile=../recipebox-release.jks
storePassword=yourStorePassword
keyAlias=recipebox-key
keyPassword=yourKeyPassword

// app/build.gradle (Groovy DSL)
def keystorePropertiesFile = rootProject.file("keystore.properties")
def keystoreProperties = new Properties()
keystoreProperties.load(new FileInputStream(keystorePropertiesFile))

android {
    signingConfigs {
        release {
            storeFile file(keystoreProperties['storeFile'])
            storePassword keystoreProperties['storePassword']
            keyAlias keystoreProperties['keyAlias']
            keyPassword keystoreProperties['keyPassword']
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
            minifyEnabled true
        }
    }
}

Explanation:

keystore.properties stays out of Git — teammates and CI keep their own local copy or inject it via secrets.
The release build type points at signingConfigs.release, so every release build of RecipeBox is signed automatically.
CI servers typically decode a base64-encoded keystore from a secret environment variable at build time instead of storing the raw file.

Play App Signing

Google offers a managed alternative called Play App Signing. You still sign your uploads with an upload key, but Google generates and securely stores the real app signing key that end users' devices actually see — Google re-signs your bundle with it before distribution. If you ever lose your upload key, Google can help you reset it, because the signing key that matters for existing installs never left their infrastructure. Since 2021, new apps published to Play are enrolled in Play App Signing by default.

Approach	Who holds the real signing key	Recovery if lost
Self-managed keystore	You, entirely	None — losing it can end the listing
Play App Signing	Google (you hold only the upload key)	Google can help reset the upload key

Signing gets RecipeBox onto a device safely, but signing alone isn't security — next, Security Best Practices rounds up the other habits (HTTPS, encrypted storage, input validation) every release build should follow.

« Prev Next »