Android Studio 3.0 Error. Migrate dependency configurations for local modules

Google added more instruction how to solve it: Resolve build errors related to dependency matching

Cause of build error:

Your app includes a build type that a library dependency does not.

For example, your app includes a "staging" build type, but a dependency includes only a "debug" and "release" build type.

Note that there is no issue when a library dependency includes a build type that your app does not. That's because the plugin simply never requests that build type from the dependency.

Resolution

Use matchingFallbacks to specify alternative matches for a given build type, as shown below:

// In the app's build.gradle file.
android {
    buildTypes {
        debug {}
        release {}
        staging {
            // Specifies a sorted list of fallback build types that the
            // plugin should try to use when a dependency does not include a
            // "staging" build type. You may specify as many fallbacks as you
            // like, and the plugin selects the first build type that's
            // available in the dependency.
            matchingFallbacks = ['debug', 'qa', 'release']
        }
    }
}

After facing the same issue, I finally declared exactly the same buildTypes in both App and Modules' build.gradle files.

In your case, adding

buildTypes {
    debug {}
    releaseApp {}
    releaseSdk {}
}

to your module's build.gradle should do the trick.

Be sure to change any "compile project" to "implementation project" too.

Hope it helps

With the new plugin, the variant-aware dependency resolution

implementation project(':MyLib')

needs to have exact matching build types. The migration guide describes this

For instance, it is not possible to make a 'debug' variant consume a 'release' variant through this mechanism because the producer and consumer would not match. (In this case, the name 'debug' refers to the published configuration object mentioned above in the Publishing Dependencies section.) Now that we publish two configurations, one for compiling and one for runtime, this old way of selecting one configuration really doesn't work anymore.

So the old method of

releaseCompile project(path: ':foo', configuration: 'debug')

will not work anymore.

Example

With your example this would look like this:

In app build.gradle:

apply plugin: 'com.android.application'

android {
  buildTypes {
    debug {}
    releaseApp {}
    releaseSdk {}
  }
  ...
  dependencies {
    implementation project(':MyLib')
  }
}

In module/lib 'MyLib' build.gradle:

apply plugin: 'com.android.library'

android {
  buildTypes {
    debug {}
    releaseApp {}
    releaseSdk {}
  }
}

Therefore the build type must exactly match, no more no less.

Using Build-Type Fallbacks

A new feature called "matchingFallbacks" can be used to define default buildtypes if a sub-module does not define the buildtype.

Use matchingFallbacks to specify alternative matches for a given build type (...)

For example if module/lib 'MyLib' gradle would look like this:

apply plugin: 'com.android.library'

android {
  buildTypes {
    debug {}
    releaseLib {}
  }
}

You could define the following in your app build.gradle:

apply plugin: 'com.android.application'

android {
  buildTypes {
    debug {}
    releaseApp {
        ...
        matchingFallbacks = ['releaseLib']
    }
    releaseSdk {
        ...
        matchingFallbacks = ['releaseLib']
    }
  }
  ...
  dependencies {
    implementation project(':MyLib')
  }
}

Missing Flavor Dimensions

Use missingDimensionStrategy in the defaultConfig block to specify the default flavor the plugin should select from each missing dimension

android {
    defaultConfig {
        missingDimensionStrategy 'minApi', 'minApi18', 'minApi23'
        ...
    }
}