SoFunction
Updated on 2025-04-10

Summary of precautions for upgrading gradle tool to 3.0

Gradle version upgrade

In fact, after AS is upgraded to 3.0, Gradle Plugin and Gradle can continue to be used without upgrading, but many new features such as Java8 support, new dependency matching mechanism, AAPT2 and other new functions cannot be used normally.

Upgrade Gradle Plugin to 3.0.0 or above, modify project/file:

Modify (custom lib managed gradle)

tools = [
  gradleTools   : ':gradle:3.0.1'
]

Modify project/file

buildscript {
  repositories {
    google()
  }
  apply from: ''
  def tools = 
  dependencies {
    classpath 
  }
}

Upgrade Gradle to 4.1 and above, modify project/gradle/file

distributionUrl=https\:///distributions/gradle-4.

Generate APK file name attribute outputFile becomes read-only

Code to change the apk name before modifying the file in the app module

 { output ->
  def outputFile = 
  if (outputFile != null && ('.apk')) {
    def fileName = "host_${}_${[0].name}_${mApplicationId}_${}_v${mVersionName}.apk"
     = new File(, fileName)
  }
}

Since the outputFile attribute becomes read-only, the following modifications are required, and the outputFileName attribute can be directly assigned:

 {
  outputFileName = "host_${}_${[0].name}_${mApplicationId}_${}_v${mVersionName}.apk"
}

Relying on keyword changes

  • api: Corresponding to the previous compile keyword, the functions are exactly the same. It will pass dependencies, causing gradle to traverse the entire dependency tree when it is compiled
  • implementation: Corresponding to the previous compile, similar to the API, the key difference is that there will be no dependency delivery
  • compileOnly: Corresponding to the previous provided, the dependency is only used in the compilation period and will not be packaged into the final apk.
  • runtimeOnly: corresponding to the previous 'apk', opposite to the above compileOnly

Regarding the difference between implementation and API, the main thing is whether the dependency will be passed. For example: A depends on B, B depends on C. If you use api, A can refer to C, but implementation cannot refer to it.

It is recommended to use implementation here. First, it will not indirectly expose references and clearly know the current dependency situation of the project; second, it can improve the search speed of the dependency tree during compilation, thereby improving the compilation speed. Channels need to declare flavor dimensions

When Sync first starts, there should be an error:

Error:All flavors must now belong to a named flavor dimension. Learn more at /r/tools/

That is, each flavor channel must belong to a dimension dimension. If there is only one dimension, the dimension attribute can be not written in the channel and it is assigned to this dimension by default. Just add a default dimension, such as: flavorDimensions "dimensionality"

The solution is to add flavorDimensions

defaultConfig {
  flavorDimensions getVersion("VERSION_CODE")
}

You can also set multiple dimensions like the official documentation

// Specifies two flavor dimensions.
flavorDimensions "mode", "minApi"
productFlavors {
  free {
    // Assigns this product flavor to the "tier" flavor dimension. Specifying
    // this property is optional if you are using only one dimension.
    dimension "mode"
    ...
  }
  paid {
    dimension "mode"
    ...
  }
  minApi23 {
    dimension "minApi"
    ...
  }
  minApi18 {
    dimension "minApi"
    ...
  }
}

Modification of the dependency method of Kudo variant

Gradle plugin 3.0.0+ introduced a new variant automatic matching mechanism, which means that the app's flavorDebug variant will automatically match the library's flavorDebug variant.

Looking back at the old method, if the app needs to rely on the corresponding type of library under a variant, you need to declare the dependency in the following way:

dependencies {
  hytestCompile project(path: ':main', configuration: 'hytestRelease')
  productionCompile project(path: ':main', configuration: 'productionRelease')
}

In the new way, gradle will automatically sense and match the corresponding variant (provided that the app and library have corresponding variant types):

dependencies {
  implementation project(':main')
}

Fill the pit

1、style attribute ‘@android:attr/windowEnterAnimation'Not found. This is caused by aapt2, and 3.0 enables aapt2 by default. Solution: Add the code to close aapt2 at the end of the project root directory:

android.enableAapt2=false

2. Gradle tool 3.0 uses the lowest SDK buildTool 26.0.2 version

3. If you use aapt, you need to remove it and use annotationProcessor instead.

Summarize

The above is a summary of the precautions for upgrading gradle tool to 3.0 introduced by the editor. I hope it will be helpful to everyone. If you have any questions, please leave me a message. The editor will recover everyone in time!