Saya menghadapi sesuatu proses pekerjaan yang mesti dilakukan tapi cukup malas dan menunda untuk dikerjakan. Agak malas karena ngerjain satu hal tapi harus mengerjakan yang lain juga. Kesalahan di satu hal bisa merembet ke yang lain, begitu juga sebaliknya. Proses ini adalah upgrade API level android dan gradle.
Google kini mewajibkan minimal target API level 35 untuk aplikasi yang ingin dirilis atau di-update di Play Store. Bagi banyak developer yang masih bertahan di API 28, migrasi ini bukan sekadar ganti angka—tapi sebuah proses kompleks yang melibatkan dependency, build system, dan refactor kode besar-besaran.
⚠️ Kenapa Migrasi Ini Mendesak?
- Google Play Policy: Mulai 2025, aplikasi baru dan update harus menargetkan API 35.
- Banyak aplikasi lama masih di API 28, karena tidak pernah di-update sejak 2019–2020.
- Perubahan besar di dependency seperti AndroidX, Jetpack, AGP, dan Gradle membuat migrasi tidak bisa dilakukan parsial.
🔄 Tantangan Migrasi: Dependency yang Saling Menggantung
- Update satu dependency sering memicu error di dependency lain.
- Banyak library yang sudah deprecated atau tidak kompatibel dengan AGP terbaru.
- Proses migrasi bisa jadi loop tak berujung kalau tidak dilakukan secara menyeluruh.
🧱 Komponen yang Harus Diupdate Bersamaan
Untuk migrasi yang sukses, kamu harus menyentuh hampir semua lapisan build system:
🔧 File Terkait Gradle & Build System
| File | Fungsi |
|---|---|
build.gradle (project) | Versi Gradle Plugin & Kotlin DSL |
build.gradle (app) | Target SDK, compile SDK, dependency |
gradle-wrapper.properties | Versi Gradle minimum |
gradle.properties | Flag konfigurasi build |
libs.versions.toml | Manajemen dependency versi modern |
settings.gradle | Konfigurasi modul dan plugin |
AndroidManifest.xml | Target SDK dan permission yang deprecated |
proguard-rules.pro | Penyesuaian obfuscation untuk library baru |
🧹 Refactor Kode: Hadapi Deprecated API
- Banyak API lama (seperti
AsyncTask,getExternalStorageDirectory(), dll) sudah deprecated. - Perlu migrasi ke API modern seperti
WorkManager,Storage Access Framework, danActivityResult API. - Gunakan lint dan IDE inspection untuk mendeteksi deprecated usage.
📦 Strategi Migrasi Modular
- Audit dependency: Cek versi dan kompatibilitas dengan AGP terbaru.
- Update Gradle wrapper dan AGP dulu: Pastikan build system stabil.
- Migrasi ke
libs.versions.toml: Untuk manajemen versi yang lebih maintainable. - Refactor kode deprecated: Gunakan IDE dan dokumentasi resmi.
- Testing bertahap: Gunakan emulator API 35 dan unit test untuk validasi.
🧪 Studi Kasus & Strategi Praktis Migrasi
Untuk menghindari migrasi yang membingungkan dan penuh error, lakukan pendekatan berikut:
- Install Android Studio terbaru Pastikan kamu menggunakan versi terbaru agar kompatibel dengan AGP dan SDK level 35.
- Buat proyek baru dari template bawaan Gunakan template “Empty Compose Activity” atau “Basic Views” untuk melihat struktur modern.
- Review struktur proyek baru Perhatikan versi Gradle, AGP,
libs.versions.toml,settings.gradle, dan konfigurasibuild.gradle. - Bandingkan dengan proyek lama Identifikasi perbedaan versi, plugin, dan struktur dependency.
- Terapkan secara bertahap ke proyek lama Mulai dari update Gradle wrapper, lalu AGP, lalu dependency, lalu refactor kode deprecated.
- Gunakan version catalog (
libs.versions.toml) Ini akan memudahkan tracking versi dan menghindari konflik antar modul.
Dengan pendekatan ini, kamu bisa belajar dari proyek baru yang sudah sesuai standar modern, lalu menerapkannya ke proyek lama secara sistematis dan minim risiko.
✅ Penutup: Migrasi Bukan Sekadar Update, Tapi Rebirth
Migrasi dari API 28 ke 35 bukan hanya soal memenuhi kebijakan Google, tapi juga kesempatan untuk membersihkan, merapikan, dan memodernisasi proyekmu. Dengan pendekatan modular dan dokumentasi yang rapi, kamu bisa mengubah proses yang menyakitkan jadi investasi jangka panjang.
Kediri, 8 Sep 2025