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.
Pertimbangkan strategi upgrade Anda
Langkah terpenting untuk setiap upgrade adalah analisis risiko. Tentukan seberapa nyaman Anda dengan setiap dependensi yang diupgrade. 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 membuat library untuk membantu developer lain mem-build 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 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 Pertimbangkan untuk membuat kandidat rilis (RC) library Anda agar dapat diuji pengguna lebih awal. 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 Jika upgrade library Anda memerlukan perubahan yang dapat menyebabkan gangguan yang mungkin sangat mengganggu bagi konsumen, pertimbangkan untuk merilisnya sebagai artefak baru sehingga versi lama dan baru dapat 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 |
Siklus rilis |
Seberapa sering Anda merilis aplikasi atau library? Siklus pengembangan dan rilis yang lebih singkat
Siklus pengembangan dan rilis yang 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 untuk memastikan build berfungsi dengan benar sebelum engineer menggunakan versi baru. |
Jenis upgrade |
Beberapa upgrade lebih penting daripada yang lain. Pikirkan mana 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 Android SDK versi baru 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 secara keseluruhan?
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 dalam build Anda, tetapi pastikan untuk menganalisis hasilnya guna memeriksa risiko. |
Strategi untuk jenis upgrade tertentu
Mengupgrade beberapa jenis dependensi mungkin memiliki efek cascading, sehingga jenis dependensi lainnya harus diupgrade. Kita membahas hubungan antara elemen build di Interdependensi alat dan library.
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 tidak lagi menggunakan dan kemudian menghapus API, sehingga menyebabkan inkompatibilitas dengan plugin sebelumnya. |
Kompiler, bahasa, dan runtime Kotlin |
Periksa catatan rilis Kotlin untuk mengetahui masalah umum dan inkompatibilitas. Jika Anda menggunakan Jetpack Compose:
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 plugin KSP versi 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 Upgrade semua Plugin Compiler Kotlin lainnya 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 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 di-build 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 Beberapa library juga menentukan versi Kotlin minimum untuk digunakan. Update versi Kotlin di file build Anda setidaknya ke versi yang ditentukan. |
Gradle |
Terkadang, versi baru Gradle menghentikan penggunaan API yang ada, sehingga menghapus API tersebut 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:
|
Plugin Gradle |
Plugin Gradle yang diupgrade terkadang menggunakan API Gradle baru atau yang diubah, yang pada akhirnya memerlukan upgrade Gradle atau mungkin perubahan pada konfigurasinya dalam 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 Sebelum mengupgrade Android SDK, baca catatan rilis dengan cermat. Perhatikan dengan cermat bagian perubahan perilaku, yang mencakup:
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 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: |
Java |
Jika memiliki kode sumber Java di aplikasi Android, sebaiknya manfaatkan Java API yang lebih baru. Setiap versi Android SDK mendukung subset Java API 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 dalam build Android untuk mengetahui 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:
- Mengubah kode untuk perubahan API?
- Menambahkan pemeriksaan izin baru?
- Membuat pengujian tambahan atau mengubah 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 asumsikan bahwa semuanya akan berfungsi dengan baik setelah jenis upgrade otomatis ini.
Kunci untuk upgrade yang berhasil adalah analisis upgrade:
- Tentukan perbedaan dependensi dari sebelum dan setelah upgrade.
- Periksa setiap perubahan dan tentukan risiko yang terlibat.
- 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 setelah, lalu 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.
- Mengaktifkan
- 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
adalah target yang mungkin, tetapi jika Anda ingin
menggunakan konfigurasi yang 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 memiliki dasar pengukuran, upgrade dependensi dan perubahan build lainnya 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 akan dianalisis untuk project Anda guna memastikan analisis yang konsisten.
Beberapa pertimbangan:
Peningkatan versi utama |
Apakah nomor versi utama berubah? 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 minor 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.
|
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 dapat diupdate di luar kontrol aplikasi Anda. Library mungkin menggunakan Layanan Play, yang diupgrade secara terpisah dari Android SDK. Library lain dapat terikat ke layanan dalam 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 yang 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 ada) 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 dengan kerentanan yang diketahui. 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 |
Konflik versi |
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 Jika memungkinkan, hubungi penulis dependensi untuk menyelesaikan konflik dependensi mereka. Jika perusahaan Anda mengizinkan, kontribusikan perubahan pada library (upstreaming) untuk membantu meningkatkan kompatibilitas library. |
Memeriksa 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 |
Untuk library dengan repositori publik:
|
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
Build project Anda. Cari error atau peringatan baru. Jika Anda dapat mengidentifikasi library yang menyebabkannya, perhatikan bahwa hal tersebut merupakan 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
.
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 mewajibkan atribusi library dan menampilkan 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 mengupgrade, 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.