Nâng cấp phiên bản phần phụ thuộc

Việc nâng cấp các phần phụ thuộc giúp bạn có quyền sử dụng các tính năng, bản sửa lỗi và điểm cải tiến mới nhất của các phần phụ thuộc đó. Để nâng cấp các phần phụ thuộc, bạn cần hiểu cách Gradle phân giải các phiên bản bạn yêu cầu, các rủi ro liên quan và các bước bạn có thể thực hiện để giảm thiểu những rủi ro đó.

Lưu ý: Kiểm thử ứng dụng hiệu quả là yếu tố then chốt để đảm bảo quá trình nâng cấp không làm hỏng bản dựng hoặc ứng dụng theo cách không mong muốn.

Cân nhắc chiến lược nâng cấp

Bước quan trọng nhất trong mọi quá trình nâng cấp là phân tích rủi ro. Xác định mức độ thoải mái của bạn với từng phần phụ thuộc mà bạn nâng cấp. Có nhiều yếu tố cần cân nhắc khi xác định chiến lược nâng cấp, bao gồm:

Tạo thư viện	Bạn đang xây dựng một ứng dụng mà người dùng tải xuống và chạy trên một thiết bị? Hay bạn đang xây dựng một thư viện để hỗ trợ các nhà phát triển khác xây dựng ứng dụng của họ? Nếu đang tạo một ứng dụng, bạn phải tập trung vào việc đảm bảo ứng dụng luôn được cập nhật và ổn định. Nếu đang xây dựng thư viện, bạn nên tập trung vào ứng dụng của các nhà phát triển khác. Các bản nâng cấp của bạn ảnh hưởng đến người dùng. Nếu bạn nâng cấp một trong các phần phụ thuộc, thì phiên bản đó sẽ trở thành ứng viên để phân giải phần phụ thuộc của Gradle, có thể làm hỏng việc ứng dụng sử dụng phần phụ thuộc đó. Trước tiên, hãy giảm thiểu các phần phụ thuộc của thư viện khi có thể. Bạn càng có ít phần phụ thuộc thì mức tác động đối với cách giải quyết phần phụ thuộc của người tiêu dùng càng thấp. Hãy nhớ làm theo phiên bản ngữ nghĩa để giúp chỉ ra loại thay đổi mà bạn đang thực hiện. Ví dụ: AndroidX tuân theo cách tạo phiên bản ngữ nghĩa và thêm một lược đồ tạo phiên bản phát hành trước. Cố gắng tránh nâng cấp phiên bản major để tránh làm hỏng ứng dụng của người dùng. Cân nhắc tạo bản phát hành đề xuất (RC) của thư viện để người dùng thử nghiệm sớm. Hãy xem Nguyên tắc về khả năng tương thích ngược dành cho tác giả thư viện để biết thông tin chi tiết về cách duy trì khả năng tương thích của Giao diện nhị phân của ứng dụng (ABI) trong thư viện. Sử dụng các công cụ và kiểm thử tích hợp như Trình xác thực khả năng tương thích tệp nhị phân để đảm bảo các thay đổi về ABI khớp với thay đổi về phiên bản mà bạn dự định. Nếu bạn phát hành bản sửa lỗi trong patch cho các phiên bản thư viện thấp hơn, thì người dùng không cần nâng cấp thư viện lên phiên bản major hoặc minor tiếp theo trừ phi họ muốn có các tính năng mới. Tránh nâng cấp các phần phụ thuộc bắc cầu trong các bản nâng cấp này. Nếu việc nâng cấp thư viện của bạn đòi hỏi những thay đổi có thể gây lỗi có thể đặc biệt ảnh hưởng xấu đến người tiêu dùng, hãy xem xét phát hành những thay đổi đó dưới dạng cấu phần phần mềm mới để các phiên bản cũ và mới có thể cùng tồn tại, đồng thời cho phép phát hành dần dần. Lưu ý: Nếu bản nâng cấp cho một trong các phần phụ thuộc có chứa thay đổi lớn về API, thì bạn nên nâng cấp lên bản phát hành đó trong bản phát hành major hoặc minor và thực hiện mọi thay đổi cần thiết. Nếu bạn không làm như vậy, người dùng thư viện của bạn có thể làm như vậy, gây ra sự không tương thích giữa thư viện và phần phụ thuộc đó. Điều này có thể áp dụng ngay cả khi thư viện của bạn không có gì thay đổi. Bạn có thể phát hành một phiên bản mới chỉ để nâng cấp phần phụ thuộc đó.
Chu kỳ phát hành	Bạn phát hành ứng dụng hoặc thư viện bao lâu một lần? Chu kỳ phát triển và phát hành ngắn hơn Bạn sẽ có ít thời gian để nâng cấp hơn. Bạn có thể nhanh chóng bị tụt lại phía sau. Việc thường xuyên nâng cấp nhỏ có thể giúp giảm khối lượng công việc. Nếu quá trình nâng cấp thư viện gặp vấn đề, bạn có thể nhanh chóng khôi phục quá trình nâng cấp đó. Các công cụ như Dependabot và Renovate giúp giảm khối lượng công việc, nhưng hãy nhớ phân tích kết quả để kiểm tra rủi ro. Chu kỳ phát triển và phát hành dài hơn Có thêm thời gian để tạo và kiểm thử bản nâng cấp. Các phiên bản phần phụ thuộc mới hơn có nhiều khả năng được phát hành trong chu kỳ của bạn. Việc quay lại các bản nâng cấp và phát hành ứng dụng hoặc thư viện sẽ mất nhiều thời gian hơn.
Nắm bắt các tính năng mới nhất	Bạn muốn sử dụng các tính năng và API mới nhất hiện có hay chỉ nâng cấp khi cần một tính năng hoặc bản sửa lỗi? Cân nhắc những điểm đánh đổi khi nâng cấp thường xuyên. Các bản nâng cấp trong tương lai sẽ dễ dàng hơn (ít thay đổi hơn để tích hợp), nhưng bạn sẽ phải đối mặt với rủi ro nâng cấp thường xuyên hơn. Việc thử nghiệm nâng cấp lên các phiên bản phát hành trước (alpha, beta, bản phát hành dùng thử) của thư viện có thể giúp bạn sẵn sàng khi có bản phát hành ổn định.
Phần phụ thuộc mới	Nếu bạn đang thêm một phần phụ thuộc mới, hãy cân nhắc một quy trình xem xét chặt chẽ để kiểm tra tất cả tiêu chí rủi ro trong thư viện đó nhằm đảm bảo chúng đã được đánh giá đúng cách. Không cho phép thêm phần phụ thuộc mới mà không được xem xét.
Nhóm chuyên trách	Bạn có nhóm xây dựng chuyên trách không? Kỹ sư phần mềm của bạn có duy trì bản dựng không? Một nhóm chuyên trách thường có thể dành nhiều thời gian hơn để phân tích rủi ro trong quá trình nâng cấp và thử nghiệm các phiên bản mới để đảm bảo bản dựng hoạt động đúng cách trước khi các kỹ sư sử dụng phiên bản mới.
Loại nâng cấp	Một số bản nâng cấp quan trọng hơn các bản nâng cấp khác. Hãy suy nghĩ xem mục nào quan trọng nhất đối với bạn. Việc nâng cấp công cụ xây dựng, chẳng hạn như Gradle và trình bổ trợ Gradle, thường ít tác động đến người dùng hơn và phần lớn rủi ro nằm trong bản dựng của bạn. Bản dựng này tự giúp xác thực những thay đổi này. Việc nâng cấp thư viện và SDK khó xác thực hơn và cũng gây rủi ro cao hơn cho người dùng. Trình bổ trợ Android cho Gradle (AGP) – công cụ dùng để tạo ứng dụng hoặc thư viện Android. Đây là bản nâng cấp quan trọng nhất mà bạn có thể thực hiện, vì bản nâng cấp này thường bao gồm hoặc hỗ trợ cải thiện hiệu suất, sửa lỗi, quy tắc tìm lỗi mã nguồn mới và hỗ trợ các phiên bản nền tảng Android mới. Gradle – bạn thường cần nâng cấp Gradle khi nâng cấp AGP hoặc một trình bổ trợ Gradle khác. Các trình bổ trợ Gradle khác – Đôi khi, API trình bổ trợ của Gradle thay đổi. Khi bạn nâng cấp Gradle, hãy kiểm tra các bản nâng cấp cho trình bổ trợ mà bạn sử dụng. Kotlin và Java – Một số thư viện và trình bổ trợ yêu cầu phiên bản Kotlin hoặc Java tối thiểu, hoặc bạn muốn tận dụng các tính năng ngôn ngữ, API mới hoặc cải thiện hiệu suất. Nền tảng Android – Cửa hàng Play yêu cầu bạn thường xuyên nâng cấp SDK Android. Bạn nên kiểm thử các phiên bản mới của SDK Android trong thời gian sớm nhất có thể. Một số bản nâng cấp SDK yêu cầu bạn phải thay đổi ứng dụng, chẳng hạn như quyền mới hoặc việc sử dụng API mới. Thư viện — Bạn có muốn ưu tiên các thư viện dựa trên mức độ gần gũi của các thư viện đó với kiến trúc tổng thể của bạn không? Các thư viện liên quan đến Nền tảng và Cấu trúc (chẳng hạn như AndroidX) thường thay đổi để tận dụng các tính năng mới hoặc giúp tóm tắt các thay đổi trong nền tảng. Hãy nâng cấp các thư viện này ít nhất mỗi khi bạn nâng cấp nền tảng Android hoặc các thư viện khác liên quan đến cấu trúc. Các bản nâng cấp thư viện khác có thể được kéo dài hoặc trì hoãn trừ phi bạn cần một tính năng mới hoặc bản sửa lỗi cụ thể. Android Studio – việc cập nhật Android Studio sẽ giúp bạn có quyền sử dụng các tính năng và bản sửa lỗi mới nhất trong nền tảng IntelliJ IDEA cơ bản cũng như các công cụ để làm việc với SDK Android mới nhất.
Các công cụ có sẵn	Có nhiều công cụ và trình bổ trợ có sẵn để hỗ trợ bạn nâng cấp. Các công cụ như Dependabot và Renovate sẽ tự động nâng cấp các phiên bản thư viện trong bản dựng của bạn, nhưng hãy nhớ phân tích kết quả để kiểm tra xem có rủi ro hay không.

Chiến lược cho các loại nâng cấp cụ thể

Việc nâng cấp một số loại phần phụ thuộc có thể có hiệu ứng lây lan, yêu cầu nâng cấp các loại phần phụ thuộc khác. Chúng tôi thảo luận về mối quan hệ giữa các thành phần bản dựng trong Các phần phụ thuộc lẫn nhau của thư viện và công cụ.

Hình 1. Xây dựng mối quan hệ.

Khi nâng cấp từng loại thành phần, hãy cân nhắc tác động của việc nâng cấp đó đối với các thành phần khác trong bản dựng.

Trình bổ trợ Android cho Gradle (AGP)	Android Studio có một trợ lý nâng cấp AGP có thể hỗ trợ các nhiệm vụ này. Nếu bạn sử dụng trợ lý hoặc nâng cấp theo cách thủ công, hãy cân nhắc những điều sau: Xem ghi chú phát hành AGP. Nâng cấp Gradle lên ít nhất là phiên bản được liệt kê. Nâng cấp Android Studio lên phiên bản hỗ trợ phiên bản AGP đã chọn. Sử dụng các phiên bản Android Studio và AGP hỗ trợ SDK Android mà bạn muốn sử dụng. Kiểm tra khả năng tương thích với Bộ công cụ xây dựng SDK, NDK và JDK. Nếu bạn phát triển một trình bổ trợ Gradle (dùng cho mục đích nội bộ hoặc công khai) mở rộng hoặc sử dụng dữ liệu từ AGP, hãy kiểm tra xem bạn có cần nâng cấp trình bổ trợ hay không. Đôi khi, AGP ngừng sử dụng và sau đó xoá các API, gây ra sự không tương thích với các trình bổ trợ trước đó.
Trình biên dịch, ngôn ngữ và thời gian chạy Kotlin	Hãy xem ghi chú phát hành Kotlin để biết các vấn đề và trường hợp không tương thích đã biết. Nếu bạn sử dụng Jetpack Compose: Nếu phiên bản Kotlin mới thấp hơn 2.0.0: Tìm trình bổ trợ trình biên dịch Compose tương thích. Nâng cấp kotlinCompilerExtensionVersion trong build.gradle.kts của bất kỳ mô-đun nào nơi nó xuất hiện. Nếu phiên bản Kotin mới là 2.0.0 trở lên: Thiết lập Trình bổ trợ Gradle cho Trình biên dịch Compose bằng cùng một phiên bản với trình biên dịch Kotlin. Nếu bạn sử dụng chế độ Xử lý biểu tượng Kotlin (KSP), hãy xem phần Bắt đầu nhanh KSP để biết cách thiết lập và xem Bản phát hành KSP cho các phiên bản có sẵn. Xin lưu ý rằng bạn phải sử dụng một phiên bản KSP khớp với phiên bản Kotlin. Ví dụ: nếu đang sử dụng Kotlin 2.0.21, bạn có thể sử dụng bất kỳ phiên bản trình bổ trợ KSP nào bắt đầu bằng 2.0.21, chẳng hạn như 2.0.21-1.0.25. Bạn thường không cần nâng cấp trình xử lý KSP (chẳng hạn như trình biên dịch Room, xuất hiện dưới dạng phần phụ thuộc ksp trong tệp bản dựng); trình bổ trợ KSP tóm tắt nhiều API trình biên dịch và API KSP mà trình xử lý sử dụng là ổn định. Nâng cấp tất cả các Trình bổ trợ trình biên dịch Kotlin khác mà bạn đang sử dụng. API Trình bổ trợ Trình biên dịch Kotlin thường thay đổi giữa các bản phát hành và các trình bổ trợ phải sử dụng API tương thích. Nếu trình bổ trợ được liệt kê trong Trình bổ trợ trình biên dịch, bạn phải sử dụng cùng một phiên bản với trình biên dịch Kotlin. Đối với bất kỳ trình bổ trợ biên dịch nào khác, hãy tham khảo tài liệu của trình bổ trợ đó để ánh xạ phù hợp. Xin lưu ý rằng các trình bổ trợ trình biên dịch không được duy trì cùng với chính trình biên dịch Kotlin thường bị chậm phát hành khi chờ API trình bổ trợ trình biên dịch ổn định. Trước khi nâng cấp Kotlin, hãy kiểm tra để đảm bảo tất cả trình bổ trợ trình biên dịch mà bạn sử dụng đều có bản nâng cấp phù hợp. Cuối cùng, trong một số trường hợp, ngôn ngữ Kotlin sẽ thay đổi, yêu cầu bạn cập nhật mã. Điều này thường xảy ra nếu bạn đang dùng thử các tính năng thử nghiệm. Nếu mã của bạn không tạo đúng cách sau khi nâng cấp trình biên dịch Kotlin, hãy kiểm tra các thay đổi về ngôn ngữ hoặc lỗi thư viện thời gian chạy trong ghi chú phát hành Kotlin.
Trình bổ trợ trình biên dịch Kotlin	Nếu bạn cần nâng cấp trình bổ trợ trình biên dịch Kotlin, hãy nâng cấp lên phiên bản Kotlin phù hợp đang được sử dụng. Hầu hết các trình bổ trợ trình biên dịch Kotlin đều sử dụng cùng một phiên bản với trình biên dịch Kotlin hoặc bắt đầu bằng phiên bản bắt buộc của trình biên dịch Kotlin. Ví dụ: nếu phiên bản trình bổ trợ là 2.0.21-1.0.25, bạn phải sử dụng phiên bản 2.0.21 của trình biên dịch Kotlin. Đôi khi, việc thay đổi phiên bản trình biên dịch Kotlin đòi hỏi phải thay đổi các nội dung khác.
Thư viện	Thư viện là phần phụ thuộc được nâng cấp thường xuyên nhất trong bản dựng. Bạn sẽ thấy các bản nâng cấp có sẵn trong trình chỉnh sửa Android Studio hoặc nếu bạn sử dụng một số công cụ và trình bổ trợ phần phụ thuộc. Một số thư viện chỉ định compileSdk hoặc minSdk tối thiểu cần thiết để sử dụng thư viện. Nếu bạn không sử dụng ít nhất compileSdk được chỉ định, thì bản dựng sẽ không thành công. Tuy nhiên, minSdk của ứng dụng sẽ tự động được đặt thành giá trị tối đa của tất cả các giá trị minSdk được chỉ định trong các phần phụ thuộc thư viện và tệp bản dựng. Một số thư viện cũng chỉ định phiên bản Kotlin tối thiểu để sử dụng. Cập nhật phiên bản Kotlin trong các tệp bản dựng sao cho phiên bản ít nhất là được chỉ định.
Gradle	Đôi khi, các phiên bản mới của Gradle sẽ ngừng sử dụng các API hiện có, xoá các API đó trong một bản phát hành trong tương lai. Nếu bạn phát triển một trình bổ trợ Gradle, hãy nâng cấp trình bổ trợ của mình càng sớm càng tốt, đặc biệt là khi trình bổ trợ đó đang ở chế độ công khai. Một số bản nâng cấp Gradle yêu cầu bạn phải tìm phiên bản mới của các trình bổ trợ mà bạn sử dụng. Xin lưu ý rằng các trình bổ trợ này có thể bị chậm trễ trong quá trình phát triển khi nâng cấp trình bổ trợ để khớp với API trình bổ trợ Gradle mới nhất. Cách nâng cấp Gradle: Đọc ghi chú phát hành cho phiên bản bạn muốn sử dụng. Nâng cấp phiên bản Gradle trong gradle/wrapper/gradle-wrapper.properties. Nâng cấp tệp jar và tập lệnh trình bao bọc Gradle bằng cách chạy ./gradlew wrapper --gradle-version latest. Nâng cấp trình bổ trợ Gradle. Nâng cấp JDK dùng để chạy Gradle.
Trình bổ trợ Gradle	Đôi khi, các trình bổ trợ Gradle đã nâng cấp sử dụng các API Gradle mới hoặc đã thay đổi, do đó, bạn cần nâng cấp Gradle hoặc có thể thay đổi cấu hình của các trình bổ trợ đó trong tệp bản dựng. Trong cả hai trường hợp, bạn sẽ thấy cảnh báo hoặc lỗi bản dựng cho biết sự không tương thích. Bất cứ khi nào nâng cấp trình bổ trợ, hãy nâng cấp Gradle.
SDK Android	Android Studio có một trợ lý nâng cấp SDK Android có thể giúp bạn thực hiện những việc này. Nếu bạn sử dụng trợ lý hoặc nâng cấp theo cách thủ công, hãy cân nhắc những điều sau: Mỗi bản phát hành SDK Android đều chứa các tính năng và API mới, bản sửa lỗi và thay đổi về hành vi. Cửa hàng Play yêu cầu bạn cập nhật targetSdk, nhưng hãy cân nhắc cập nhật targetSdk sớm hơn thời hạn để có thêm thời gian thực hiện mọi thay đổi cần thiết. Trước khi nâng cấp SDK Android, hãy đọc kỹ ghi chú phát hành. Hãy chú ý đến phần thay đổi về hành vi, bao gồm: Các quyền mới mà bạn cần yêu cầu khi cài đặt hoặc khi bắt đầu chạy. Các API không dùng nữa và API thay thế. Các thay đổi có thể gây lỗi về API hoặc hành vi. API Kotlin hoặc Java mới có thể ảnh hưởng đến mã của bạn. Phần thay đổi về hành vi có thể khá dài, nhưng hãy chú ý kỹ vì phần này thường chứa các thay đổi quan trọng mà bạn cần thực hiện đối với ứng dụng của mình. Bạn phải nâng cấp targetSdk để đáp ứng các yêu cầu của Cửa hàng Play. Bạn không bắt buộc phải nâng cấp compileSdk để có quyền truy cập vào các API mới. Xin lưu ý rằng một số thư viện (như AndroidX) có yêu cầu tối thiểu về compileSdk. Để tận dụng các tính năng SDK mới trong quá trình phát triển và đảm bảo khả năng tương thích trong bản dựng, hãy nâng cấp trình bổ trợ Android cho Gradle (AGP) và Android Studio. Các công cụ này bao gồm cả công cụ mới và cải tiến cho SDK mới. Xem Phiên bản tối thiểu của các công cụ dành cho cấp độ API Android. Khi nâng cấp SDK Android, hãy nâng cấp mọi thư viện AndroidX mà bạn sử dụng. AndroidX thường sử dụng các API mới và được cập nhật để có khả năng tương thích và hiệu suất tốt hơn trên các phiên bản SDK Android.
Android Studio	Nhìn chung, bạn có thể nâng cấp Android Studio bất cứ lúc nào. Bạn có thể thấy các thông báo nhắc bạn nâng cấp AGP hoặc nâng cấp SDK Android. Bạn nên nâng cấp nhưng không bắt buộc. Sau này, nếu muốn sử dụng Android Studio để nâng cấp AGP hoặc SDK Android, bạn có thể tìm thấy các tuỳ chọn này trên trình đơn Tools (Công cụ): Trợ lý nâng cấp AGP… Trợ lý nâng cấp SDK Android…
Java	Nếu có mã nguồn Java trong ứng dụng Android, bạn nên tận dụng các API Java mới hơn. Mỗi phiên bản SDK Android đều hỗ trợ một tập hợp con API Java và các tính năng ngôn ngữ. AGP cung cấp khả năng tương thích cho các phiên bản SDK Android thấp hơn bằng một quy trình có tên là đơn giản hoá. Ghi chú phát hành SDK Android chỉ định cấp độ Java được hỗ trợ và các vấn đề tiềm ẩn. Một số vấn đề trong số này cũng có thể ảnh hưởng đến mã nguồn Kotlin, vì Kotlin có quyền truy cập vào cùng các API Java. Hãy nhớ chú ý kỹ các phần API JDK xuất hiện trong phần thay đổi về hành vi của ghi chú phát hành, ngay cả khi bạn không có mã nguồn Java. Việc sử dụng JDK được chỉ định ở một số vị trí trong tập lệnh bản dựng. Hãy xem phần Phiên bản Java trong bản dựng Android để biết thêm thông tin.

Phân tích nâng cấp

Việc nâng cấp phần phụ thuộc có thể gây ra rủi ro dưới dạng thay đổi về API và hành vi, yêu cầu mới về việc sử dụng, vấn đề bảo mật mới hoặc thậm chí là thay đổi về giấy phép. Ví dụ: bạn có cần:

• Thay đổi mã cho các thay đổi về API?
• Thêm các bước kiểm tra quyền mới?
• Tạo các chương trình kiểm thử bổ sung hoặc sửa đổi các chương trình kiểm thử hiện có cho những thay đổi về hành vi?

Hãy cân nhắc rằng phần phụ thuộc bạn đã nâng cấp đã nâng cấp các phiên bản của phần phụ thuộc của phần phụ thuộc đó. Điều này có thể nhanh chóng dẫn đến một loạt thay đổi lớn.

Nếu bạn sử dụng một công cụ như Renovate hoặc Dependabot để tự động nâng cấp, hãy lưu ý rằng họ không thực hiện bất kỳ phân tích nào cho bạn mà nâng cấp lên phiên bản thư viện mới nhất. Đừng giả định rằng mọi thứ sẽ hoạt động đúng cách sau các loại bản nâng cấp tự động này.

Chìa khoá để nâng cấp thành công là phân tích nâng cấp:

1. Xác định sự khác biệt về phần phụ thuộc trước và sau khi nâng cấp.
2. Kiểm tra từng thay đổi và xác định các rủi ro liên quan.
3. Giảm thiểu rủi ro hoặc chấp nhận hoặc từ chối các thay đổi.

Xác định sự khác biệt về phần phụ thuộc

Bước đầu tiên trong quá trình phân tích bản nâng cấp là xác định cách các phần phụ thuộc thay đổi. Tận dụng tính năng kiểm soát phiên bản (VCS, chẳng hạn như Git) và trình bổ trợ Dependency Guard để nhanh chóng xem các thay đổi. Mục tiêu của bạn là tạo ảnh chụp nhanh trước và sau rồi so sánh chúng.

Thiết lập và tạo đường cơ sở đầu tiên

Trước khi bắt đầu nâng cấp, hãy đảm bảo dự án của bạn được tạo thành công.

Tốt nhất là bạn nên giải quyết nhiều cảnh báo nhất có thể hoặc tạo đường cơ sở để theo dõi những cảnh báo bạn đã nhìn thấy.

• Tìm lỗi mã nguồn: Kiểm tra các cảnh báo tìm lỗi mã nguồn hiện có và tạo đường cơ sở tìm lỗi mã nguồn Android.
• Trình biên dịch Kotlin:
  • Bật -Werror để coi tất cả cảnh báo là lỗi. Xem phần Cách xác định tuỳ chọn.
  • Hãy cân nhắc sử dụng các trình bổ trợ như Kotlin Warning Baseline (Đường cơ sở cảnh báo Kotlin) hoặc Kotlin Warnings Baseline Generator (Trình tạo đường cơ sở cảnh báo Kotlin).
• Các công cụ khác: Nếu bạn sử dụng các công cụ phân tích tĩnh khác (chẳng hạn như Detekt) hỗ trợ tính năng theo dõi cơ sở, hãy thiết lập cơ sở của các công cụ đó.

Các đường cơ sở cảnh báo này giúp bạn dễ dàng xem các cảnh báo mới được đưa ra khi bạn nâng cấp các phần phụ thuộc.

Tạo đường cơ sở phần phụ thuộc bằng cách thiết lập và chạy Dependency Guard. Trong danh mục phiên bản gradle/libs.versions.toml, hãy thêm:

[versions]
dependencyGuard = "0.5.0"

[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }

Sau đó, hãy thêm nội dung sau vào tệp bản dựng của ứng dụng:

Kotlin

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Groovy

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

Cấu hình releaseRuntimeClasspath có thể là mục tiêu, nhưng nếu bạn muốn sử dụng một cấu hình khác, hãy chạy ./gradlew dependencyGuard mà không có cấu hình được liệt kê trong tệp bản dựng để xem tất cả cấu hình có sẵn.

Sau khi thiết lập, hãy chạy ./gradlew dependencyGuard để tạo báo cáo trong app/dependencies/releaseRuntimeClasspath.txt. Đây là báo cáo cơ sở của bạn. Hãy cam kết thay đổi này với hệ thống quản lý phiên bản (VCS) để lưu.

Xin lưu ý rằng Trình bảo vệ phần phụ thuộc chỉ ghi lại danh sách các phần phụ thuộc thư viện. Có các phần phụ thuộc khác trong tệp bản dựng, chẳng hạn như phiên bản SDK Android và JDK. Việc cam kết với VCS trước khi thay đổi phần phụ thuộc cũng cho phép VCS diff làm nổi bật những thay đổi đó.

Nâng cấp và so sánh với đường cơ sở

Sau khi bạn có đường cơ sở, hãy nâng cấp các phần phụ thuộc và các thay đổi khác về bản dựng mà bạn muốn kiểm thử. Đừng nâng cấp mã nguồn hoặc tài nguyên tại thời điểm này.

Chạy ./gradlew lint để xem các lỗi hoặc cảnh báo mới về tìm lỗi mã nguồn. Giải quyết mọi vấn đề quan trọng rồi cập nhật đường cơ sở cảnh báo bằng cách chạy ./gradlew lint -Dlint.baselines.continue=true. Nếu bạn đã sử dụng các công cụ khác để ghi lại đường cơ sở cảnh báo, chẳng hạn như Đường cơ sở cảnh báo Kotlin hoặc Trình tạo đường cơ sở cảnh báo Kotlin, hãy giải quyết các cảnh báo mới và cập nhật đường cơ sở của chúng.

Chạy ./gradlew dependencyGuard để cập nhật báo cáo cơ sở. Sau đó, hãy chạy lệnh so sánh VCS để xem các thay đổi không phải thư viện. Có thể bạn sẽ thấy nhiều bản nâng cấp thư viện hơn bạn nghĩ.

Phân tích rủi ro

Sau khi bạn biết điều gì đã thay đổi, hãy xem xét những rủi ro có thể xảy ra của mỗi thư viện được nâng cấp. Điều này giúp bạn tập trung vào việc kiểm thử hoặc điều tra kỹ hơn về các thay đổi. Xác định một nhóm rủi ro để phân tích cho dự án của bạn nhằm đảm bảo tính nhất quán của quá trình phân tích.

Một số điều cần cân nhắc:

Tăng phiên bản lớn	Số phiên bản chính có thay đổi không? Trong phiên bản ngữ nghĩa, số đầu tiên được gọi là phiên bản chính. Ví dụ: nếu phiên bản của một thư viện được nâng cấp từ 1.2.3 lên 2.0.1, thì phiên bản chính đã thay đổi. Thông báo này thường cho biết nhà phát triển thư viện đã thực hiện các thay đổi không tương thích giữa các phiên bản, chẳng hạn như xoá hoặc thay đổi một số phần của API. Khi thấy thông báo này, hãy chú ý đến các thư viện bị ảnh hưởng khi xem xét bất kỳ điều gì sau đây. Nếu mã của bạn sử dụng bất kỳ API thử nghiệm nào (thường yêu cầu bạn chọn sử dụng chú thích hoặc thông số kỹ thuật của tệp bản dựng), thì ngay cả những thay đổi nhỏ hoặc thay đổi phiên bản bản vá, chẳng hạn như nâng cấp từ 1.2.3 lên 1.3.1 hoặc 1.2.3 lên 1.2.5, cũng có thể gây ra thêm rủi ro.
API không ổn định	Một số bản phát hành thư viện có thể bao gồm các API không ổn định. Đây thường là những API đang trong quá trình phát triển hoặc phụ thuộc vào một API không ổn định khác. Mặc dù thường chỉ giới hạn ở các bản xem trước, chẳng hạn như bản phát hành alpha, bản phát hành dành cho nhà phát triển hoặc bản phát hành thử nghiệm, nhưng một số thư viện có chứa các API được đánh dấu là thử nghiệm hoặc không ổn định. Nếu có thể, hãy tránh sử dụng các API như vậy. Nếu bạn cần sử dụng chúng, hãy nhớ ghi lại quá trình sử dụng của bạn và chú ý đến những thay đổi hoặc bị xoá trong các bản phát hành sau này.
Hành vi động	Một số thư viện hoạt động theo cách khác nhau dựa trên các yếu tố bên ngoài. Ví dụ: một thư viện giao tiếp với máy chủ phụ thuộc vào các thay đổi trong máy chủ đó. Thư viện có cần khớp với một phiên bản máy chủ cụ thể không? Thư viện có thể kết nối với nhiều phiên bản máy chủ không? Một số yếu tố bên ngoài khác có ảnh hưởng đến hoạt động bình thường của thư viện không?
Hợp nhất tệp kê khai	Các thư viện được phát hành dưới dạng Tệp lưu trữ Android (AAR) có thể chứa các tài nguyên và tệp kê khai được hợp nhất vào ứng dụng của bạn. Các tệp này có thể thêm các quyền mới và các thành phần Android, chẳng hạn như hoạt động hoặc broadcast receiver, chạy gián tiếp.
Thông tin cập nhật về thời gian chạy	Một số thư viện sử dụng các tính năng có thể được cập nhật bên ngoài phạm vi kiểm soát của ứng dụng. Thư viện có thể sử dụng Dịch vụ Play, được nâng cấp độc lập với SDK Android. Các thư viện khác có thể liên kết với các dịch vụ trong các ứng dụng bên ngoài được cập nhật độc lập (thường sử dụng AIDL).
Bạn sẽ bỏ qua bao nhiêu phiên bản?	Bạn càng chờ lâu để nâng cấp thư viện thì càng có nhiều rủi ro tiềm ẩn. Nếu bạn thấy một phiên bản thay đổi đáng kể, chẳng hạn như 1.2.3 thành 1.34.5, hãy chú ý nhiều hơn đến thư viện này.
Hướng dẫn di chuyển	Kiểm tra xem thư viện có hướng dẫn di chuyển hay không. Điều này có thể làm giảm đáng kể việc phân tích rủi ro và lập kế hoạch giảm thiểu rủi ro. Xin lưu ý rằng sự hiện diện của hướng dẫn như vậy là một chỉ báo tốt cho thấy nhà phát triển đã tập trung vào khả năng tương thích và cân nhắc việc giảm thiểu việc nâng cấp của bạn.
Ghi chú phát hành	Xem ghi chú phát hành (nếu được cung cấp) cho từng thư viện đã thay đổi. Tìm các dấu hiệu về thay đổi có thể gây lỗi hoặc các yêu cầu mới, chẳng hạn như quyền được thêm.
README	Một số tệp README cho thư viện sẽ ghi chú các rủi ro tiềm ẩn, đặc biệt là nếu thư viện không cung cấp ghi chú phát hành. Tìm _các vấn đề đã biết_, đặc biệt là các vấn đề bảo mật đã biết.
Kiểm tra các lỗ hổng đã biết	Chỉ mục SDK của Play theo dõi các lỗ hổng bảo mật của nhiều SDK phổ biến. Play Console sẽ báo cáo xem bạn có sử dụng một trong các SDK được liệt kê có lỗ hổng đã biết hay không. Khi chỉnh sửa tệp bản dựng trong Android Studio, IDE sẽ kiểm tra chỉ mục SDK và gắn cờ việc sử dụng các phiên bản thư viện dễ bị tấn công. Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) duy trì một Cơ sở dữ liệu lỗ hổng quốc gia (NVD) lớn. Trình bổ trợ Gradle Dependency Check (Kiểm tra phần phụ thuộc) sẽ kiểm tra các phần phụ thuộc bạn đã sử dụng dựa trên NVD. Để sử dụng tính năng Kiểm tra phần phụ thuộc, hãy yêu cầu một khoá API NVD, thiết lập trình bổ trợ Gradle rồi chạy ./gradlew dependencyCheckAnalyze. Xin lưu ý rằng quá trình này có thể mất nhiều thời gian để chạy.
Xung đột phiên bản	Các phiên bản có phân giải như mong đợi không? Tìm xung đột, đặc biệt là sự khác biệt lớn về phiên bản. Hãy xem phần Xử lý phần phụ thuộc Gradle để biết thông tin chi tiết về cách tìm xung đột. Cụ thể, hãy tìm kiếm -> trong báo cáo ./gradlew app:dependencies. Khi có thể, hãy làm việc với tác giả của phần phụ thuộc để giải quyết xung đột giữa các phần phụ thuộc đó. Nếu công ty của bạn cho phép, hãy đóng góp các thay đổi cho thư viện (chuyển lên trên) để giúp cải thiện khả năng tương thích của thư viện.
Kiểm tra giấy phép	Tìm những thay đổi về giấy phép khi nâng cấp thư viện. Bản thân thư viện có thể thay đổi thành giấy phép không còn tương thích với ứng dụng hoặc thư viện của bạn. Các phần phụ thuộc bắc cầu mới cũng có thể đưa ra các giấy phép không tương thích. Hãy xem phần Xác thực giấy phép để biết thông tin chi tiết về cách kiểm tra bộ giấy phép hiện tại trên các phần phụ thuộc của bạn.
Bảo trì và rủi ro về chất lượng	Đối với thư viện có kho lưu trữ công khai: Có bao nhiêu người đóng góp đang duy trì thư viện này? Lần nâng cấp gần đây nhất là khi nào và thư viện thay đổi thường xuyên như thế nào? Danh sách tồn đọng vấn đề (nếu có) trông như thế nào? Đọc qua để xác định các vấn đề tiềm ẩn và món nợ kỹ thuật của thư viện. Các bài kiểm thử đơn vị có bao gồm thư viện hiệu quả như thế nào? Có mẫu chống đối nào đã biết trong cơ sở mã không? Thư viện có được ghi nhận đầy đủ không? Có nhiều nhận xét _fixme_ trong cơ sở mã không?
Nguồn mở so với nguồn đóng	Nếu thư viện có nguồn mở, bạn sẽ dễ dàng gỡ lỗi các vấn đề hơn so với thư viện có nguồn đóng, cho dù vấn đề nằm trong mã của bạn hay mã thư viện. Giảm thiểu các phần phụ thuộc nguồn đóng và giám sát thêm trong quá trình đánh giá. Có giải pháp thay thế phù hợp với trường hợp sử dụng của bạn không? Thư viện nguồn đóng có những thoả thuận mức độ cung cấp dịch vụ nào? Nếu bạn chọn sử dụng phần phụ thuộc nguồn đóng, hãy chuẩn bị viết thêm các trường hợp kiểm thử để giúp hạn chế rủi ro.

Chạy bản dựng

Tạo dự án. Tìm lỗi hoặc cảnh báo mới. Nếu bạn có thể xác định thư viện nào đang gây ra lỗi, hãy lưu ý rằng đó là rủi ro khi nâng cấp thư viện đó.

Nếu bạn thấy bất kỳ cảnh báo khấu hao mới nào, hãy thêm các cảnh báo đó dưới dạng rủi ro cụ thể cho thư viện tạo ra các cảnh báo đó. Bạn có thể xoá các tệp này trong các bản phát hành sau này. Nếu bạn muốn tiếp tục sử dụng thư viện đó, hãy dành thời gian chuyển đổi từ việc sử dụng các API không dùng nữa sang các API thay thế hoặc ghi chú các API không dùng nữa để theo dõi các hàm đó và xem liệu sau này chúng có bị xoá hay không.

Sử dụng công cụ tìm lỗi mã nguồn để phát hiện vấn đề về API

Tìm lỗi mã nguồn Android có thể phát hiện nhiều vấn đề trong ứng dụng của bạn, bao gồm cả một số vấn đề là kết quả của việc thay đổi phiên bản phần phụ thuộc hoặc SDK Android. Ví dụ: nếu bạn nâng cấp compileSdk và sử dụng các API mới, công cụ tìm lỗi mã nguồn sẽ báo cáo những API không có trong các phiên bản SDK trước.

Công cụ tìm lỗi mã nguồn chạy trong trình chỉnh sửa Android Studio, báo cáo các vấn đề khi bạn thực hiện thay đổi. Tuy nhiên, công cụ này thường không chạy trong bản dựng của bạn trong Studio hoặc khi bạn chạy bản dựng dòng lệnh, trừ phi bạn sử dụng mục tiêu build hoặc lint.

Nếu bạn sử dụng tính năng Tích hợp liên tục (CI), hãy chạy gradlew build hoặc gradlew lint trong các bản dựng CI (hoặc ít nhất là trên các bản dựng hằng đêm) để phát hiện những loại lỗi này.

Nếu bạn không sử dụng CI, hãy nhớ ít nhất thỉnh thoảng chạy gradlew lint.

Lưu ý: Các quy tắc tìm lỗi mã nguồn cấp SDK của Android và chung được phân phối bằng AGP, còn các quy tắc dành riêng cho thư viện được đóng gói cùng với thư viện của chúng. Hãy cập nhật AGP và các phần phụ thuộc thư viện của bạn càng mới càng tốt để đảm bảo rằng các quy tắc tìm lỗi mã nguồn mới nhất được áp dụng cho mã của bạn. Điều này đặc biệt quan trọng đối với các quy tắc tìm lỗi mã nguồn mới đã được thêm hoặc nâng cấp cho một phiên bản SDK Android mới.

Hãy đặc biệt chú ý đến các lỗi và cảnh báo tìm lỗi mã nguồn. Một số thư viện được vận chuyển cùng với các tính năng kiểm tra tìm lỗi mã nguồn riêng, giúp đảm bảo việc sử dụng API đúng cách. Một số phiên bản mới của thư viện sẽ bao gồm các cảnh báo và lỗi mới về tìm lỗi mã nguồn, dẫn đến các báo cáo mới khi bạn tạo bản dựng.

Giảm thiểu rủi ro

Sau khi xác định các rủi ro khi nâng cấp, hãy quyết định cách bạn muốn giảm thiểu các rủi ro đó:

• Chấp nhận một số rủi ro như hiện tại. Một số rủi ro ở mức đủ thấp để có thể chấp nhận được, đặc biệt là khi thời gian và tài nguyên nâng cấp bị hạn chế.
• Từ chối ngay một số rủi ro. Một số bản nâng cấp có thể quá rủi ro, đặc biệt là khi bạn có ít thời gian hoặc tài nguyên để giảm thiểu rủi ro tại thời điểm này. Nếu bạn cần phân loại, hãy tập trung vào các bản nâng cấp cần thiết cho các lỗi bạn gặp phải hoặc các tính năng mới mà bạn cần.
• Giảm thiểu các rủi ro còn lại
  • Hãy cân nhắc việc phân chia các bản nâng cấp thành các nhóm thay đổi nhỏ, độc lập. Điều này giúp giảm rủi ro tổng thể và cho phép khôi phục một phần.
  • Điều tra chi tiết các thay đổi.
  • Kiểm thử ứng dụng để kiểm tra những thay đổi không mong muốn. Thêm các chương trình kiểm thử mới cần thiết để tự tin nâng cấp.
  • Xem nguồn (nếu có) khi phát hiện thấy nội dung đáng ngờ.
  • Thực hiện các thay đổi bắt buộc trong nguồn hoặc bản dựng.

Ghi lại các quyết định của bạn. Nếu rủi ro từ việc nâng cấp trở thành vấn đề khi chạy ứng dụng, thì tài liệu về việc phân tích rủi ro có thể giảm thiểu việc phân tích lỗi cần thiết.

Xác thực giấy phép

Nhà phát triển thư viện cấp phép cho bạn sử dụng thư viện. Bạn phải tuân thủ các điều khoản của giấy phép thì mới có thể sử dụng thư viện. Một số giấy phép có nhiều quyền tuỳ ý, thường chỉ yêu cầu ghi nguồn thư viện và hiển thị nội dung giấy phép của thư viện cho người dùng cuối. Một số được coi là virus; nếu sử dụng các thư viện đó, bạn phải áp dụng cùng một giấy phép cho ứng dụng hoặc thư viện của mình.

Giấy phép có thể thay đổi theo bất kỳ bản phát hành nào. Bất cứ khi nào nâng cấp, bạn nên xác minh rằng các phần phụ thuộc bạn đang sử dụng được cấp phép theo cách tương thích với ứng dụng hoặc thư viện của bạn.

Nếu giấy phép không tương thích (hoặc đã thay đổi để không còn tương thích), bạn không thể sử dụng phiên bản thư viện đó. Bạn có thể:

• Hãy liên hệ với chủ sở hữu thư viện và yêu cầu tiếp tục cấp giấy phép hiện có hoặc cấp giấy phép kép để tiếp tục cho phép giấy phép cũ.
• Hãy làm việc với nhóm pháp lý của bạn để xác định xem bạn có thể thay đổi giấy phép để phù hợp hay không.
• Tìm một thư viện khác có giấy phép tương thích và sửa đổi ứng dụng của bạn nếu cần.
• Phát triển nhánh phiên bản tương thích mới nhất của thư viện (nếu giấy phép đó cho phép các dẫn xuất và các thay đổi không có hiệu lực hồi tố) rồi thực hiện các thay đổi của riêng bạn.