我的应用程序有多种构建类型和flavour(口味) gradle。
buildTypes {
release {}
test {}
debug {}
}
productFlavors {
europe {}
asia {}
}
如何根据构建类型和风味来命名应用程序?
示例:
风味europe将具有应用程序名称AppEurope
构建类型test将在应用程序名称后添加"Test"后缀,AppEuropeTest
我的应用程序有多种构建类型和flavour(口味) gradle。
buildTypes {
release {}
test {}
debug {}
}
productFlavors {
europe {}
asia {}
}
如何根据构建类型和风味来命名应用程序?
示例:
风味europe将具有应用程序名称AppEurope
构建类型test将在应用程序名称后添加"Test"后缀,AppEuropeTest
我面临着在我的表盘中遇到的同样问题,并尝试将口味依赖的应用程序名称与构建类型相关的应用程序标签值相结合。最终,我按照以下方式完成了它:
在build.gradle文件中:
buildTypes {
release {
manifestPlaceholders = [ applicationLabel: "@string/app_name"]
}
debug {
manifestPlaceholders = [ applicationLabel: "@string/app_name_dev" ]
}
}
<application
[..]
android:label="${applicationLabel}">
<resources>
<string name="app_name">Classic & Essential</string>
<string name="app_name_dev">Classic & Essential (DEV)</string>
</resources>
我在我的博客文章中也有描述:https://www.journal.deviantdev.com/android-build-type-app-name-label/
您的问题已在此处得到解答 -
为所有风味的每个构建类型创建单独的string.xml版本。
这里有一个示例项目。
https://github.com/commonsguy/cw-omnibus/tree/master/Gradle/HelloBuildType
编辑 1
android.sourceSets.europe {
res.srcDirs = ['flavor_resources/europe/res']
}
android.sourceSets.europe.debug {
res.srcDirs = ['flavor_resources/europe/debug/res']
}
相关链接展示了如何为flavors执行此操作,当扩展以包括构建类型时,概念是相同的-我们可以将flavors和构建类型组合起来创建“变体”,并且我们可以像配置制作flavors一样轻松地配置变体。
您有以下构建类型:
您有以下flavors:
您在正常位置声明了默认的app_name
字符串资源。
src/main/res/values/strings.xml
<string name="app_name">应用</string>
在这种简单情况下,不需要使用清单占位符。如果您的情况需要,可以按照其他答案进行配置。
直接在清单中使用app_name
即可。相信您为变体所做的更改将正确反映出来。
例如:
<application
android:label="@string/app_name"
etc...
标准情况下,Gradle 允许在变体源文件夹中声明资源文件(例如口味或构建类型源文件夹),这些文件将自动覆盖默认值。
在这种简单情况下,不需要使用源集。
只需为每个变体添加一个新的 strings.xml
文件,重新定义 app_name
以匹配该变体。
例如,对于 Europe Test 构建,请将文件添加到名为 europeTest
的变体文件夹中,并覆盖名称:
src/europeTest/res/values/strings.xml
<string name="app_name">AppEuropeTest</string>
根据需要,不同的变体也将拥有自己的覆盖字符串文件。
使用应用程序ID,可以配置每个风味以向应用程序ID添加一位。
这在普通构建系统中目前不可能实现,因此您目前无法配置“测试”构建以将名称“Test”附加到主名称,然后配置“欧洲”风味以附加“Europe”。
那将是非常好的,但本地不支持。
这个答案提供了一个库,您可以使用它来组合应用程序名称的替代方法,并且可以用于创建更逻辑的命名系统,特别是对于更多的风味维度(类似于应用程序ID的操作方式)。