How to specify different buildTypes in Gradle 3.0.0 beta 4 and later

After updating to Gradle plugin 3.0.0 beta 4 our build failed with the following message:

buildTypeMatching has been removed. Use buildTypes..fallbacks

Our libraries have release and debug buildTypes, but our app has two additional buildTypes: releaseWithLogs and debugMinified.

Snippet of our app Gradle file:

android {
    // ...
    buildTypeMatching 'releaseWithLogs', 'release'
    buildTypeMatching 'debugMinified', 'debug'

    buildTypes {
        debug {
            // ...
        }
        debugMinified {
            // ...
        }
        release {
            // ...
        }
        releaseWithLogs {
            // ...
        }
    }
}

After some investigation, the following announcement has been found: Android Studio 3.0 Beta 4 is now available. There, it mentions:

You now provide fallbacks for missing build types and flavors using matchingFallbacks (which replaces buildTypeMatching and productFlavorMatching). You also provide the default selection and fallbacks for missing dimensions using missingDimensionStrategy (which replaces flavorSelection).

So, our previous app build.gradle gets converted to:

android {
    // ...
    //buildTypeMatching 'releaseWithLogs', 'release' // remove this
    //buildTypeMatching 'debugMinified', 'debug'     // remove this

    buildTypes {
        debug {
            // ...
        }
        debugMinified {
            // ...
            matchingFallbacks = ['debug']    // instead use this
        }
        release {
            // ...
        }
        releaseWithLogs {
            // ...
            matchingFallbacks = ['release']  // instead use this
        }
    }
}

Notice that, instead of saying that buildType releaseWithLogs will also match with release (buildTypeMatching 'releaseWithLogs', 'release'), we specify the match inside the buildType itself. Same for debugMinified matching debug. Also notice that there’s no need to include this in release and debug buildTypes, as they already match.

The original question and answer can be found in Gradle plugin 3.0.0 beta 4: “buildTypeMatching has been removed. Use buildTypes..fallbacks”

Kotlin interop: mixing Kotlin and Java ButterKnife-annotated activities

I’ve been working with Kotlin for a while, mainly for side-projects or toy-projects. Since last Google I/O 2017 announcement it has become clear that there are no more reasons or excuses to not use it in production.

One of the big selling points of Kotlin is that you can start small, by converting one class or two, or by creating new ones, while keeping all the remaining code in Java. So, interop between the two languages is almost 100% transparent. Almost.

Working to convert a small project step by step, I started to convert activities into Kotlin. Those activities use ButterKnife (I’m using current version, which is 8.7.0) to inject the views. So, after converting the first activity I stumbled upon a problem with the annotation processor: in Gradle script, you have to use either annotationProcessor or kapt, but not both at the same time. So, you have to choose:

  • using annotationProcessor only will not find Kotlin classes, and because of that injection will silently fail at runtime,
  • using kapt only will make compilation fail.

The final workaround I found was:

  • using kapt3 (by applying kotlin-kapt plugin to the Gradle script) and,
  • adding a @JvmField() annotation in addition to ButterKnife annotations so Kotlin compiler generates public fields instead of getters and setters.

By applying kapt3 we fix the compilation error involving “kotlin.jvm.internal.FunctionReference.(ILjava/lang/Object;)V” and by converting Kotlin fields to plain-old Java fields we allow ButterKnife compiler to find the fields to inject, as is unable to find Kotlin fields.

You can find the source code with different options in different branches (the one with the final solution is kotlin-workaround) in this GitHub project.

The project has two activities, one (MainActivity) that is written in Java and kept in this language, and the second one (NextActivity) that is converted to Kotlin. Notice that a simple suite of tests is available to check that both activities are being correctly injected, and that there is a TextView in both activities that has its text replaced by code to prove that the activity has been successfully injected.

Hope this tip is useful!