When the app is based on more than one criteria, instead of creating a lot of flavors you can define flavor dimensions.
The flavor dimensions define the cartesian product that will be used to produce variants.
Example:
flavorDimensions("dimA", "dimB")
productFlavors {
row1 {
...
dimension = "dimA"
}
row2 {
...
dimension = "dimA"
}
row3 {
...
dimension = "dimA"
}
col1 {
...
dimension = "dimB"
}
col2 {
...
dimension = "dimB"
}
col3 {
...
dimension = "dimB"
}
}
This config will produce 18 (332) variants (if you have the 2 standard build types : debug
and release
).
The following build variants will be created:
row1-col1-debug
row1-col2-debug
row1-col3-debug
row1-col1-release
row1-col2-release
row1-col3-release
row2-col1-debug
row2-col2-debug
row2-col3-debug
row2-col1-release
row2-col2-release
row2-col3-release
row3-col1-debug
row3-col2-debug
row3-col3-debug
row3-col1-release
row3-col2-release
row3-col3-release
The order of the dimension is defined by android.flavorDimensions
and
drives which flavor override the other, which is important for resources when a value in a flavor replaces a value defined in a lower priority flavor.
The flavor dimension is defined with higher priority first. So in this case:
dimA > dimB > defaultConfig
There is also a "flavor combination" source folder available when more than one flavor dimension is used. For instance src/flavor1Flavor2/
.