Before you can publish an app on Google Play or any other app store, you need to sign it with a private key. If you have a paid and free version or different apps for different clients, you need to sign every flavor with a different key. This is where signing configurations come in handy.

Signing configurations can be defined like this:

android {
    signingConfigs {
        staging.initWith(signingConfigs.debug)

        release {
            storeFile file("release.keystore")
            storePassword"secretpassword"
            keyAlias "gradleforandroid"
            keyPassword "secretpassword"
        }
    }
}

In this example, we create two different signing configurations.

The debug configuration is automatically set up by the Android plugin and makes use of a general keystore with a known password, so it is not necessary to create a signing configuration for this build type.

The staging configuration in the example uses initWith(), which copies all properties from another signing configuration. This means that the staging builds are signed with the debug key, instead of defining its own.

The release configuration uses storeFile to specify the path of the keystore file and then defines the key alias and both passwords.

After you define the signing configurations, you need to apply them to your build types or flavors. Build types and flavors both have a property called signingConfig, which can be used like this:

android {
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

This example uses build types, but if you want to use different certificates for every flavor you create, you need to create different signing configurations. You can define those in the exact same way:

android {
    productFlavors {
        blue {
            signingConfig signingConfigs.release
        }
    }
}

Using signing configurations this way leads to problems though. When assigning a configuration to a flavor, you are actually overriding the signing configurations for the build types. What you want to do instead, when using flavors, is to have a different key per build type per flavor:

android {
    buildTypes {
        release {
            productFlavors.red.signingConfig signingConfigs.red
            productFlavors.blue.signingConfig signingConfigs.blue
        }
    }
}

The example shows how to use different signing configurations for the red and blue flavors that use the release build type, without influencing the debug and staging build types.