有些人可能已经看过Android Studio Gradle i / o,Xavier Ducrohet在他的快速演讲中提到了如何使用android gradle构建系统。我的问题是,文档和演示文稿缺乏快速启动的信息。或者至少对我而言。在我的下面的代码中,我试图解决gradle android插件系统的使用,我确定我有一些错误的步骤,一些正确。 (我没有经常使用蚂蚁或maven)
也许我会一步一步地完成我到目前为止所做的事情。
android {
compileSdkVersion 17
buildToolsVersion "17.0.0"
defaultConfig {
minSdkVersion 7
targetSdkVersion 16
signingStoreLocation = "debug.keystore"
signingStorePassword = "***************"
signingKeyAlias = "***************"
signingKeyPassword = "**************"
}
首先我配置调试版本的默认设置(或使用默认设置的每个版本......这意味着没有构建类型或风格?)
sourceSets:
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['com.project.maingradle', 'com.otherproject.changedsourcefilesforthisproject']
res.srcDirs = ['res', 'resfromotherprojectusingpartsofsamecode']
assets.srcDirs = ['assets']
}
}
在这一步中我定义了sourceSets。这是我第一个问题。如果我有相同的代码我想用于两个项目,是否可能/或应该完成定义更多的源集,如 - >
sourceSets {
main {...}
srcsetforanotherproject {...}
}
...取决于底层的src文件夹?或者是否应该像我在第一个sourceSets声明中那样完成sourceSets的定义,通过定义一组不同的,例如res文件夹,如Xavier Ducrohet所提到的? (还不清楚我是否只能以这种方式为res文件夹执行此操作,或者对java src代码文件夹执行此操作,例如java.srcDirs = ['com.project.maingradle','com.otherproject.changedsourcefilesforthisproject']。
signingConfigs:
signingConfigs {
debugRelease {
storeFile file("debug.keystore")
}
release {
storeFile file("release.keystore")
}
testflight {
storeFile file("testflight.keystore")
}
}
在这一步中,我已经为不同的版本定义了不同的密钥。应该没事......
buildTypes:
buildTypes {
debugRelease.initWith(buildTypes.release)
testflight.initWith(buildTypes.release)
sourceSets.debugRelease.setRoot("src/release")
sourceSets.debugRelease.setRoot("src/release")
sourceSets.debugRelease.setRoot("src/release")
debugRelease {
packageNameSuffix ".debugRelease"
versionNameSuffix "-DEBUG"
debuggable true
signingConfig signingConfigs.debug
}
testflight {
packageNameSuffix ".testflight"
versionNameSuffix "-TESTFLIGHT"
signingConfig signingConfigs.testflight
}
release {
packageNameSuffix ".release"
versionNameSuffix "-RELEASE"
runProguard true
proguardFile getDefaultProguardFile('proguard-android.txt')
signingConfig signingConfigs.release
}
}
此步骤比gradle android插件的任何其他步骤更清楚地解释。除了我不知道是否有预定义的发布或调试设置在后台工作...我还需要澄清它...至少我是这么认为的,因为使用了namesuffix,proguard或声明了这个构建的关键(signingConfig)。
口味:
flavorGroups "abi", "version"
productFlavors {
arm {
flavorGroup "abi"
}
standardproject1 {
flavorGroup "version"
minSdkVersion 7
targetSdkVersion 14
packageName "com.project.maingradle.normal"
sourceSet sourceSets.main
}
standardproject2 {
flavorGroup "version"
minSdkVersion 6
targetSdkVersion 14
packageName "com.otherproject.normal"
sourceSet sourceSets.main
}
testflightproject1 {
flavorGroup "version"
minSdkVersion 7
targetSdkVersion 14
packageName "com.project.maingradle.testflight"
sourceSet sourceSets.main
}
testflightproject2 {
flavorGroup "version"
minSdkVersion 6
targetSdkVersion 14
packageName "com.otherproject.testflight"
sourceSet sourceSets.main
}
}
}
我个人认为口味是最有趣的部分。 Xavier Ducrohet说如果你想为不同的味道构建使用不同的键,你不应该在buildtype中定义一个键(而不是在flavor中声明)?我不知道我是否理解正确。
无论如何......我在这里尝试做的是定义不同的风格,应该使用不同的设置构建,例如,针对不同系统的sdk版本控制,独占包名称以及设置一个依赖的源集,就像你在示例中看到的那样。我不确定的是,buildtypes如何依赖于味道......它们只是将每种味道都加到每种构造类型上吗?并且...可以设置一个sourceSet(如果可以设置更多的sourceSets),就像这样的味道吗?
答案 0 :(得分:1)
buildtypes如何依赖于味道......他们只是将每种味道都加到每个构建类型上吗?
是的,Gradle将生成构建类型和产品风格的每种组合。根据{{3}},每种构建类型和产品风味组合称为构建变体。
是否可以设置一个sourceSet(如果可以设置更多的sourceSets),就像这样的风格?
当然!根据{{3}},产品风味(和构建变体)也会自动包含src/myFlavorName
中自己的源集。