ProductFlavor

dimension

abstract var dimension: String?

Specifies the flavor dimension that this product flavor belongs to.

When configuring product flavors with Android plugin 3.0.0 and higher, you must specify at least one flavor dimension, using the flavorDimensions property, and then assign each flavor to a dimension. Otherwise, you will get the following build error:

Error:All flavors must now belong to a named flavor dimension.
The flavor 'flavor_name' is not assigned to a flavor dimension.

By default, when you specify only one dimension, all flavors you configure automatically belong to that dimension. If you specify more than one dimension, you need to manually assign each flavor to a dimension, as shown in the sample below:

android {
    ...
    // Specifies the flavor dimensions you want to use. The order in which you
    // list each dimension determines its priority, from highest to lowest,
    // when Gradle merges variant sources and configurations. You must assign
    // each product flavor you configure to one of the flavor dimensions.
    flavorDimensions 'api', 'version'

    productFlavors {
        demo {
            // Assigns this product flavor to the 'version' flavor dimension.
            dimension 'version'
            ...
        }

        full {
            dimension 'version'
            ...
        }

        minApi24 {
            // Assigns this flavor to the 'api' dimension.
            dimension 'api'
            minSdkVersion '24'
            versionNameSuffix "-minApi24"
            ...
        }

        minApi21 {
            dimension "api"
            minSdkVersion '21'
            versionNameSuffix "-minApi21"
            ...
        }
    }
}

To learn more about configuring flavor dimensions, read Combine multiple flavors.

matchingFallbacks

abstract val matchingFallbacks: MutableList<String>

Specifies a sorted list of product flavors that the plugin should try to use when a direct variant match with a local module dependency is not possible.

Android plugin 3.0.0 and higher try to match each variant of your module with the same one from its dependencies. For example, when you build a "freeDebug" version of your app, the plugin tries to match it with "freeDebug" versions of the local library modules the app depends on.

However, there may be situations in which, for a given flavor dimension that exists in both the app and its library dependencies, your app includes flavors that a dependencydoes not. For example, consider if both your app and its library dependencies include a "tier" flavor dimension. However, the "tier" dimension in the app includes "free" and "paid" flavors, but one of its dependencies includes only "demo" and "paid" flavors for the same dimension. When the plugin tries to build the "free" version of your app, it won't know which version of the dependency to use, and you'll see an error message similar to the following:

Error:Failed to resolve: Could not resolve project :mylibrary.
Required by:
project :app

In this situation, you should use matchingFallbacks to specify alternative matches for the app's "free" product flavor, as shown below:

// In the app's build.gradle file.
android {
    flavorDimensions 'tier'
    productFlavors {
        paid {
            dimension 'tier'
            // Because the dependency already includes a "paid" flavor in its
            // "tier" dimension, you don't need to provide a list of fallbacks
            // for the "paid" flavor.
        }
        free {
            dimension 'tier'
            // Specifies a sorted list of fallback flavors that the plugin
            // should try to use when a dependency's matching dimension does
            // not include a "free" flavor. You may specify as many
            // fallbacks as you like, and the plugin selects the first flavor
            // that's available in the dependency's "tier" dimension.
            matchingFallbacks = ['demo', 'trial']
        }
    }
}

Note that, for a given flavor dimension that exists in both the app and its library dependencies, there is no issue when a library includes a product flavor that your app does not. That's because the plugin simply never requests that flavor from the dependency.

If instead you are trying to resolve an issue in which a library dependency includes aflavor dimension that your app does not, use missingDimensionStrategy.