If you really want per-flavor properties, here's an off-the-cuff approach.
Step #1: Come up with your list of flavors. For the purposes of this answer, I'll use vanilla and chocolate.
Step #2: Create, in your module root, a properties file per flavor (i.e., vanilla.properties, chocolate.properties).
Step #3: In your productFlavors closure, you would have the code to load up that flavor's properties and use them, using something like this:
productFlavors {
vanilla {
applicationId "com.commonsware.android.gradle.hello.vanilla"
def propFile = rootProject.file('vanilla.properties')
if (propFile.canRead()) {
def Properties flavorProps = new Properties()
flavorProps.load(new FileInputStream(propFile))
// you can now access flavorProps[...] for various string keys
// identified here as ..., like flavorProps['foo']
}
}
// repeat for chocolate and other flavors
}
The only wrinkle in the above code that I can think of off the top of my head is my use of rootProject. My sample code for all of these Gradle tricks are for a project without modules, but Android Studio projects often will be set up with your code in an app/ module (a.k.a., subproject). I have not experimented with this code yet in that scenario, and I do not know if rootProject will refer to the module or the top-level project directory. There may be a different value to use, other than rootProject, to get to the module.
build.gradleis an object model representing tasks. Only after the object model is created are tasks considered, and only then is there a concept of a "current flavor". But by then yourbuild.gradlecode has long since been run. The exception would be any custom tasks you create, and those usually are created for every flavor (e.g., by iterating over the variants). - CommonsWareBuildConfig, those should be defined in yourbuild.gradlefile. I fail too see what the advantage would be of having flavor-specific code inbuild.gradle, turning around and having to read in a flavor-specific properties file. That being said, you are welcome to have per-flavor properties files, but I would put them in the module root (e.g.,${flavor}.properties) rather than try to put them in the sourceset. - CommonsWare