Việc nâng cấp các phần phụ thuộc sẽ giúp bạ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 đó.
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 xây dựng một ứng dụng, bạn nên tập trung vào việc cập nhật và duy trì sự ổn định cho ứng dụng. Nếu đang xây dựng một thư viện, bạn nên tập trung vào các ứng dụng của 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ì càng ít ảnh hưởng đến quyền phân giải phần phụ thuộc của người dùng. Hãy nhớ tuân theo quy trình tạo phiên bản ngữ nghĩa để giúp chỉ ra các 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 lược đồ tạo phiên bản trước khi phát hành. Cố gắng tránh nâng cấp phiên bản 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 Nếu việc nâng cấp thư viện của bạn yêu cầu các thay đổi có thể gây khó khăn đặc biệt cho người dùng, hãy cân nhắc phát hành các thay đổi đó dưới dạng một cấu phần phần mềm mới để các phiên bản cũ và mới có thể tồn tại song song và cho phép triển khai 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ủa bạn có thay đổi lớn về API, thì bạn nên nâng cấp phần phụ thuộc đó trong bản phát hành |
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
Chu kỳ phát triển và phát hành dài 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 nghiêm ngặt để kiểm tra thư viện đó theo tất cả các tiêu chí rủi ro nhằm đảm bảo rằng các tiêu chí đó đã đượ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 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 kỹ sư sử dụng các 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 xác thực bản nâng cấp thư viện và SDK khó khăn hơn và có nhiều rủi ro hơn đối với 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ác điểm cải thiện về hiệu suất, bản 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 hoặc cải tiến hiệu suất mới. 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 càng sớm càng tốt. Một số bản nâng cấp SDK yêu cầu bạn 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 với cấu trúc tổng thể của mình không?
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 rủi ro. |
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 ta sẽ thảo luận về mối quan hệ giữa các phần tử bản dựng trong phần Phần phụ thuộc lẫn nhau giữa công cụ và thư viện.
Khi nâng cấp từng loại thành phần, hãy cân nhắc mức độ tác động của quá trình 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: 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 bạn sử dụng Kotlin Symbol Processing (KSP), hãy xem phần Hướng dẫn nhanh về KSP để thiết lập và Bản phát hành KSP để biết các phiên bản hiện có. 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 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 một 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 mọi trình bổ trợ biên dịch khác, hãy kiểm tra tài liệu của trình bổ trợ đó để biết mối liên kết thích 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 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 của bạn thành ít nhất là phiên bản đã 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 trình bổ trợ Gradle, hãy nâng cấp trình bổ trợ càng sớm càng tốt, đặc biệt là nếu trình bổ trợ đó là 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:
|
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 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:
Phần thay đổi về hành vi có thể khá dài, nhưng hãy chú ý 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. Bạn phải nâng cấp Để 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 phần Phiên bản tối thiểu của các công cụ dành cho cấp độ API trên 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 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ụ): |
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 các 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 của SDK Android chỉ định cấp độ Java được hỗ trợ và các vấn đề tiềm ẩn. Một số vấn đề 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 một 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 hoá quá trình nâng cấp, hãy lưu ý rằng các công cụ này không phân tích gì cho bạn; chúng sẽ nâng cấp lên các 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:
- Xác định sự khác biệt về phần phụ thuộc trước và sau khi nâng cấp.
- Kiểm tra từng thay đổi và xác định các rủi ro liên quan.
- 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 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 càng nhiều cảnh báo càng tốt hoặc tạo đường cơ sở để theo dõi những cảnh báo mà bạ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).
- Bật
- 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 đường cơ sở, hãy thiết lập đường 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 thay đổi.
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 những gì đã thay đổi, hãy cân nhắc các rủi ro có thể xảy ra đối với từng thư viện đã 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:
Nâng cấp phiên bản lớn |
Số phiên bản chính có thay đổi không? 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 ở 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 các tính năng này, hãy nhớ ghi lại mức sử dụng và theo dõi các thay đổi hoặc nội dung 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ủ đó.
|
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ó) cho từng thư viện đã thay đổi. Tìm các dấu hiệu cho thấy có 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. |
Tệp 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 khoá API NVD, thiết lập trình bổ trợ Gradle và 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 Khi có thể, hãy làm việc với tác giả của một phần phụ thuộc để giải quyết xung đột 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à |
Đối với thư viện có kho lưu trữ công khai:
|
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à áp dụng thêm quy trình kiểm tra 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 đó. Các API này có thể bị xoá 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ủa compileSdk, thì 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ừ khi 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.
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 có các lỗi và cảnh báo tìm lỗi mã nguồn mới, 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ế.
- Tuyệt đối từ chối 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 làm 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 về những thay đổi.
- Kiểm thử ứng dụng để kiểm tra xem có thay đổi ngoài dự kiến hay không. Thêm các bài kiểm thử mới khi cần để tăng độ tự tin khi 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 rất dễ tính, thường chỉ yêu cầu ghi công thư viện và hiển thị văn bản giấy phép 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 sử dụng giấy phép hiện có hoặc 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 gần đây nhất của thư viện (nếu giấy phép đó cho phép các sản phẩm phái sinh 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.