Trình bổ trợ Android cho Gradle 7.0.0 (tháng 7 năm 2021)

Trình bổ trợ Android cho Gradle 7.0.0 là một bản phát hành chính bao gồm nhiều các tính năng và cải tiến mới.

Khả năng tương thích

Cần có JDK 11 để chạy AGP 7.0

Khi sử dụng trình bổ trợ Android cho Gradle 7.0 để xây dựng ứng dụng, JDK 11 hiện là cần thiết để chạy Gradle. Android Studio Arctic Fox gói JDK 11 và định cấu hình Gradle để sử dụng theo mặc định, nghĩa là hầu hết Android Studio người dùng không cần thực hiện bất kỳ thay đổi nào về cấu hình đối với dự án.

Nếu bạn cần đặt Phiên bản JDK mà AGP sử dụng trong Android Studio, bạn cần sử dụng JDK 11 trở lên.

Khi sử dụng AGP độc lập với Android Studio, hãy nâng cấp phiên bản JDK bằng cách đặt biến môi trường JAVA_HOME hoặc tuỳ chọn dòng lệnh -Dorg.gradle.java.home vào thư mục cài đặt JDK 11.

Lưu ý rằng Trình quản lý SDK và Trình quản lý thiết bị ảo Android trong gói Bộ công cụ SDK không dùng nữa không phù hợp với JDK 11. Để tiếp tục sử dụng Trình quản lý SDK và Trình quản lý thiết bị ảo Android với AGP 7.0 trở lên, bạn cần chuyển sang các phiên bản mới của các công cụ trong hiện tại Bộ công cụ dòng lệnh SDK Android gói.

Variant API đã ổn định

Variant API mới hiện đã ổn định. Hãy xem các giao diện mới trong com.android.build.api.variant và các ví dụ trong Dự án GitHub gradle-recipes. Là một phần của phiên bản mới Variant API, chúng tôi đã cung cấp một số tệp trung gian, được gọi là cấu phần phần mềm, thông qua Cấu phần phần mềm . Bạn có thể lấy các cấu phần phần mềm này, chẳng hạn như tệp kê khai sáp nhập, một cách an toàn và được tuỳ chỉnh bằng trình bổ trợ và mã của bên thứ ba.

Chúng tôi sẽ tiếp tục mở rộng Variant API bằng cách bổ sung các chức năng mới và tăng cường số lượng cấu phần phần mềm trung gian mà chúng tôi cung cấp phần tuỳ chỉnh.

Thay đổi về hành vi của trình tìm lỗi mã nguồn

Phần này mô tả nhiều thay đổi về hành vi của công cụ tìm lỗi mã nguồn trong Android Gradle trình bổ trợ 7.0.0.

Cải thiện trình tìm lỗi mã nguồn cho phần phụ thuộc của thư viện

Quá trình chạy trình tìm lỗi mã nguồn bằng checkDependencies = true nay nhanh hơn so với trước đây. Đối với các dự án Android chứa một ứng dụng có thư viện phần phụ thuộc, bạn nên đặt checkDependencies thành true như hình bên dưới và để chạy công cụ tìm lỗi mã nguồn qua ./gradlew :app:lint, sẽ phân tích tất cả phần phụ thuộc các mô-đun song song và tạo một báo cáo duy nhất bao gồm các vấn đề từ ứng dụng và tất cả các phần phụ thuộc của ứng dụng đó.

// build.gradle
android {
  ...
  lintOptions {
    checkDependencies true
  }
}

// build.gradle.kts
android {
  ...
  lint {
    isCheckDependencies = true
  }
}

Giờ đây tác vụ của trình tìm lỗi mã nguồn có thể được CẬP NHẬT

Nếu các nguồn và tài nguyên của một mô-đun không thay đổi, thì quá trình phân tích tìm lỗi mã nguồn tác vụ cho mô-đun không cần chạy lại. Khi điều này xảy ra, việc thực thi tác vụ xuất hiện dưới dạng "UP-TO-DATE" trong Gradle đầu ra. Với thay đổi này, khi chạy công cụ tìm lỗi mã nguồn trên một mô-đun ứng dụng có checkDependencies = true, chỉ những mô-đun đã thay đổi mới cần chạy bản phân tích. Do đó, trình tìm lỗi mã nguồn có thể chạy nhanh hơn nữa.

Tác vụ báo cáo tìm lỗi mã nguồn cũng không cần chạy nếu dữ liệu đầu vào của tác vụ không đã thay đổi. Một vấn đề đã biết có liên quan là không có công cụ tìm lỗi mã nguồn đầu ra văn bản được in ra stdout khi tác vụ tìm lỗi mã nguồn là UP-TO-DATE (vấn đề #191897708).

Chạy trình tìm lỗi mã nguồn trên mô-đun có tính năng động

AGP không còn hỗ trợ việc chạy trình tìm lỗi mã nguồn qua các mô-đun tính năng động. Việc chạy công cụ tìm lỗi mã nguồn qua mô-đun ứng dụng tương ứng sẽ chạy công cụ tìm lỗi mã nguồn trên các mô-đun tính năng động của ứng dụng và đưa tất cả vấn đề vào trình tìm lỗi mã nguồn của ứng dụng báo cáo. Một vấn đề đã biết có liên quan là khi chạy công cụ tìm lỗi mã nguồn với checkDependencies = true từ một mô-đun ứng dụng, Các phần phụ thuộc của thư viện có tính năng động sẽ không được kiểm tra trừ phi chúng cũng là ứng dụng phần phụ thuộc (vấn đề #191977888).

Chỉ chạy trình tìm lỗi mã nguồn trên biến thể mặc định

Hiện tại, việc chạy ./gradlew :app:lint chỉ chạy trình tìm lỗi mã nguồn cho biến thể mặc định. Trong các phiên bản AGP trước đây, thuộc tính này sẽ chạy công cụ tìm lỗi mã nguồn cho tất cả các biến thể.

Thiếu cảnh báo lớp trong trình rút gọn mã R8

R8 chính xác hơn và xử lý nhất quán các lớp bị thiếu và tuỳ chọn -dontwarn. Do đó, bạn nên bắt đầu đánh giá các cảnh báo về lớp bị thiếu được phát ra của R8.

Khi R8 gặp một tham chiếu lớp không được xác định trong ứng dụng của bạn hoặc một trong các phần phụ thuộc của nó, nó sẽ phát ra cảnh báo xuất hiện trong bản dựng của bạn đầu ra. Ví dụ:

R8: Missing class: java.lang.instrument.ClassFileTransformer

Cảnh báo này có nghĩa là định nghĩa lớp Không tìm thấy java.lang.instrument.ClassFileTransformer khi phân tích mã của ứng dụng. Mặc dù điều này thường có nghĩa là có lỗi, bạn có thể bỏ qua cảnh báo này. Hai lý do phổ biến để bỏ qua cảnh báo là:

1. Các thư viện nhắm mục tiêu JVM và lớp bị thiếu là thư viện JVM loại thư viện (như trong ví dụ trên).

2. Một trong các phần phụ thuộc sử dụng API chỉ có thời gian biên dịch.

Bạn có thể bỏ qua cảnh báo về lớp bị thiếu bằng cách thêm -dontwarn quy tắc cho tệp proguard-rules.pro. Ví dụ:

-dontwarn java.lang.instrument.ClassFileTransformer

Để thuận tiện, AGP sẽ tạo một tệp chứa tất cả thiếu quy tắc thì ghi chúng vào một đường dẫn tệp như sau: app/build/outputs/mapping/release/missing_rules.txt. Thêm vào tệp proguard-rules.pro của bạn để bỏ qua cảnh báo.

Trong AGP 7.0, các thông báo về lớp bị thiếu sẽ xuất hiện dưới dạng cảnh báo và bạn có thể biến chúng thành lỗi bằng cách đặt android.r8.failOnMissingClasses = true inch gradle.properties Trong AGP 8.0, các cảnh báo này sẽ trở thành có thể làm hỏng bản dựng. Bạn có thể giữ nguyên hành vi AGP 7.0 bằng cách thêm tuỳ chọn -ignorewarnings vào proguard-rules.pro, nhưng bạn không nên làm như vậy.

Xoá bộ nhớ đệm bản dựng trình bổ trợ Android cho Gradle

Bộ nhớ đệm bản dựng AGP đã bị xoá trong AGP 4.1. Đã ra mắt trước đây trong AGP 2.3 để bổ sung cho bộ nhớ đệm bản dựng Gradle, bộ nhớ đệm bản dựng AGP đã được thay thế hoàn toàn bằng bộ nhớ đệm bản dựng Gradle trong AGP 4.1. Thay đổi này không ảnh hưởng thời gian xây dựng.

Trong AGP 7.0, thuộc tính android.enableBuildCache, thuộc tính android.buildCacheDir và Đã xoá cleanBuildCache việc cần làm.

Dùng mã nguồn Java 11 trong dự án

Giờ đây, bạn có thể biên dịch tối đa mã nguồn Java 11 trong dự án của ứng dụng, cho phép bạn sử dụng các tính năng ngôn ngữ mới hơn như phương thức giao diện riêng tư, toán tử cho các lớp ẩn danh và cú pháp biến cục bộ cho tham số lambda.

Để bật tính năng này, hãy đặt compileOptions thành giá trị mong muốn Phiên bản Java và đặt compileSdkVersion thành 30 trở lên:

// build.gradle
android {
  compileSdkVersion 30
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_11
    targetCompatibility JavaVersion.VERSION_11
  }
  // For Kotlin projects
  kotlinOptions {
    jvmTarget = "11"
  }
}

// build.gradle.kts
android {
  compileSdkVersion(30)
  compileOptions {
    sourceCompatibility(JavaVersion.VERSION_11)
    targetCompatibility(JavaVersion.VERSION_11)
  }
  kotlinOptions {
    jvmTarget = "11"
  }
}

Xoá cấu hình phần phụ thuộc

Trong AGP 7.0, các cấu hình (hoặc phạm vi phụ thuộc) sau đây đã được đã xoá:

• 
  compile Tuỳ thuộc vào trường hợp sử dụng, phương thức này đã được thay thế bằng api hoặc implementation.
  Cũng áp dụng cho các biến thể *Compile (Biên dịch), ví dụ: debugCompile.
• 
  provided Tính năng này đã được thay thế bằng compileOnly.
  Cũng áp dụng cho các biến thể *Provided (*Được cung cấp), ví dụ: releaseProvided.
• 
  apk Tính năng này đã được thay thế bằng runtimeOnly.
• 
  publish Tính năng này đã được thay thế bằng runtimeOnly.

Trong hầu hết trường hợp, AGP Trợ lý nâng cấp sẽ tự động di chuyển dự án của bạn sang .

Classpath thay đổi khi biên dịch bằng Android Trình bổ trợ Gradle

Nếu bạn đang biên dịch bằng trình bổ trợ Android cho Gradle, thì quá trình biên dịch Đường dẫn lớp có thể thay đổi. Vì AGP hiện sử dụng api/implementation cấu hình nội bộ, một số cấu phần phần mềm có thể bị xoá khỏi trình biên dịch của bạn đường dẫn lớp ( classpath). Nếu bạn phụ thuộc vào phần phụ thuộc AGP tại thời điểm biên dịch, hãy nhớ thêm nó dưới dạng phần phụ thuộc rõ ràng.

Bổ sung thư viện gốc trong tài nguyên Java thư mục không được hỗ trợ

Trước đây, bạn có thể thêm thư viện gốc trong thư mục tài nguyên Java và đăng ký thư mục bằng cách sử dụng android.sourceSets.main.resources.srcDirs để thư viện gốc được trích xuất và thêm vào tệp cuối cùng APK. Kể từ AGP 7.0, định dạng này không được hỗ trợ và các thư viện gốc trong Thư mục tài nguyên Java sẽ bị bỏ qua. Thay vào đó, hãy sử dụng phương thức DSL dành cho thư viện gốc, android.sourceSets.main.jniLibs.srcDirs. Cho thông tin khác, xem cách định cấu hình nhóm tài nguyên.

Vấn đề đã biết

Phần này mô tả các vấn đề đã biết tồn tại trong trình bổ trợ Android cho Gradle 7.0.0.

Tình trạng không tương thích với trình bổ trợ đa nền tảng Kotlin 1.4.x

Trình bổ trợ Android cho Gradle 7.0.0 tương thích với Kotlin Trình bổ trợ đa nền tảng phiên bản 1.5.0 trở lên. Các dự án sử dụng Kotlin Hỗ trợ đa nền tảng cần cập nhật lên Kotlin 1.5.0 để sử dụng Android Gradle Trình bổ trợ 7.0.0. Để khắc phục vấn đề này, bạn có thể hạ cấp trình bổ trợ Android cho Gradle lên 4.2.x, mặc dù không nên dùng điều này.

Để biết thêm thông tin, hãy xem KT-43944.

Thiếu đầu ra trình tìm lỗi mã nguồn

Không có kết quả văn bản tìm lỗi mã nguồn nào được in ra stdout khi tác vụ tìm lỗi mã nguồn là mới nhất (vấn đề #191897708). Để biết thêm bối cảnh, hãy xem Các thay đổi về hành vi đối với công cụ tìm lỗi mã nguồn. Vấn đề này sẽ được khắc phục trong trình bổ trợ Android cho Gradle 7.1.

Trình tìm lỗi mã nguồn không kiểm tra toàn bộ phần phụ thuộc của thư viện có tính năng động

Khi chạy công cụ tìm lỗi mã nguồn với checkDependencies = true qua một mô-đun ứng dụng, phần phụ thuộc của thư viện có tính năng động sẽ không được kiểm tra trừ phi nhưng chúng cũng là phần phụ thuộc của ứng dụng (vấn đề #191977888). Để khắc phục vấn đề này, bạn có thể chạy tác vụ tìm lỗi mã nguồn trên các thư viện đó. Để biết thêm bối cảnh, xem Các thay đổi về hành vi đối với công cụ tìm lỗi mã nguồn.