Device farm Android: bangun sendiri atau pakai cloud

Device farm Android adalah sekumpulan ponsel uji yang terhubung ke mesin host, sehingga test otomatis dan para tester bisa memakainya tanpa harus memegangnya. Istilah ini berasal dari dunia QA, dan dalam arti itulah artikel ini memakainya: kumpulan perangkat bersama untuk menjalankan dan mereproduksi pengujian. Rak ponsel yang dipakai untuk mengoperasikan akun media sosial dalam skala besar adalah hal yang berbeda, melanggar ketentuan semua platform besar, dan tidak dibahas di sini.

Setiap tim mobile pasti sampai pada titik ketika laci berisi ponsel tidak lagi memadai. Ada yang membawa Pixel pulang, tidak ada yang tahu ponsel mana memakai build yang mana, dan CI berjalan di satu emulator saja. Panduan ini membahas untuk apa sebuah farm, apa saja yang dibutuhkan rak buatan sendiri beserta biayanya, dan kapan cloud phone bisa melakukan pekerjaan yang sama.

Untuk apa device farm

• Test UI otomatis di sebuah matriks. Suite Espresso, UI Automator, atau Appium di beberapa versi Android dan ukuran layar sekaligus, sehingga release candidate mendapat satu jawaban yang jelas.
• Mereproduksi bug pengguna. Laporan menyebut sebuah model dan versi Android, dan farm punya ponsel itu atau yang mendekatinya.
• Sesi manual dan eksploratif. Tester membuka model tertentu dari jarak jauh alih-alih meminjamnya dari rekan kerja.
• Pengujian berdurasi panjang. Sinkronisasi di latar belakang, pengiriman notifikasi, dan pemakaian memori selama berjam-jam, yang tidak bisa diperlihatkan emulator yang dibuang setelah setiap job CI.
• Smoke test rilis. Pengecekan cepat yang sama di sepuluh ponsel secara paralel sebelum rollout.

Anatomi rak buatan sendiri

Membangun rak tidaklah sulit. Menjaganya tetap sehat itulah pekerjaan sebenarnya. Rak pada umumnya punya lima bagian.

Ponsel. Pilih berdasarkan data analitik Anda, bukan berdasarkan yang sedang diskon: model teratas menurut porsi sesi, versi Android tertua yang Anda dukung, dan yang terbaru. Beli dua unit untuk model paling umum, supaya satu bisa dipakai manual sementara yang lain menjalankan CI.

Daya dan USB. Hub berdaya dengan arus yang cukup per port, kabel pendek berkualitas layak, dan anggaran untuk USB host controller. Sebagai patokan, adb mulai tidak stabil di kisaran sepuluh sampai lima belas ponsel per host, tergantung controller dan hub-nya.

Host. Mesin Linux kecil atau Mac, masing-masing menjalankan server adb untuk raknya. Lacak perangkat berdasarkan nomor seri dan simpan peta ponsel mana tersambung di port mana, karena Anda akan membutuhkannya di saat yang paling tidak tepat.

Software. adb, pengelola perangkat seperti DeviceFarmer (penerus OpenSTF dari komunitas) untuk layar jarak jauh dan pemesanan perangkat, Appium dengan grid jika Anda menguji lewat WebDriver, dan CI Anda untuk menjadwalkan run.

Perawatan. Inilah bagian yang tidak pernah masuk anggaran. Baterai menggembung jika ponsel terus di charger selama berbulan-bulan, jadi gunakan batas pengisian yang ditawarkan sebagian vendor atau smart plug yang memutus dan menyambung daya. Notifikasi update sistem muncul di tengah run. Layar terkunci, notifikasi menumpuk, penyimpanan penuh dengan media uji, dan ponsel yang crash semalaman menyala dengan sebuah dialog tanpa ada orang yang mengetuknya.

Biaya sebenarnya sebuah rak

Untuk rak berisi 20 ponsel, perkiraan kasar tahun 2026 kira-kira seperti ini. Ponselnya $3.000 sampai $12.000, tergantung berapa banyak flagship yang Anda butuhkan. Hub, kabel, rak, dan dua host menambah $1.500 sampai $4.000. Lalu sisihkan 20 sampai 30% dari belanja ponsel setiap tahun untuk baterai menggembung, port rusak, dan model baru yang dibeli pengguna Anda.

Pos yang mengejutkan banyak tim adalah waktu: tiga sampai delapan jam per minggu bagi seseorang untuk membereskan ponsel yang macet, memasang update, dan me-reboot host. Angka Anda akan berbeda, tetapi polanya sama. Hardware hanyalah bagian yang lebih kecil dari tagihannya.

Cloud phone mengubah semua ini menjadi biaya berjalan tanpa perawatan. Di Clousd, bayar per menit dikenai $0.004 per menit selama ponsel menyala dan tidak pernah lebih dari $0.80 per ponsel per hari, dan paket mulai $20 per bulan; detailnya ada di halaman harga. Dua contoh hitungan untuk 20 ponsel yang sama:

• Dua jam setiap hari kerja: 20 ponsel × 120 menit × $0.004 = $9.60 per hari, sekitar $211 untuk 22 hari kerja.
• Nonstop sepanjang hari: batas harian berlaku, jadi 20 × $0.80 × 30 hari = maksimal $480 per bulan.

Menit bayar per menit berhenti saat ponsel dimatikan. Model yang Anda butuhkan untuk satu laporan bug cukup dibuat, dipakai, lalu dihapus.

Rak sendiri, device cloud, atau cloud phone

Apa yang berubah dengan setup cloud

• Awal yang bersih. Ponsel dibuat dalam sekitar satu menit dan bisa di-reset ke kondisi baru sebelum setiap suite, sehingga setiap run dimulai dari titik yang sama.
• Model sebagai parameter. Android 12 sampai 17 di 150+ model asli, dipilih per run dari daftar model, bukan dari apa yang kebetulan ada di rak.
• Jarak jauh secara bawaan. Layar langsung di browser untuk sesi manual, REST API dan ADB untuk CI, serta server MCP jika pengecekan dijalankan AI agent.
• Tanpa urusan hardware. Tidak ada yang menggembung, tidak ada yang butuh kabel, tidak ada yang perlu di-reboot jam 2 pagi.

Apa yang tidak berubah

Cloud phone bukan ponsel fisik. Pipeline kamera, akurasi sensor, performa GPU, konsumsi baterai, thermal throttling, NFC, Bluetooth, dan pembunuh proses latar khas vendor tetap butuh hardware asli. Sebagian besar tim akhirnya memakai kombinasi: tiga sampai lima ponsel fisik di meja untuk pengecekan tersebut, dan matriks luas model serta versi di cloud. Testing aplikasi di berbagai versi Android merinci apa saja yang perlu dicakup matriks itu.

Menjalankan test di farm, di mana pun lokasinya

Test runner mengenali ponsel lewat serial adb-nya, jadi suite yang sama bisa berjalan di rak USB maupun di ponsel jarak jauh. AndroidJUnitRunner bisa membagi satu suite ke beberapa perangkat dengan shard:

R=com.example.app.test/androidx.test.runner.AndroidJUnitRunner
adb -s "$P12" shell am instrument -w -e numShards 3 -e shardIndex 0 $R
adb -s "$P14" shell am instrument -w -e numShards 3 -e shardIndex 1 $R
adb -s "$P16" shell am instrument -w -e numShards 3 -e shardIndex 2 $R

Jalankan ketiga baris secara paralel, dan setiap ponsel mengerjakan sepertiga test. Appium memilih perangkat lewat capability appium:udid, yang memakai serial yang sama. Ponsel jarak jauh bergabung ke pool dengan adb connect; dokumentasi ADB menunjukkan cara kerjanya lewat relay, dan halaman testing aplikasi menunjukkan jalur API untuk CI.

Perkirakan setiap aksi jarak jauh sedikit lebih lama daripada lewat USB, dan atur timeout test UI Anda dengan mempertimbangkan hal itu. Test yang lolos di emulator lokal tetapi timeout dari jarak jauh biasanya punya sleep yang di-hardcode atau wait yang terlalu ketat.

Mobile device farm dan cloud phone farm

Mobile device farm adalah ide yang sama, dengan iPhone dan iPad di rak di samping ponsel Android. Dalam QA, cloud phone farm hanyalah kumpulan cloud phone tempat suite Anda berjalan. Kata "farm" punya arti lain di luar dunia pengujian; penjelasan tentang phone farm membahasnya.