1
votes

I'm currently working on migrating our project to the new gradle plugin (3.0.0) via the provided migration guide:

https://developer.android.com/studio/preview/features/new-android-plugin-migration.html

In our Android project we have a single library module and 2 app modules. The library module, as it stands, has no flavours and just the debug & release build types whereas the apps have multiple flavors and build types.

What I'm finding is that the buildTypes of the library module have to match those of the app modules exactly. For instance,

If the app module has a buildType called debugProguard, then the library module must also have a buildType called debugProguard. This means that in the library module I end up having to declare the buildTypes with no body:

    buildTypes {
        ...

        debugProguard {
        }

        ...
    }

(From here: Android Studio 3.0 Error. Migrate dependency configurations for local modules)

Is there anyway to avoid this? It seems strange that the library needs some knowledge of the architecture of the consuming app.

What I'd like to do, ideally, is to tell the build system to use a certain buildType of the library for a buildType of the app. For instance, for buildType x, y, z in the app use 'debug' in the library, and for i, j, k use 'release'.

Thanks in advance

1

1 Answers

2
votes

They've just addressed this in the Canary 7 release of Android Studio 3.0:

You can now specify an alternative build type the consumer should use from the producer using the android.buildTypeMatching property as shown below. The plugin uses the alternative build type only if a matching build type is not found.

android {
    …
    // Let's say your app configures a 'staging' build type and a library module
    // it depends on does not. You can use the property below to tell the Android plugin
    // to use a library's 'debug' build type instead.
    buildTypeMatching 'staging', 'debug'
}