我们正在团队中开发 android 应用程序。要创建签名发布 apk，您应该设置密钥存储路径、密码、密钥别名和密钥密码。如果我希望我和我的任何团队成员可以创建具有相同签名的签名 apk，我应该将密钥存储文件提交到源代码控制吗？
【问题讨论】：
标签： android git android-studio
你不应该。
Release keystore 是最敏感的数据。
在我的团队中，只有一个人可以签署发布包。 （并且可能是一个备份）。
所有敏感信息必须被忽略，我们会参考这些信息。
在我的团队中，我们是这样配置的：
在Android Studio:
/local.properties文件：
storeFile=[path/to/keystore/file]
keyAlias=[alias's key]
keyPassword=[alias's password]
storePassword=[key's password]
/app/build.gradle, config 作用域：
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
}
.
.
.
}
查看我的完整演示配置：
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'
}
【讨论】：
继续：
但是，也有缺点：您在签入时会引入一些被暴力破解的风险。因此您应该进行成本效益分析并确定这对您是否值得。
另一个考虑因素是您的组织已经在使用什么进行配置管理。如果你有一个像 Azure DevOps (TFS/VSTS) 这样的系统，你应该尝试利用它。如果您有秘密管理器，则应该与之集成。
有一些权衡：
+----------------------------+--------------------------------+- -----+--------+--------+------------+ |方法 |示例 |容易 |简单 |安全 |关注点分离 | +----------------------------+--------------------------------+- -----+--------+--------+------------+ |配置管理系统 | Azure DevOps | | | X | X | |私人仓库：未加密 |明文秘密 | X | X | | | |私人仓库：加密 |混帐秘密 | | X | X | | |秘密经理 | Azure 密钥库 | | | X | X | +----------------------------+--------------------------------+- -----+--------+--------+------------+就个人而言，如果我在一个大型组织中设置这个，我会四处寻找一位秘密经理。对于个人项目或小型团队，我只需提交密钥库并将凭据保存在其他地方。这取决于范围、风险以及可用的基础架构。
【讨论】：