Should I commit release key store for Android app to team repository?

You should not.

Release keystore is the most sensitive data.

In my team, there is only one people can sign the release package. (And may be one for backing up).

All sensitive info MUST be ignored and we make a reference to these info.

In my team, we config like that:

On Android Studio:

/local.properties file:

storeFile=[path/to/keystore/file]
keyAlias=[alias's key]
keyPassword=[alias's password]
storePassword=[key's password]

/app/build.gradle, config scope:

signingConfigs {
  release {
    Properties properties = new Properties()
    properties.load(project.rootProject.file('local.properties').newDataInputStream())
    storeFile file(properties.getProperty('storeFile'))
    keyAlias properties.getProperty('keyAlias')
    storePassword properties.getProperty('storePassword')
    keyPassword properties.getProperty('keyPassword')
  }
}

buildTypes {
  release {
    minifyEnabled false
    proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    signingConfig signingConfigs.release
  }
  .
  .
  .
}

See my complete demo config:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 21
    buildToolsVersion "22.0.1"

    defaultConfig {
        multiDexEnabled = true

        applicationId "com.appconus.demoapp"
        minSdkVersion 16
        targetSdkVersion 21
        multiDexEnabled = true
        versionCode 18
        versionName "1.3"
    }

    signingConfigs {
        release {
            Properties properties = new Properties()
            properties.load(project.rootProject.file('local.properties').newDataInputStream())
            storeFile file(properties.getProperty('storeFile'))
            keyAlias properties.getProperty('keyAlias')
            storePassword properties.getProperty('storePassword')
            keyPassword properties.getProperty('keyPassword')
        }
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
        debug {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        applicationVariants.all { variant ->
            appendVersionNameVersionCode(variant, defaultConfig)
        }
    }
}
dependencies {
    compile 'com.google.android.gms:play-services:8.1.0'
}

Go ahead:

• It's AES-encrypted
• You can keep the credentials outside source control (e.g., KeePass, Beyond Trust)
• No one can access the key without the credentials

However, there are cons: You introduce some risk of it being brute-forced when you check it in. So you should do a cost-benefit analysis and figure out whether that's worth it to you.

---

Another consideration is what your organization is using for config management already. If you have a system like Azure DevOps (TFS/VSTS) in place, you should try to leverage that. If you have a secret manager, you should integrate with that.

There are tradeoffs:

+---------------------------+-------------------+------+--------+--------+------------------------+
|         Approach          |      Example      | Easy | Simple | Secure | Separation of Concerns |
+---------------------------+-------------------+------+--------+--------+------------------------+
| Config management system  | Azure DevOps      |      |        | X      | X                      |
| Private repo: unencrypted | Cleartext secrets | X    | X      |        |                        |
| Private repo: encrypted   | git-secret        |      | X      | X      |                        |
| Secret manager            | Azure Key Vault   |      |        | X      | X                      |
+---------------------------+-------------------+------+--------+--------+------------------------+

---

Personally, if I were setting this up in a large organization, I'd shop around for a secret manager. For a personal project or small team, I'd just commit the keystore and keep the credentials elsewhere. It depends on the scope, the risks, and what infrastructure is available.