Kami pernah merasa heran saat perangkat tiba-tiba cepat habis, padahal tidak banyak yang berubah. Kita ingin tahu apa yang sebenarnya menyedot daya dan kapan kejadian itu terjadi.
Kali ini kita akan menelusuri alat visual yang memetakan event dan metrik pada Android 5.0+ saat perangkat tidak diisi ulang. Tujuan bersama kita: memahami alur dari hulu ke hilir agar bisa mengungkap aplikasi paling boros dalam 24 jam dengan analisis time berbasis timeline.
Kegunaannya nyata bagi pengguna harian dan tim developer. Dari melihat battery usage per app hingga membaca event system yang memicu power spike, kita dapat membuat keputusan yang memperpanjang battery life.
Kursus singkat alurnya: siapkan adb shell, ambil bugreport, jalankan Historian di device lokal, lalu unggah data untuk membaca log dan state perangkat. Metode ini bekerja lintas device dan membantu menghubungkan aktivitas app dengan konsumsi daya secara usage-driven.
Kita akan mendapatkan daftar app teratas yang boros, rentang time saat drain terjadi, serta rekomendasi mitigasi. Siapkan settings dan perangkat agar langkah berikutnya berjalan mulus.
Menyelaraskan Niat: Apa yang Ingin Kita Capai dengan Battery History ADB hari ini
Sebelum menyentuh perintah teknis, kita perlu menyamakan tujuan pengukuran agar hasilnya berguna.
Kita menetapkan sasaran terukur: menemukan app paling boros battery dalam jangka 24 jam, menentukan rentang time saat drain puncak, dan menyiapkan langkah mitigasi berbasis statistics yang bisa segera dipakai developer.
Kami akan memantau usage sebelum dan sesudah skenario uji. Patokan praktis: aplikasi yang menguras lebih dari 15% battery per hour dianggap perlu perbaikan. Alur manual sebelum otomatisasi: reset statistik, jalankan app 1 jam, ambil metrik, lalu ekstrak indikator kunci.
- Mengidentifikasi processes yang memicu drain tiba-tiba.
- Mengukur dampak aktivitas app terhadap cpu dan screen.
- Mengunci kriteria sukses: bukti timeline, angka consumption, rekomendasi perbaikan.
| Metode | Baseline | Target |
|---|---|---|
| Penggunaan per jam | >15% per hour | |
| Window time | Variabel, tidak konsisten | 24 jam konsisten |
| Dokumentasi | Catatan sporadis | Log, screenshot timeline, ringkasan data |
Konsistensi settings, reset statistik, dan pencatatan rapi membuat perbandingan valid. Hasilnya harus actionable bagi user internal dan tim developer agar mitigasi bisa langsung dijalankan.
Prasyarat & Perlengkapan: ADB, USB Debugging, dan Perangkat yang Didukung
Sebelum kita mulai menangkap data, mari pastikan perangkat dan koneksi siap dipakai.
Kita aktifkan Developer Options lalu USB debugging melalui Settings > System > Developer Options agar adb bisa berkomunikasi dengan device. Beberapa model menyembunyikan menu developer; ketuk Build number beberapa kali sampai muncul.
Instal Android SDK Platform Tools sebagai tools utama. Dengan itu, semua adb commands dan shell dapat dijalankan pada Windows, macOS, atau Linux tanpa masalah.
Mengaktifkan Developer Options & USB Debugging
Masuk ke Settings, buka System, lalu aktifkan Developer Options. Hidupkan USB debugging dan terima prompt RSA saat pertama kali menghubungkan device ke komputer.
Menyiapkan Android SDK Platform Tools dan koneksi device
Periksa kabel USB dan izin debugging setiap kali. Simpan bugreport di komputer sesuai nomor versi Android:
- Android 7.0+ : jalankan adb bugreport bugreport.zip
- Android 6.0 ke bawah : jalankan adb bugreport > bugreport.txt
| Metode | Perintah | Catatan |
|---|---|---|
| Ambil bugreport | adb bugreport bugreport.zip | Untuk Android 7.0 ke atas, buat zip agar tools lain bisa membaca files |
| Shell akses | adb shell dumpsys | Gunakan shell untuk melihat status cpu dan screen saat kalibrasi |
| Konfirmasi koneksi | adb devices | Pastikan device muncul dan tidak terblokir oleh RSA prompt |
Siapkan ruang penyimpanan pada komputer untuk artefak pengujian. Pastikan cpu dan screen perangkat tidak overheat, dan atur time mulai uji agar setiap sesi dapat dibandingkan secara apples-to-apples.
Menyiapkan Battery Historian: Opsi Docker vs Build Go
Langkah pertama: tentukan apakah kita pakai container atau membangun dari kode sumber.
Kami merekomendasikan jalur tercepat via Docker untuk tim yang ingin langsung melihat UI dalam hitungan menit. Jalankan perintah berikut untuk memulai container pada port pilihan:
docker run -p <port>:9999 gcr.io/android-battery-historian/stable:3.0 –port 9999
Di Mac/Linux akses http://localhost:<port>. Di Windows pastikan Virtualization aktif dan gunakan IP Docker yang ditampilkan agar device penguji dapat mengunggah file bugreport.
Alternatif: build manual dengan Go
Untuk kontrol penuh, bangun dari sumber. Instal Go 1.8.1+, set GOPATH/GOBIN pada PATH, lalu pasang Git, Python 2.7, dan Java.
Unduh dan susun kode dengan:
go get -d -u github.com/google/battery-historian/…
go run setup.go
go run cmd/battery-historian/battery-historian.go –port 9999
Akses Web UI dan pengaturan jaringan
Gunakan port statis agar tim tidak saling bentrok. Simpan lokasi source di $GOPATH/src/github.com/google/battery-historian untuk memudahkan upgrade dan audit dependency.
| Aspek | Docker | Build Go |
|---|---|---|
| Kecepatan | Mulai dalam minutes | Butuh build & setup |
| Kontrol versi | Sedikit lebih terbatas | Penuh, mudah patch |
| Dependensi | Minimal host | Go, Git, Python2.7, Java |
- Dokumentasikan commands dan lokasi files untuk replikasi environment.
- Tetapkan port dan pastikan server screen tetap aktif selama review agar koneksi tidak terputus.
- Perhatikan spesifikasi mesin; render timeline membutuhkan cukup CPU dan power agar analisis data lancar.
Mengambil Bugreport & Mereset Statistik: Dasar Data yang Bersih
Sebelum merekam sesi, kita pastikan semua log dan statistik dimulai dari kondisi bersih.
Kita mulai dengan membuat file bugreport yang sesuai versi Android agar Historian dapat membaca data. Untuk Android 7.0+ gunakan adb bugreport bugreport.zip. Untuk versi 6.0 ke bawah jalankan adb bugreport > bugreport.txt.
Selanjutnya reset agregat agar statistik benar-benar fresh. Jalankan adb shell dumpsys batterystats –reset.
Aktifkan full wake detail dan praktik terbaik
Kalau butuh detail wakelock, hidupkan dengan adb shell dumpsys batterystats –enable full-wake-history. Ingat, log bisa overflow jika durasi uji lebih dari 3–4 jam.
- Nama file konsisten: tanggal_waktu_device_skenario.zip untuk memudahkan tracking.
- Pastikan device relatif idle sebelum mulai sehingga stats mewakili skenario.
- Simpan semua files dan catatan di repositori terpusat dengan kontrol versi.
- Jaga screen agar tidak masuk sleep saat mengambil bugreport.
- Jika bugreport gagal, jalankan adb beberapa kali dan cek cpu di PC untuk kinerja pembuatan file.
| Langkah | Perintah | Catatan |
|---|---|---|
| Ambil bugreport (7.0+) | adb bugreport bugreport.zip | Gunakan zip agar Historian bisa mengimpor semua files |
| Ambil bugreport (≤6.0) | adb bugreport > bugreport.txt | File teks cocok untuk versi lama |
| Reset stats | adb shell dumpsys batterystats –reset | Bersihkan semua statistik sebelum skenario |
| Full wake detail | adb shell dumpsys batterystats –enable full-wake-history | Gunakan untuk sesi singkat (3–4 jam) untuk mencegah log overflow |
Battery History ADB: Perintah Inti dan Contoh Cepat
Sebelum mengekspor ke tools visual, mari kumpulkan data primer lewat beberapa command singkat.
Kita mulai dengan ringkasan konsumsi menggunakan adb shell dumpsys batterystats. Perintah ini memberi statistik penggunaan dan baseline sebelum visualisasi.
Ringkasan konsumsi dan status perangkat
Untuk melihat level, suhu, dan state jalankan adb shell dumpsys battery. Ini membantu kita memahami kondisi power saat pengujian dimulai.
Fokus pada app dan proses terkait
Gunakan adb shell dumpsys meminfo <package>, adb shell dumpsys cpuinfo, dan adb shell dumpsys wifi untuk melengkapi data. Gabungan output ini memudahkan korelasi antara cpu spike dan consumption pada waktu tertentu.
| Tujuan | Perintah | Catatan |
|---|---|---|
| Ringkasan usage | adb shell dumpsys batterystats | Baseline sebelum import |
| Status power | adb shell dumpsys battery | Level, suhu, state |
| Detail proses | meminfo / cpuinfo / wifi | Kaitkan dengan timeline |
Kita rekomendasikan menyimpan setiap output ke file teks dan menjalankan commands yang sama di tiap sesi. Untuk analisis lanjutan, gunakan parser Historian (checkin-parse, history-parse, checkin-delta) atau buat script agar sequence ini hanya sekali klik.
Mengunggah dan Membaca Timeline di Battery Historian
Dalam beberapa klik, file zip atau txt berubah menjadi timeline interaktif yang membantu kita menemukan puncak usage.
Mulai dengan mengunggah bugreport.txt atau bugreport.zip ke antarmuka. Setelah import selesai, UI mem-plot event dan statistik sejak state penuh charge sehingga kita mendapat gambaran time yang jelas.
Mengimpor dan menavigasi
Kita pilih device target lalu unggah files. Timeline mendukung panning dan zoom sehingga inspection rentang time tertentu jadi cepat.
Membaca aktivitas dan korelasi
Perhatikan wakelock, cpu peaks, perubahan screen, dan event jaringan. Pola yang sering muncul: spike cpu bersamaan dengan activity jaringan dan perubahan window, yang biasanya menandai peningkatan battery drain.
- Pilih app atau proses untuk menyaring data.
- Beri catatan pada segmen mencurigakan untuk diskusi tim.
- Simpan tangkapan layar timeline sebagai bukti visual bagi user non-teknis.
| Elemen | Apa yang Dicari | Tindakan |
|---|---|---|
| Wakelock | Durasi panjang saat idle | Investigasi package |
| CPU | Puncak berulang | Cek proses background |
| Screen & Network | Perubahan window & trafik | Hubungkan dengan usage app |
Identifikasi Aplikasi Paling Boros dalam 24 Jam
Kami ingin cepat menemukan app yang paling berkontribusi pada drain dalam rentang 24 hours.
Kita mulai dengan membaca puncak consumption pada timeline dan mencatat time serta hours saat lonjakan terjadi. Catatan ini jadi dasar nomor untuk perbandingan.
Historian mendukung strategi A/B: unggah dua bugreport dan bandingkan metrics untuk melihat regresi consumption setelah perubahan kode. Ambang praktis yang kita pakai adalah >15%/hour sebagai indikator masalah.
Untuk menautkan puncak drain ke activity app atau window, kita periksa event yang bersamaan dan jalankan adb shell tambahan untuk mengecek proses saat lonjakan. Log yang dikumpulkan jadi bukti kuat saat membuat rekomendasi.
- Kami tandai segmen timeline dengan consumption tinggi, simpan time dan number metrik.
- Bandingkan dua bugreport untuk menonjolkan perubahan stats dan statistics.
- Validasi hasil di beberapa devices agar pola drain tidak tersangka karena hardware tertentu.
- Dokumentasikan usage per app dan rekomendasi prioritas perbaikan.
| Langkah | Aksi | Hasil |
|---|---|---|
| Identifikasi puncak | Baca timeline & catat time | Daftar app target |
| A/B comparison | Unggah dua bugreport | Perbedaan consumption jelas |
| Validasi | Uji di beberapa phone | Hasil dapat diandalkan |
Workflow Pengujian Otomatis: Dari ADB Commands ke Laporan JSON dan Graf
Kami membuat alur otomatis agar pengukuran consumption repeatable dan cepat diproses oleh tim.
Kita mulai dengan skema sederhana: reset statistik → jalankan app → logging berkala → rekap akhir. Setiap langkah dieksekusi lewat skrip yang memanggil adb dan mengambil output secara periodik.
Skema test singkat
Contoh manual: reset statistik, jalankan app selama 1 jam, ambil metrik, dan ekstrak angka kunci.
Contoh otomatis (Java): cek level setiap 10 menit lalu simpan ke battery_report.json untuk analisis lebih lanjut.
Integrasi CI/CD
Di Jenkins kita jalankan job yang mengeksekusi skrip, mengumpulkan log, dan mengarsip artifacts. Ini menjaga histori number metrik per build.
Visualisasi dengan Grafana
Kita ekspor JSON dan files log ke time-series DB, lalu buat dashboard. Grafana memetakan consumption dan cpu terhadap time sehingga proses, screen, dan event terlihat jelas.
| Langkah | Perintah / Output | Hasil |
|---|---|---|
| Reset | adb shell dumpsys batterystats –reset | Statistik bersih untuk sesi |
| Periodic polling | adb shell dumpsys battery → JSON | Log berkala untuk time-series |
| CI archive | Jenkins archiveArtifacts | Files log & laporan terjaga |
Kita juga tetapkan ambang kelulusan (misal 15%/jam). Jika consumption melewati batas, pipeline menandai build gagal. Standar perangkat dan skenario wajib agar hasil antar-build comparable.
Optimasi Lanjutan via ADB: Kurangi Drain Setelah Analisis
Setelah menganalisis timeline, kita terapkan tweak yang cepat diuji dan mudah diulang. Fokusnya pada perubahan settings yang memberi dampak nyata pada power dan screen serta pengelolaan processes yang berjalan di background.
Matikan animasi UI, kurangi refresh rate, dan batasi background
Kami mulai dengan perubahan yang langsung terasa pada battery life. Aktifkan low power mode:
adb shell settings put global low_power 1
Nonaktifkan animasi agar render window tidak memicu gpu/cpu berlebih:
adb shell settings put global window_animation_scale 0.0, transition_animation_scale 0.0, animator_duration_scale 0.0.
Kurangi refresh rate pada phone high-refresh:
settings put system peak_refresh_rate <value> dan settings put system min_refresh_rate <value>.
Device Idle dan App Standby: force-idle, whitelist, dan force-stop
Untuk menghentikan aktivitas background sementara, gunakan perintah ini secara selektif:
- adb shell pm restrict-background <package> untuk batasi data background.
- adb shell am force-stop <package> untuk menghentikan app yang bermasalah pada sesi uji.
- Paksa mode idle dan cek whitelist dengan adb shell dumpsys deviceidle lalu adb shell dumpsys deviceidle force-idle.
Kelola bloatware, brightness, resolusi, dan power management
Kita hapus atau disable bloatware agar service tidak lagi menempati resources.
Contoh: pm uninstall –user 0 <package> atau pm disable-user <package>.
Ubah resolusi dan density untuk menurunkan beban render screen:
adb shell wm size 1080×1920 dan adb shell wm density 420.
Setiap perubahan dicatat dan divalidasi dengan snapshot adb shell dumpsys atau adb shell dumpsys batterystats untuk membandingkan battery life dan cpu hotspot sebelum/after.
| Optimasi | Perintah | Efek yang Diharapkan |
|---|---|---|
| Low power | adb shell settings put global low_power 1 | Menurunkan konsumsi background dan throttling cpu |
| Nonaktifkan animasi | adb shell settings put global window_animation_scale 0.0 … | Render UI lebih ringan, menekan gpu usage |
| Batasi background app | adb shell pm restrict-background <package> | Kurangi trafik dan wakeups dari proses latar |
| Paksa idle | adb shell dumpsys deviceidle force-idle | Reduksi activity saat device idle, uji dampak drain |
Pemecahan Masalah dan Praktik Terbaik
Masalah overflow log sering muncul saat kita mengaktifkan mode rekam wake lengkap. Untuk mencegah file corrupt dan memudahkan analisis, batasi durasi uji pada sesi 3–4 jam ketika opsi full-wake-history aktif.
Sebelum merekam, reset stats dengan adb shell dumpsys batterystats –reset. Mulai rekaman power monitor setelah itu, hentikan sesuai jadwal, lalu ambil bugreport segera untuk meminimalkan drift time antara sumber data.
Gunakan format power monitor yang konsisten: epoch detik (dengan fraksi) amps/volts atau epoch ms milliamps/millivolts. Format yang seragam memudahkan overlay ke timeline dan mengurangi error parsing.
Catatan state, verifikasi lintas devices, dan checklist
Catat state perangkat sebelum & sesudah uji: charging/offline, radio aktif, screen on/off. Informasi ini penting saat menafsirkan stats dan aktivitas background.
Verifikasi hasil di beberapa devices agar temuan bukan hanya anomali hardware. Kami juga menyarankan checklist sederhana untuk developer: reset → run → capture → label → archive.
- Pantau cpu dan system load di host; UI lambat sering karena mesin analisis kelebihan beban.
- Simpan semua file dan files pendukung secara terstruktur dengan penamaan konsisten.
- Gunakan catatan time yang sama antara power monitor dan bugreport untuk mempermudah korelasi.
| Masalah | Solusi | Praktik | Durasi empfohlen |
|---|---|---|---|
| Log overflow | Batasi rekaman; nonaktifkan full-wake-history untuk sesi panjang | Gunakan 3–4 jam untuk detail wake | 3–4 jam |
| Sinkronisasi time | Reset stats lalu mulai rekaman; ambil bugreport segera | Gunakan epoch ms atau detik untuk power monitor | N/A |
| Performa host | Monitor cpu/system; alokasikan resource lebih | Jalankan Historian pada host dengan CPU memadai | – |
Untuk referensi teknis dan langkah lanjutan, lihat panduan resmi. Dengan rutinitas sinkronisasi dan penyimpanan files yang rapi, analisis kami menjadi lebih andal dan dapat direplikasi oleh tim developer.
Kesimpulan
Secara singkat, kombinasi visual timeline dari Historian dan praktik otomasi memberi kita gambaran jelas tentang battery usage dan titik-titik consumption yang bermasalah.
Kita pakai statistik sejak full charge, pemilihan app, dan perbandingan A/B antar bugreport untuk mengidentifikasi puncak drain dalam rentang time tertentu. Ambang praktis 15%/jam tetap menjadi panduan saat menilai apakah sebuah app perlu diinvestigasi.
Kami menganjurkan monitoring rutin di pipeline CI dan pembuatan laporan JSON berkala via adb agar consumption terpantau lintas devices. Perhatikan level tren, cpu spike, perubahan screen, dan event power pada setiap time untuk menemukan penyebab utama.
Terakhir, terapkan prioritas optimasi pada app yang boros lalu ukur ulang usage untuk memastikan battery life membaik.
