Awalnya, printer Canon G2010 saya terhubung ke jaringan lokal menggunakan print server Wavlink. Di lingkungan Windows, semuanya berjalan mulus: printer terdeteksi otomatis, driver tersedia, dan proses cetak berlangsung cepat tanpa hambatan. Ini solusi ideal untuk rumah atau kantor kecil yang ingin berbagi printer tanpa harus colok langsung ke satu komputer.
2. Masuk Mac: Driver Ada, Tapi Lemot dan Gagal
Masalah muncul saat mencoba mencetak dari MacBook. Saya menambahkan printer lewat System Preferences → Printers & Scanners, memilih driver Canon G2000 series (karena G2010 tidak muncul). Awalnya, printer bisa menerima job dan mulai mencetak. Tapi…
Proses cetak sangat lambat
Sering berhenti di tengah jalan
Kadang hang total dan harus restart printer
Setelah frustrasi berkali-kali, saya cek langsung ke situs resmi Canon — dan ternyata: Canon G2010 memang tidak mendukung macOS secara resmi. Tidak ada driver native, dan solusi workaround tidak stabil.
3. Jalan Alternatif: CUPS + Raspberry Pi
Karena saya sudah punya Raspberry Pi yang standby di jaringan, saya coba eksperimen: jadikan Pi sebagai print server berbasis CUPS (Common Unix Printing System).
Ini adalah grafik pemantauan PLTS hari kedua. Maksudnya hari kedua setelah panel dipasang. Karena sebelum dipasang panel, grafik load DC SCC tidak ada isinya.
Grafik voltase menunjukkan sekitar jam setengah 6 pagi sudah ada arus dari panel ke baterai walaupun nilainya masih sangat kecil. Tapi paling tidak jam segitu voltase sudah mampu masuk ke baterai.
Pada grafik current atau arus pada SCC, terlihat bahwa pada waktu yang sama saat voltase naik, arus juga naik. Nilainya bertahap naik sampai puncaknya sekitar jam 10 sebesar 27-30 Amper. Setelah jam ini, grafik arus naik turun karena cucaca memang sedang mendung. Kemudian mendekati jam 12 siang arus drop ke level sekitar 4 amper seperti jam 6 pagi karena hujan lebat turun. Disini bisa dilihat bahwa walaupun hujan, panel surya masih bisa menghasilkan arus untuk tetap mengisi baterai atau pemakaian langsung.
Kita beralih ke grafik Battery Current, ada dua hal yang bisa kita ceritakan. Yang pertama saat inverter mulai aktif, arus mulai naik sesuai dengan pemakaian. Sebelumnya kosong memang inverter belum aktif dan arus listrik dipenuhi oleh PLN. Kemudian ada kenaikan drastis hingga 15 Amper ini saat AC 1/2 pk dinyalakan.
Baterai PLTS semalem tidak sampai pagi, karena kemarin hujan penuh dari jam 12 siang. Bisa dilihat pada grafik di bawah. Inverter aktif mulai jam sekitar 11 siang kemarin sampai jam 4 pagi tadi.
Pada grafik diatas, pada jam 4 pagi, voltase pada Load AC PLTS, naik tajam dan memiliki karakteristik grafis yang sama dengan voltage pada Load AC PLN. Pada waktu ini inverter mulai mengaktifkan sistem bypass PLN, sehingga sistem kelistrikan menggunakan jaringan PLN karena baterai sudah tidak sanggup menyuplai kebutuhan energi.
Voltase yang dikeluarkan oleh inverter juga terlihat lebih stabil di angka 220 volt. Berbeda dengan voltase dari PLN yang berfluktuasi naik turun. Hal ini bisa dipahami karena memang yang menggunakan listrik PLN ada banyak rumah yang pemakaiannya juga berfluktuasi.
Analogi yang sama juga pada air PDAM, kadang kenceng tapi kadang juga lemah tergantung waktu pemakaian. Pagi hari biasanya air lemah karena banyak yang pakai. Sedangkan malam atau siang hari kencang karena jarang orang yang pakai air.
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, dan ActivityResult 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 konfigurasi build.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.
