Keep Android Signing Credentials Out of Gradle Repositories

Separate public configuration from private material

Keep application IDs, expected certificate fingerprints and the chosen alias in controlled release documentation. Store the private keystore and passwords in a secret manager or equivalent protected CI facility. A Base64-encoded keystore in a public variable is still the same sensitive credential, not encryption.

Use access controls that distinguish ordinary build jobs from authorized release jobs. Android signing.

Resolve values without printing them

A Kotlin DSL fragment can read environment-backed values:

val signingPath = providers.environmentVariable("ANDROID_KEYSTORE_PATH")
val storeSecret = providers.environmentVariable("ANDROID_STORE_PASSWORD")
val keySecret = providers.environmentVariable("ANDROID_KEY_PASSWORD")

Use those providers in the release signing configuration according to your build setup. Fail a release task clearly when required values are absent. Do not log the passwords while diagnosing whether they were supplied.

Keep the temporary keystore outside artifact-upload globs and remove it when the job ends. A successful cleanup step should not be the only protection; restrict the workspace and artifact collection from the start.

Bind signing to the intended variant

A multi-flavor project can have several release variants and application IDs. Verify which signingConfig each variant uses. Do not let a fallback silently sign a production artifact with a debug key or another app's upload key. Build variants.

A release gate can inspect package metadata and compare the output certificate with an allowlisted public fingerprint. That catches incorrect credential selection without exposing the private key.

Protect logs, caches and forks

Untrusted pull-request jobs should not receive release secrets. Review caching and diagnostic archive rules so a temporary key file cannot be saved into a general build cache. Masking known password strings is helpful but does not prevent every encoding or file-content leak.

Limit who can edit the release workflow itself; otherwise an attacker who changes the script may gain access to secrets even when they cannot read the secret manager directly.

Retain reproducibility and recovery

Record the source revision, toolchain, variant, version code and public signing identity for every release. Test backup recovery under an authorized process. APKLint's certificate inspection can assist a final artifact review, but secret handling and release authorization remain responsibilities of the CI and account configuration.