preface

Gradle 4.10 supports the use of Kotlin DSL build scripts, so I decided to use the script to build Gradle 4.10. So this is probably the first unofficial migration guide to save your Time!

All right, without further ado, we’re on our migration journey

The preparatory work

  1. Make sure your IDE is the latest version. If not, upgrade to the latest version. This is a migration based on Android Studio 3.1.4

  2. Migration process may appear some unexpected potholes, suggest to find a free time, buy a cup of coffee, and then do…… And ya dead knock preparation 🙂

It is not recommended to migrate directly in the actual project, after all, the support for Kotlin has just come out and is not stable, you can open a branch or do a Demo project to experience.

Starting the migration

Step 1: Upgrade Gradle 4.10. You are advised to run the following command:

. / gradlew wrapper - gradle - version = 4.10

Once the update is complete, click the Sync button and there you have it. The first problem is as follows:

Let’s look at the exception description

    Configuration on demand is not supported by the current version of the Android Gradle plugin since you are using Gradle version 4.6 or above. Suggestion: disable configuration on demand by setting org.gradle.configureondemand=false in your gradle.properties file or use a Gradle version less than 4.6.
Copy the code

To put it simply, the Android Gradle plugin does not support on-demand configuration based on newer versions of Gradle.

  1. ingradle.propertiesincreaseorg.gradle.configureondemand=falseSet up the
  2. Use a version lower than Gradle 4.6

Ok, first of all, the reduced version of the project must be passed, so we can add a configuration to the gradle.properties of our project

Too Navie, when you add this configuration, you will find that it still failed to compile, the error is still the same, for this reason, I specially check several times to see if there is a missing letter or something, obviously has nothing to do with this, here should not question my professionalism as a CV warrior.

Was misled by abnormal description, at least I intuitively is directly to modify the project in the gradle. The properties, in fact, you need to modify the ${HOME} /. Gradle/gradle. The properties, of course, there are more simple way, as shown in figure:

Configuration-on-demand -is-not-supported

After confirming the success of sync, you can begin the Kotlin DSL migration

Step 2. Rewrite Groovy using Kotlin

The points to note are:

  • Groovy DSL script files use the .gradle file name extension.
  • Kotlin DSL script files use the .gradle.kts file name extension.

Gradle. KTS. Click continu, and the script will go red. The previous Groovy syntax is just wrong in Kotlin. I recommend deleting all of it and rewriting it with Kotlin to make it more impressive.

Here is a simple example project to illustrate:

Gradle > settting.gradle > build. Gradle > build. Gradle > build. Gradle > build. Gradle > build. Gradle > build. Gradle > build.

app/build.gradle -> setting.gradle -> build.gradle

A few things to note:

To be clear, Gradle currently officially supports Groovy scripting and Kotlin, although I don’t think it’s very well supported

1. androidConfiguration items cannot be automatically identified, as shown in the following figure:

2. signconfig releaseConfiguration changes

signingConfigs { create("release") { storeFile = file("your keystore path") storePassword = "your password" keyAlias = "your alias" keyPassword = "your password" } getByName("debug") { storeFile = file("your keystore path") storePassword =  "your password" keyAlias = "your alias" keyPassword = "your password" } }Copy the code

3. Rename the generated fileapkThe file name

In most developments, there will be a need to rename the apK output. In Groovy, I used:

applicationVariants.all { variant ->
    variant.outputs.all {
        outputFileName = "${flavors}@app_$versionName}.apk"
    }
}
Copy the code

The migration to Kotlin found that the attributes of outputFileName could not be used directly

Workaround: Explicitly convert to concrete implementation classes

android.applicationVariants.all {
    outputs.all {
        if (this is ApkVariantOutputImpl) {
            this.outputFileName = "$flavors@app_$versionName.apk"
        }
    }
}
Copy the code

4. setting.gradleConfiguration specifiedbuild.gradle.kts

    rootProject.buildFileName = "build.gradle.kts"

    include("app")
Copy the code

Well, if you don’t run into any other problems, you’re almost done here!

In addition, I have put the sample project of this article on GitHub, if you are interested, you can go to see ~

conclusion

First of all, I’m surprised that Gradle has come to support Kotlin DSL so quickly. It took a while, but in fact, it probably doesn’t work, if anything.

However, I think there are some advantages to be said. For those of you who use Kotlin development, first of all, the development language and build language are unified. Before you want to write build scripts, you still need to learn Groovy. Now you can write Gradle build scripts directly and enjoyably with Kotlin.

The sample Demo

Example of this article

References:

Official Migration document

Other References 1

Other References 2

About me