Mengupgrade versi dependensi

Mengupgrade dependensi akan memberi Anda akses ke fitur terbaru, perbaikan bug, dan peningkatan. Untuk mengupgrade dependensi, Anda perlu memahami cara Gradle me-resolve versi yang Anda minta, risiko yang terkait, dan langkah-langkah yang dapat Anda lakukan untuk memitigasi risiko tersebut.

Catatan: Pengujian aplikasi yang baik adalah kunci untuk memastikan upgrade tidak merusak build atau aplikasi dengan cara yang tidak terduga.

Pertimbangkan strategi upgrade Anda

Langkah terpenting untuk setiap upgrade adalah analisis risiko. Tentukan seberapa nyaman Anda dengan setiap dependensi yang Anda upgrade. Ada banyak pertimbangan saat menentukan strategi upgrade, termasuk:

Mem-build library	Apakah Anda mem-build aplikasi yang didownload dan dijalankan pengguna di perangkat? Atau apakah Anda membangun library untuk membantu developer lain membangun aplikasi mereka? Jika Anda mem-build aplikasi, fokus Anda harus menjaga aplikasi tetap terbaru dan stabil. Jika Anda mem-build library, fokus Anda harus pada aplikasi developer lain. Upgrade Anda akan memengaruhi konsumen. Jika Anda mengupgrade salah satu dependensi, versi tersebut akan menjadi kandidat untuk resolusi dependensi Gradle, yang mungkin merusak penggunaan dependensi tersebut oleh aplikasi. Pertama - minimalkan dependensi library Anda jika memungkinkan. Makin sedikit dependensi yang Anda miliki, makin rendah dampaknya pada resolusi dependensi konsumen. Pastikan untuk mengikuti versi semantik untuk membantu menunjukkan jenis perubahan yang Anda buat. Misalnya, AndroidX mengikuti pembuatan versi semantik dan menambahkan skema pembuatan versi pra-rilis. Coba hindari upgrade versi major untuk menghindari kerusakan pada konsumen. Pertimbangkan untuk membuat kandidat rilis (RC) library Anda agar dapat diuji lebih awal oleh pengguna. Lihat Panduan kompatibilitas mundur untuk penulis library untuk mengetahui detail tentang cara menjaga kompatibilitas Antarmuka Biner Aplikasi (ABI) library Anda. Gunakan alat dan pengujian integrasi seperti Validator kompatibilitas biner untuk memastikan perubahan ABI Anda cocok dengan perubahan versi yang diinginkan. Jika Anda merilis perbaikan di patch ke versi library yang lebih rendah, konsumen tidak perlu mengupgrade library ke versi major atau minor berikutnya, kecuali jika mereka menginginkan fitur baru. Hindari mengupgrade dependensi transitif dalam upgrade ini. Jika upgrade library memerlukan perubahan yang dapat menyebabkan gangguan yang mungkin sangat menyulitkan konsumen, sebaiknya rilis sebagai artefak baru sehingga versi lama dan baru dapat beroperasi berdampingan dan memungkinkan peluncuran yang lebih bertahap. Catatan: Jika upgrade ke salah satu dependensi Anda berisi perubahan API utama, sebaiknya upgrade dependensi tersebut dalam rilis major atau minor dan lakukan perubahan yang diperlukan. Jika tidak, pengguna library Anda mungkin akan melakukannya, sehingga menyebabkan inkompatibilitas antara library Anda dan dependensi tersebut. Hal ini mungkin berlaku meskipun tidak ada perubahan pada library Anda. Anda dapat merilis versi baru hanya untuk mengupgrade dependensi tersebut.
Siklus rilis	Seberapa sering Anda merilis aplikasi atau library? Siklus pengembangan dan rilis yang lebih singkat Lebih cepat untuk mengupgrade. Anda dapat dengan cepat tertinggal. Upgrade kecil yang sering dilakukan dapat meringankan beban kerja. Jika upgrade library menjadi bermasalah, Anda dapat melakukan rollback upgrade tersebut dengan lebih cepat. Alat seperti Dependabot dan Renovate mengurangi beban kerja, tetapi pastikan untuk menganalisis hasilnya guna memeriksa risiko. Siklus pengembangan dan rilis yang lebih lama Masih ada waktu untuk membuat dan menguji upgrade. Versi dependensi yang lebih baru cenderung dirilis selama siklus Anda. Mengembalikan upgrade dan merilis aplikasi atau library memerlukan waktu lebih lama.
Ikuti perkembangan terbaru fitur-fitur terkini	Apakah Anda lebih suka menggunakan fitur dan API terbaru yang tersedia, atau hanya mengupgrade saat Anda memerlukan fitur atau perbaikan bug? Pertimbangkan konsekuensi dari upgrade yang sering dilakukan. Upgrade di masa mendatang akan lebih mudah (lebih sedikit perubahan yang harus diintegrasikan), tetapi Anda akan lebih sering mengambil risiko upgrade. Menguji upgrade ke versi pra-rilis (alfa, beta, kandidat rilis) library dapat membantu kesiapan saat rilis stabil tersedia.
Dependensi baru	Jika Anda menambahkan dependensi baru, pertimbangkan proses peninjauan yang kuat yang memeriksa library tersebut untuk semua kriteria risiko guna memastikannya telah dievaluasi dengan benar. Jangan izinkan dependensi baru ditambahkan tanpa peninjauan.
Tim khusus	Apakah Anda memiliki tim build khusus? Apakah engineer software Anda mengelola build? Tim khusus sering kali dapat menghabiskan lebih banyak waktu untuk menganalisis risiko upgrade dan menguji versi baru guna memastikan build berfungsi dengan baik sebelum engineer menggunakan versi baru.
Jenis upgrade	Beberapa upgrade lebih penting daripada yang lain. Pikirkan tentang apa yang paling penting bagi Anda. Upgrade alat build, seperti Gradle dan plugin Gradle, biasanya memiliki dampak yang lebih rendah bagi pengguna, dan sebagian besar risikonya bersifat internal untuk build Anda. Build itu sendiri membantu memvalidasi perubahan ini. Upgrade library dan SDK lebih sulit divalidasi, dan menimbulkan risiko yang lebih tinggi bagi pengguna Anda. Plugin Android Gradle (AGP) — alat yang digunakan untuk mem-build aplikasi atau library Android Anda. Ini adalah upgrade paling penting yang dapat Anda lakukan, karena sering kali menyertakan atau mengaktifkan peningkatan performa, perbaikan bug, aturan lint baru, dan dukungan untuk versi platform Android baru. Gradle — Anda sering kali perlu mengupgrade Gradle saat mengupgrade AGP atau plugin Gradle lainnya. Plugin Gradle lainnya — Terkadang API plugin Gradle berubah. Saat mengupgrade Gradle, periksa upgrade pada plugin yang Anda gunakan. Kotlin dan Java — Beberapa library dan plugin memerlukan versi minimum Kotlin atau Java, atau Anda ingin memanfaatkan fitur bahasa, API, atau peningkatan performa baru. Platform Android — Play Store memerlukan upgrade Android SDK reguler. Anda harus menguji versi baru Android SDK sesegera mungkin. Beberapa upgrade SDK memerlukan perubahan pada aplikasi Anda, seperti izin baru atau penggunaan API baru. Library — Apakah Anda ingin memprioritaskan library berdasarkan kedekatannya dengan arsitektur Anda secara keseluruhan? Library terkait Platform dan Arsitektur, seperti AndroidX, sering berubah untuk memanfaatkan fitur baru atau membantu memisahkan perubahan di platform. Upgrade library ini setidaknya setiap kali Anda mengupgrade platform Android atau library terkait arsitektur lainnya. Upgrade library lainnya dapat didistribusikan atau ditunda kecuali jika Anda memerlukan fitur baru atau perbaikan bug tertentu. Android Studio — selalu mengupdate Android Studio akan memberi Anda akses ke fitur dan perbaikan bug terbaru di platform dan alat IntelliJ IDEA yang mendasarinya untuk digunakan dengan Android SDK terbaru.
Alat yang tersedia	Ada banyak alat dan plugin yang tersedia untuk membantu upgrade Anda. Alat seperti Dependabot dan Renovate otomatis mengupgrade versi library di build Anda, tetapi pastikan Anda menganalisis hasilnya untuk memeriksa risiko.

Strategi untuk jenis upgrade tertentu

Mengupgrade beberapa jenis dependensi mungkin memiliki efek beruntun, sehingga mengharuskan jenis dependensi lainnya diupgrade. Kita membahas hubungan antara elemen build di Interdependensi alat dan library.

Gambar 1. Bangun hubungan.

Saat mengupgrade setiap jenis komponen, pertimbangkan pengaruh upgrade terhadap komponen lain dalam build.

Plugin Android Gradle (AGP)	Android Studio menyertakan asisten upgrade AGP yang dapat membantu tugas ini. Jika Anda menggunakan asisten atau melakukan upgrade secara manual, pertimbangkan hal berikut: Lihat catatan rilis AGP. Upgrade Gradle setidaknya ke versi yang tercantum. Upgrade Android Studio ke versi yang mendukung versi AGP yang dipilih. Gunakan versi Android Studio dan AGP yang mendukung Android SDK yang ingin Anda gunakan. Periksa kompatibilitas dengan Alat Build SDK, NDK, dan JDK. Jika Anda mengembangkan plugin Gradle (untuk penggunaan internal atau publik) yang memperluas atau menggunakan data dari AGP, periksa apakah Anda perlu mengupgrade plugin. Terkadang AGP menghentikan penggunaan dan kemudian menghapus API, sehingga menyebabkan inkompatibilitas dengan plugin sebelumnya.
Compiler, bahasa, dan runtime Kotlin	Periksa catatan rilis Kotlin untuk mengetahui masalah umum dan inkompatibilitas. Jika Anda menggunakan Jetpack Compose: Jika versi Kotlin baru lebih rendah dari 2.0.0: Cari plugin compiler Compose yang kompatibel. Upgrade kotlinCompilerExtensionVersion di build.gradle.kts modul mana pun tempatnya muncul. Jika versi Kotin baru adalah 2.0.0 atau yang lebih tinggi: Siapkan Plugin Gradle Compose Compiler dengan versi yang sama dengan compiler Kotlin. Jika Anda menggunakan Pemrosesan Simbol Kotlin (KSP), lihat Panduan Memulai KSP untuk penyiapan dan Rilis KSP untuk versi yang tersedia. Perhatikan bahwa Anda harus menggunakan versi KSP yang cocok dengan versi Kotlin. Misalnya, jika menggunakan Kotlin 2.0.21, Anda dapat menggunakan versi plugin KSP apa pun yang dimulai dengan 2.0.21, seperti 2.0.21-1.0.25. Anda biasanya tidak perlu mengupgrade prosesor KSP (seperti compiler Room, yang muncul sebagai dependensi ksp dalam file build); plugin KSP menyederhanakan sebagian besar API compiler, dan API KSP yang digunakan oleh prosesor sudah stabil. Upgrade semua Plugin Compiler Kotlin lain yang Anda gunakan. API Plugin Compiler Kotlin sering berubah di antara rilis, dan plugin harus menggunakan API yang kompatibel. Jika plugin tercantum di Plugin compiler, Anda harus menggunakan versi yang sama dengan compiler Kotlin. Untuk plugin kompilasi lainnya, periksa dokumentasi untuk mengetahui pemetaan yang sesuai. Perhatikan bahwa plugin compiler yang tidak dikelola bersama compiler Kotlin itu sendiri sering mengalami penundaan rilis saat menunggu API plugin compiler stabil. Sebelum mengupgrade Kotlin, pastikan bahwa semua plugin compiler yang Anda gunakan memiliki upgrade yang cocok. Terakhir, dalam beberapa kasus, bahasa Kotlin berubah, sehingga Anda harus mengupdate kode. Hal ini paling sering terjadi jika Anda mencoba fitur eksperimental. Jika kode Anda tidak dibangun dengan benar setelah mengupgrade compiler Kotlin, periksa perubahan bahasa atau kerusakan library runtime di catatan rilis Kotlin.
Plugin Compiler Kotlin	Jika Anda perlu mengupgrade plugin compiler Kotlin, upgrade ke versi Kotlin yang cocok yang digunakan. Sebagian besar plugin compiler Kotlin menggunakan versi yang sama dengan compiler Kotlin, atau dimulai dengan versi compiler Kotlin yang diperlukan. Misalnya, jika versi plugin adalah 2.0.21-1.0.25, Anda harus menggunakan compiler Kotlin versi 2.0.21. Mengubah versi compiler Kotlin terkadang memerlukan perubahan lain.
Library	Library adalah dependensi yang paling sering diupgrade dalam build Anda. Anda akan melihat upgrade yang tersedia di editor Android Studio, atau jika Anda menggunakan beberapa alat dan plugin dependensi. Beberapa library menentukan compileSdk atau minSdk minimum yang diperlukan untuk menggunakan library. Jika tidak menggunakan minimal compileSdk yang ditentukan, build Anda akan gagal. Namun, minSdk aplikasi Anda akan otomatis ditetapkan ke maksimum dari semua nilai minSdk yang ditentukan dalam dependensi library dan file build. Beberapa library juga menentukan versi Kotlin minimum untuk digunakan. Perbarui versi Kotlin di file build Anda setidaknya ke versi yang ditentukan.
Gradle	Terkadang versi baru Gradle menghentikan penggunaan API yang sudah ada, sehingga API tersebut akan dihapus dalam rilis mendatang. Jika Anda mengembangkan plugin Gradle, upgrade plugin sesegera mungkin, terutama jika plugin tersebut bersifat publik. Beberapa upgrade Gradle memerlukan pencarian versi baru plugin yang Anda gunakan. Perhatikan bahwa plugin ini dapat tertinggal dalam pengembangannya saat mengupgrade plugin agar cocok dengan API plugin Gradle terbaru. Untuk mengupgrade Gradle: Baca catatan rilis untuk versi yang ingin Anda gunakan. Upgrade versi Gradle di gradle/wrapper/gradle-wrapper.properties. Upgrade jar dan skrip wrapper Gradle dengan menjalankan ./gradlew wrapper --gradle-version latest. Upgrade plugin Gradle Anda. Upgrade JDK yang digunakan untuk menjalankan Gradle.
Plugin Gradle	Plugin Gradle yang diupgrade terkadang menggunakan API Gradle baru atau yang diubah, yang pada gilirannya memerlukan upgrade Gradle atau mungkin perubahan pada konfigurasinya di file build Anda. Dalam kedua kasus tersebut, Anda akan melihat peringatan atau error build untuk menunjukkan ketidakcocokan. Setiap kali mengupgrade plugin, upgrade Gradle.
Android SDK	Android Studio menyertakan asisten upgrade Android SDK yang dapat membantu tugas ini. Jika Anda menggunakan asisten atau melakukan upgrade secara manual, pertimbangkan hal berikut: Setiap rilis Android SDK berisi fitur dan API baru, perbaikan bug, dan perubahan perilaku. Play Store mewajibkan Anda mengupdate targetSdk, tetapi sebaiknya update targetSdk lebih awal dari batas waktu untuk memberi Anda lebih banyak waktu guna melakukan perubahan yang diperlukan. Sebelum mengupgrade Android SDK, baca catatan rilis dengan cermat. Perhatikan baik-baik bagian perubahan perilaku, yang meliputi: Izin baru yang harus Anda minta saat penginstalan atau runtime. API yang tidak digunakan lagi dan penggantinya. Perubahan yang dapat menyebabkan gangguan pada API atau perilaku. API Kotlin atau Java baru, yang dapat memengaruhi kode Anda. Bagian perubahan perilaku bisa cukup panjang, tetapi perhatikan dengan cermat karena sering kali berisi perubahan penting yang perlu Anda buat pada aplikasi. Anda harus mengupgrade targetSdk untuk memenuhi persyaratan Play Store. Mengupgrade compileSdk bersifat opsional, sehingga Anda memiliki akses ke API baru. Perhatikan bahwa beberapa library, seperti AndroidX, menyertakan persyaratan compileSdk minimum. Untuk memanfaatkan fitur SDK baru selama pengembangan dan memastikan kompatibilitas selama build, upgrade plugin Android Gradle (AGP) dan Android Studio. Ini termasuk alat baru dan yang ditingkatkan untuk SDK baru. Lihat Versi minimum alat untuk level API Android. Saat mengupgrade Android SDK, upgrade library AndroidX yang Anda gunakan. AndroidX sering menggunakan API baru dan yang telah diupdate untuk kompatibilitas dan performa yang lebih baik di seluruh versi Android SDK.
Android Studio	Anda biasanya dapat mengupgrade Android Studio kapan saja. Anda mungkin melihat pesan yang meminta Anda untuk mengupgrade AGP atau mengupgrade Android SDK. Upgrade ini sangat direkomendasikan, tetapi tidak wajib. Jika nanti Anda ingin menggunakan Android Studio untuk mengupgrade AGP atau Android SDK, Anda dapat menemukan opsi ini di menu Tools: AGP Upgrade Assistant… Asisten Upgrade Android SDK…
Java	Jika memiliki kode sumber Java di aplikasi Android, Anda mungkin perlu memanfaatkan API Java yang lebih baru. Setiap versi Android SDK mendukung subkumpulan API Java dan fitur bahasa. AGP menyediakan kompatibilitas untuk versi Android SDK yang lebih rendah menggunakan proses yang disebut desugaring. Catatan rilis Android SDK menentukan level Java yang didukung dan potensi masalah. Beberapa masalah ini juga dapat memengaruhi kode sumber Kotlin, karena Kotlin memiliki akses ke Java API yang sama. Pastikan untuk memperhatikan bagian JDK API yang muncul di bagian perubahan perilaku dalam catatan rilis, meskipun Anda tidak memiliki kode sumber Java. Penggunaan JDK ditentukan di beberapa tempat dalam skrip build Anda. Lihat Versi Java di build Android untuk informasi selengkapnya.

Analisis upgrade

Mengupgrade dependensi dapat menimbulkan risiko dalam bentuk perubahan API dan perilaku, persyaratan baru untuk penggunaan, masalah keamanan baru, atau bahkan perubahan lisensi. Misalnya, apakah Anda perlu:

• Ubah kode untuk perubahan API?
• Menambahkan pemeriksaan izin baru?
• Buat pengujian tambahan atau ubah pengujian yang ada untuk perubahan perilaku?

Pertimbangkan bahwa dependensi yang telah Anda upgrade telah mengupgrade versi dependensi -nya. Hal ini dapat dengan cepat menjadi kumpulan perubahan yang masif.

Jika Anda menggunakan alat seperti Renovate atau Dependabot untuk mengotomatiskan upgrade, perhatikan bahwa alat tersebut tidak melakukan analisis apa pun untuk Anda; alat tersebut mengupgrade ke versi library terbaru. Jangan berasumsi bahwa semuanya akan berfungsi dengan baik setelah jenis upgrade otomatis ini.

Kunci agar upgrade berhasil adalah analisis upgrade:

1. Tentukan perbedaan dependensi sebelum dan sesudah upgrade.
2. Memeriksa setiap perubahan dan menentukan risiko yang ada.
3. Mitigasi risiko, atau setujui atau tolak perubahan.

Menentukan perbedaan dependensi

Langkah pertama dalam analisis upgrade adalah menentukan perubahan dependensi Anda. Manfaatkan kontrol versi (VCS, seperti Git) dan plugin Dependency Guard untuk melihat perubahan dengan cepat. Tujuan Anda adalah membuat snapshot sebelum dan sesudah serta membandingkannya.

Menyiapkan dan membuat dasar pengukuran pertama

Sebelum memulai upgrade, pastikan project Anda berhasil dibuat.

Idealnya, selesaikan sebanyak mungkin peringatan, atau buat dasar pengukuran untuk melacak peringatan yang telah Anda lihat.

• Lint: Periksa peringatan lint yang ada dan buat dasar pengukuran lint Android.
• Compiler Kotlin:
  • Mengaktifkan -Werror untuk memperlakukan semua peringatan sebagai error. Lihat Cara menentukan opsi.
  • Pertimbangkan untuk menggunakan plugin seperti Kotlin Warning Baseline atau Kotlin Warnings Baseline Generator.
• Alat lainnya: Jika Anda menggunakan alat analisis statis lainnya (seperti Detekt) yang mendukung pelacakan dasar pengukuran, siapkan dasar pengukurannya.

Dasar pengukuran peringatan ini memudahkan Anda melihat peringatan baru yang diperkenalkan saat mengupgrade dependensi.

Buat dasar pengukuran dependensi dengan menyiapkan dan menjalankan Dependency Guard. Di katalog versi gradle/libs.versions.toml, tambahkan:

[versions]
dependencyGuard = "0.5.0"

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

Lalu tambahkan kode berikut ke file build aplikasi Anda:

Kotlin

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

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Groovy

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

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

Konfigurasi releaseRuntimeClasspath kemungkinan merupakan target, tetapi jika Anda ingin menggunakan konfigurasi berbeda, jalankan ./gradlew dependencyGuard tanpa konfigurasi yang tercantum dalam file build untuk melihat semua konfigurasi yang tersedia.

Setelah penyiapan, jalankan ./gradlew dependencyGuard untuk membuat laporan di app/dependencies/releaseRuntimeClasspath.txt. Ini adalah laporan dasar pengukuran Anda. Lakukan commit ke sistem kontrol versi (VCS) untuk menyimpannya.

Perlu diingat bahwa Dependency Guard hanya mengambil daftar dependensi library. Ada dependensi lain dalam file build Anda, seperti versi Android SDK dan JDK. Melakukan commit ke VCS sebelum perubahan dependensi memungkinkan diff VCS juga menandai perubahan tersebut.

Mengupgrade dan membandingkan dengan dasar pengukuran

Setelah Anda memiliki dasar pengukuran, upgrade dependensi dan perubahan build lain yang ingin Anda uji. Jangan upgrade kode sumber atau resource Anda pada tahap ini.

Jalankan ./gradlew lint untuk melihat peringatan atau error lint baru. Atasi masalah penting, lalu perbarui dasar pengukuran peringatan dengan menjalankan ./gradlew lint -Dlint.baselines.continue=true. Jika Anda telah menggunakan alat lain untuk mengambil dasar pengukuran peringatan, seperti Kotlin Warning Baseline atau Kotlin Warnings Baseline Generator, tangani peringatan baru dan perbarui dasar pengukurannya juga.

Jalankan ./gradlew dependencyGuard untuk memperbarui laporan dasar pengukuran Anda. Kemudian, jalankan diff VCS untuk melihat perubahan non-library. Update ini kemungkinan akan menyertakan lebih banyak upgrade library daripada yang Anda perkirakan.

Menganalisis risiko

Setelah mengetahui perubahannya, pertimbangkan kemungkinan risiko dari setiap library yang diupgrade. Hal ini membantu memfokuskan pengujian atau investigasi perubahan yang lebih mendalam. Tentukan serangkaian risiko yang harus dianalisis di proyek Anda untuk memastikan analisis yang konsisten.

Beberapa pertimbangan:

Peningkatan versi utama	Apakah nomor versi utama berubah? Dalam pembuatan versi semantik, angka pertama dikenal sebagai versi utama. Misalnya, jika versi library diupgrade dari 1.2.3 menjadi 2.0.1, versi utamanya telah berubah. Hal ini biasanya merupakan indikasi bahwa developer library telah membuat perubahan yang tidak kompatibel antar-versi, seperti menghapus atau mengubah bagian API. Jika Anda melihat hal ini, perhatikan dengan cermat library yang terpengaruh saat melihat salah satu pertimbangan berikut. Jika kode Anda menggunakan API eksperimental (yang sering kali mengharuskan Anda ikut serta menggunakan anotasi atau spesifikasi file build), bahkan perubahan versi kecil atau patch, seperti mengupgrade dari 1.2.3 ke 1.3.1 atau 1.2.3 ke 1.2.5, dapat menimbulkan risiko tambahan.
API Tidak Stabil	Beberapa rilis library mungkin menyertakan API yang tidak stabil. API ini biasanya merupakan API yang sedang dalam proses atau bergantung pada API lain yang tidak stabil. Meskipun biasanya terbatas pada pratinjau, seperti rilis alfa, developer, atau eksperimental, beberapa library menyertakan API yang ditandai sebagai eksperimental atau tidak stabil. Jika memungkinkan, hindari API tersebut. Jika Anda perlu menggunakannya, pastikan untuk mencatat penggunaan Anda dan perhatikan perubahan atau penghapusan dalam rilis selanjutnya.
Perilaku dinamis	Beberapa library berperilaku berbeda berdasarkan faktor eksternal. Misalnya, library yang berkomunikasi dengan server bergantung pada perubahan di server tersebut. Apakah library harus cocok dengan versi server tertentu? Dapatkah library terhubung ke versi server yang berbeda? Apakah beberapa faktor eksternal lainnya memengaruhi perilaku library yang benar?
Penggabungan manifes	Library yang dipublikasikan sebagai Android Archives (AAR) dapat berisi resource dan manifes yang digabungkan ke dalam aplikasi Anda. Hal ini dapat menambahkan izin baru dan komponen Android, seperti aktivitas atau penerima siaran, yang berjalan secara tidak langsung.
Update runtime	Beberapa library menggunakan fitur yang bisa diupdate di luar kontrol aplikasi Anda. Library mungkin menggunakan Layanan Play, yang diupgrade secara terpisah dari Android SDK. Library lain mungkin terikat ke layanan di aplikasi eksternal yang diupdate secara independen (sering kali menggunakan AIDL).
Berapa banyak versi yang Anda lewati?	Semakin lama Anda menunggu untuk mengupgrade library, semakin besar potensi risikonya. Jika Anda melihat versi berubah secara signifikan, seperti 1.2.3 menjadi 1.34.5, perhatikan library ini dengan cermat.
Panduan migrasi	Periksa apakah library memiliki panduan migrasi. Hal ini dapat secara signifikan mengurangi analisis risiko dan perencanaan mitigasi Anda. Perhatikan bahwa keberadaan panduan tersebut adalah indikator yang baik bahwa developer telah berfokus pada kompatibilitas dan mempertimbangkan mitigasi upgrade Anda.
Catatan rilis	Lihat catatan rilis (jika tersedia) untuk setiap library yang diubah. Cari indikasi perubahan yang menyebabkan error atau persyaratan baru, seperti izin yang ditambahkan.
README	Beberapa file README untuk library mencatat potensi risiko, terutama jika library tidak memberikan catatan rilis. Cari _masalah umum_, terutama masalah keamanan yang diketahui.
Memeriksa kerentanan yang diketahui	Play SDK Index melacak kerentanan untuk banyak SDK populer. Konsol Play melaporkan apakah Anda menggunakan salah satu SDK yang tercantum yang memiliki kerentanan umum. Saat mengedit file build di Android Studio, IDE akan memeriksa indeks SDK dan menandai penggunaan versi library yang rentan. National Institute of Standards and Technology (NIST) mengelola National Vulnerability Database (NVD) yang besar. Plugin Gradle Pemeriksaan Dependensi memeriksa dependensi yang Anda gunakan terhadap NVD. Untuk menggunakan Dependency Check, minta kunci API NVD, siapkan plugin Gradle, dan jalankan ./gradlew dependencyCheckAnalyze. Perhatikan bahwa proses ini dapat memerlukan waktu yang lama untuk dijalankan.
Versi bertentangan	Apakah versi me-resolve seperti yang diharapkan? Cari konflik, terutama perbedaan versi utama. Lihat Resolusi dependensi Gradle untuk mengetahui detail tentang cara mencari konflik. Secara khusus, telusuri -> dalam laporan ./gradlew app:dependencies. Jika memungkinkan, hubungi penulis dependensi untuk menyelesaikan konflik dependensi mereka. Jika perusahaan Anda mengizinkan, berikan perubahan pada library (upstreaming) untuk membantu meningkatkan kompatibilitas library.
Periksa lisensi	Cari perubahan pada lisensi saat mengupgrade library. Library itu sendiri dapat berubah menjadi lisensi yang tidak lagi kompatibel dengan aplikasi atau library Anda. Dependensi transitif baru juga dapat memperkenalkan lisensi yang tidak kompatibel. Lihat Memvalidasi lisensi untuk mengetahui detail tentang cara memeriksa kumpulan lisensi saat ini di seluruh dependensi Anda.
Risiko pemeliharaan dan kualitas	Untuk library dengan repositori publik: Berapa banyak kontributor yang mengelola library? Kapan upgrade terakhir, dan seberapa sering library berubah? Seperti apa tampilan daftar masalah (jika tersedia)? Baca sekilas untuk mendapatkan gambaran tentang potensi masalah dan utang teknis library. Seberapa baik pengujian unit mencakup library? Apakah ada anti-pola yang diketahui di codebase? Apakah library tersebut didokumentasikan dengan baik? Apakah ada banyak komentar _fixme_ di codebase?
Open source versus closed source	Jika library bersifat open source, akan lebih mudah untuk men-debug masalah daripada dengan closed source, baik masalah tersebut ada dalam kode Anda maupun kode library. Minimalkan dependensi sumber tertutup dan terapkan pemeriksaan tambahan selama evaluasi. Apakah ada alternatif yang baik yang sesuai dengan kasus penggunaan Anda? Perjanjian tingkat layanan apa yang tersedia untuk library dengan sumber tertutup? Jika Anda memilih untuk menggunakan dependensi dengan sumber tertutup, bersiaplah untuk menulis kasus pengujian tambahan guna membantu membatasi risiko.

Menjalankan build

Bangun project Anda. Cari error atau peringatan baru. Jika Anda dapat mengidentifikasi library yang menyebabkan error, perhatikan hal ini sebagai risiko untuk mengupgrade library tersebut.

Jika Anda melihat peringatan depresiasi baru, tambahkan peringatan tersebut sebagai risiko spesifik untuk library yang menghasilkannya. Ini dapat dihapus dalam rilis selanjutnya. Jika Anda ingin terus menggunakan library tersebut, luangkan waktu untuk mengonversi dari penggunaan API yang tidak digunakan lagi ke penggantinya, atau catat penghentian penggunaan untuk memantau fungsi tersebut dan apakah fungsi tersebut dihapus nanti.

Menggunakan lint untuk mendeteksi masalah API

Android lint dapat mendeteksi banyak masalah dalam aplikasi Anda, termasuk beberapa yang merupakan hasil dari perubahan versi dependensi atau Android SDK. Misalnya, jika Anda mengupgrade compileSdk dan menggunakan API barunya, lint akan melaporkan API yang tidak tersedia di versi SDK sebelumnya.

Lint berjalan di editor Android Studio, yang melaporkan masalah saat Anda membuat perubahan. Namun, biasanya tidak dijalankan sebagai bagian dari build di Studio atau saat Anda menjalankan build command line, kecuali jika Anda menggunakan target build atau lint.

Jika Anda menggunakan Continuous Integration (CI), jalankan gradlew build atau gradlew lint selama build CI (atau setidaknya pada build setiap malam) untuk menangkap jenis error ini.

Jika Anda tidak menggunakan CI, pastikan untuk setidaknya sesekali menjalankan gradlew lint.

Catatan: Aturan lint tingkat umum dan Android SDK dikirim dengan AGP, dan aturan khusus library dikemas dengan library-nya. Pastikan AGP dan dependensi library Anda selalu yang terbaru untuk memastikan bahwa aturan lint terbaru diterapkan ke kode Anda. Hal ini sangat penting untuk aturan lint baru yang telah ditambahkan atau diupgrade untuk versi Android SDK baru.

Perhatikan dengan cermat error dan peringatan lint. Beberapa library dikirimkan dengan pemeriksaan lint sendiri, yang membantu memastikan penggunaan API-nya dengan benar. Beberapa versi baru library menyertakan peringatan dan error lint baru, sehingga menghasilkan laporan baru saat Anda mem-build.

Memitigasi risiko

Setelah menentukan risiko upgrade, tentukan cara Anda ingin memitigasinya:

• Terima beberapa risiko apa adanya. Beberapa risiko cukup rendah untuk dapat diterima, terutama jika waktu dan resource upgrade terbatas.
• Menolak beberapa risiko secara langsung. Beberapa upgrade mungkin terasa terlalu berisiko, terutama jika Anda memiliki waktu atau resource terbatas untuk menguranginya pada tahap ini. Jika Anda perlu melakukan pemilahan, fokuslah pada upgrade yang diperlukan untuk bug yang Anda temui atau fitur baru yang Anda perlukan.
• Memitigasi risiko yang tersisa
  • Pertimbangkan untuk mengelompokkan upgrade Anda ke dalam kumpulan perubahan yang lebih kecil dan independen. Hal ini mengurangi risiko secara keseluruhan dan memungkinkan rollback sebagian.
  • Selidiki perubahan secara mendetail.
  • Uji aplikasi Anda untuk memeriksa perubahan yang tidak terduga. Tambahkan pengujian baru jika diperlukan untuk membangun kepercayaan dalam upgrade.
  • Lihat sumbernya (jika tersedia) saat menemukan sesuatu yang dipertanyakan.
  • Lakukan perubahan yang diperlukan pada sumber atau build Anda.

Dokumentasikan keputusan Anda. Jika risiko dari upgrade menjadi masalah saat menjalankan aplikasi, dokumentasi analisis risiko dapat mengurangi analisis error yang diperlukan.

Memvalidasi lisensi

Developer library melisensikan library untuk Anda gunakan. Anda harus mematuhi persyaratan lisensi atau Anda tidak dapat menggunakan library. Beberapa lisensi sangat permisif, sering kali hanya memerlukan atribusi library dan memunculkan teks lisensinya kepada pengguna akhir. Beberapa di antaranya dianggap viral; jika menggunakan library tersebut, Anda harus menerapkan lisensi yang sama ke aplikasi atau library Anda.

Lisensi dapat berubah dengan rilis apa pun. Setiap kali melakukan upgrade, Anda harus memverifikasi bahwa dependensi yang Anda gunakan dilisensikan dengan cara yang kompatibel dengan aplikasi atau library Anda.

Jika lisensi tidak kompatibel (atau telah berubah sehingga tidak lagi kompatibel), Anda tidak dapat menggunakan versi library tersebut. Anda dapat:

• Hubungi pemilik library dan minta perpanjangan lisensi yang ada atau lisensi ganda agar tetap mengizinkan lisensi lama.
• Bekerja samalah dengan tim hukum Anda untuk menentukan apakah Anda dapat mengubah lisensi agar kompatibel.
• Temukan library lain dengan lisensi yang kompatibel dan ubah aplikasi Anda sesuai kebutuhan.
• Buat fork versi library terakhir yang kompatibel (jika lisensi tersebut mengizinkan turunan dan perubahannya tidak bersifat retroaktif) dan buat perubahan Anda sendiri.