One of the key points of this Arctic Fox update is the adjustment of AGP 7.0. It is estimated that many developers who upgrade directly to AGP 7.0 will find some exceptions in their projects. This article will briefly introduce the major adjustments of AGP 7.0 based on the official information.

The reason for going directly to AGP 7.0.0 is to match Gradle’s version, which means that AGP 7.x is a one-to-one mapping to Gradle 7.x API.

With this change, the AGP version number will be separate from the Android Studio version number, but for now it looks like Android Studio and Android Gradle plug-ins will be released at the same time. In general, projects using stable AGP should be able to open in newer versions of Android Studio.

JDK 11 is required to run AGP 7

Yes, don’t be surprised, building with Android Gradle Plugin 7.0 requires JDK 11 to run Gradle.

But don’t be too careful, the JDK 11 is free OpenJDK 11, and as soon as you update to Android Studio Arctic Fox, it bundles JDK 11 directly and configures Gradle to use it by default, so most of the time, If your local configuration is normal, you can use the AGP 7.0 upgrade directly.

Of course, you can also manually select the configuration. In the SDK Location section of Project Structure, you can see that the JDK configuration Location has been moved to Gradle Settings.

Open Gradle Projects and you can see the Gradle configuration options, and there are optional parameters such AS Gradle JDK, you can choose your own Java SDK, you can also choose AS built-in JDK

Such as under Mac can see bind JDK location in the/Applications/Android \ Studio app/Contents/jre/Contents/Home/bin/Java

If you need to configure running AGP without Android Studio, upgrade the JDK version by setting it to the JDK 11 installation directory using the JAVA_HOME environment variable or the -dorg.gradle.java. home command-line option.

Variant API stable

New Variant API is now stable version, you can view the com. Android. Build. API. The Variant in the new interface, and gradle – recipes dead simple example in the project.

As part of the new Variant API, a number of intermediate files called Artifacts, such as merged manifest capabilities, are provided through the Artifacts interface, which can be safely retrieved and customized using third-party plug-ins and code.

The Variant API will continue to be extended later by adding new features and increasing the number of middleware available for customization.

Lint behavior change

Lint improved for library dependencies

Running Lint with checkDependencies = true is now faster than before. It is recommended to use checkDependencies = true for projects with Android apps that the library depends on. And run./gradlew :app: Lint, which will analyze all dependency modules in parallel and provide a separate issues file containing the app and dependencies.

// build.gradle

android {
  ...
  lintOptions {
    checkDependencies true}}Copy the code
// build.gradle.kts

android {
  ...
  lint {
    isCheckDependencies = true}}Copy the code

Lint tasks can now be up-to-date

If a module’s sources and resources have not changed, there is no need TO run the Module’s Lint analysis task again. When this happens, the execution of the task appears as “up-to-date” in Gradle output.

With this transformation, when running Lint on an application module with checkDependencies = true, only the changed module needs to run the analysis, so Lint can run faster.

If the input has not changed, the Lint report task does not need TO be run. A related known problem here is that no Lint text output is printed TO stdout when the Lint task is up-to-date (issue #191897708).

Run Lint on a dynamic feature module

AGP no longer supports running Lint from a dynamic function module. Running Lint from the corresponding module will run Lint on its dynamic function module and include any problems in the application’s Lint report.

A related known problem is that when checkDependencies = true, running Lint from a module no longer checks for dynamic library dependencies unless they are also dependencies of the application (issue #191977888).

Run Lint only on the default Variant

Running./gradlew :app: Lint now only runs the default variant, which in previous versions of AGP will run Lint for all variants.

Missing class warnings in R8 shrinker

R8 can handle missing classes and the -dontwarn option more accurately and consistently, so developers should start handling missing class warnings issued by R8.

When R8 encounters a class reference that is not defined in your App or one of its dependencies, it will issue a warning and show up in your build output. Such as:

R8: Missing class: java.lang.instrument.ClassFileTransformer
Copy the code

This warning means that Java. Lang. Instrument. ClassFileTransformer in relation to the code can not find the class definition, although these after there may be a mistake, so the developer may wish to ignore this warning, ignore the warning of two common reasons are:

    1. The libraries targeted at the JVM and the missing classes are the JVM library types (as shown in the example above).
    1. One of the dependencies uses a compile-time only API.

Proguard-rules.pro can ignore missing class warnings by adding the -dontwarn rule to the file, such as:

-dontwarn java.lang.instrument.ClassFileTransformer
Copy the code

For convenience, AGP will generate a document containing the rules of all may be lost, and write them below path to the file app/build/outputs/mapping/release/missing_rules. TXT. This makes it easy to add rules to the proguard-rules.pro file to ignore warnings.

Lack of class in the AGP 7.0 message will be displayed as warning, of course. You can use the android r8. FailOnMissingClasses = true in gradle. The properties about them into errors.

In AGP 8.0, these warnings will become errors that break the build. You can maintain AGP 7.0 behavior by adding the option -ignoreWarnings configuration to the proguards-rules.pro file, but it is not recommended.

Removed Android Gradle plugin build cache

The AGP build cache has been removed in AGP 4.1. It was introduced in AGP 2.3 to complement the Gradle build cache. The AGP build cache has been completely replaced by the Gradle build cache in AGP 4.1.

The Android. enableBuildCache property, the Android. buildCacheDir property and the cleanBuildCache task have been removed in AGP 7.0.

Use Java 11 in your project

It is now possible to compile your project code using Java 11 from within the project. Developers can use updated language features such as private interface methods, anonymous diamond transporters for classes, and local variable syntax for lambda parameters.

To enable this, set compileOptions to the desired Java version and set compileSdkVersion to 30 or higher:

// build.gradle

android {
    compileSdkVersion 30

    compileOptions {
      sourceCompatibility JavaVersion.VERSION_11
      targetCompatibility JavaVersion.VERSION_11
    }

    // For Kotlin projects
    kotlinOptions {
      jvmTarget = "11"}}Copy the code
// build.gradle.kts

android {
    compileSdkVersion(30)

    compileOptions {
      sourceCompatibility(JavaVersion.VERSION_11)
      targetCompatibility(JavaVersion.VERSION_11)
    }

    kotlinOptions {
      jvmTarget = "11"}}Copy the code

Known problems

Compatible with 1.4.x Kotlin multi-platform plug-ins

Android Gradle plugin 7.0.0 is compatible with Kotlin multi-platform plugin 1.5.0 and higher.

Projects using Kotlin multi-platform support will need to update to Kotlin 1.5.0 to use Android Gradle plugin 7.0.0.

Lint output missing

When the Lint task is up to date (issue #191897708), the text output is not printed to stdout Lint. This issue will be fixed in Android Gradle plugin 7.1.

Not all dynamic library dependencies are checked by Lint

CheckDependencies = true When running Lint from an application module, dynamic library dependencies are not checked unless they are also application dependencies (issue #191977888).