Mengatasi masalah "menunggu perangkat" ADB


9

Kami sedang menyiapkan server integrasi berkelanjutan untuk pengembangan Android kami dan kami dengan cepat bertemu dengan ADB yang menunggu masalah perangkat .

Sebagai catatan, kami sudah mencoba banyak kombinasi adb kill-server, adb start-server, adb devices, dll tidak berhasil.

Sayangnya, semua yang saya temukan di internet adalah variasi "cabut dan pasang kembali perangkat", yang jelas bukan solusi bagi kami (kami tidak bisa membiarkan manusia duduk di dekat server CI untuk melepas dan memasang kembali perangkat sebelum masing-masing membangun).

Sebagai latar belakang, kami menggunakan Jenkins pada Mac, karena menjalankan CI kami untuk iOS juga.

Saat mendekati masalah saya berpikir bahwa jika pada level OS perangkat ditemukan, itu setidaknya sebuah permulaan. Memang, menjalankan perintah seperti system_profiler SPUSBDataTypeberhasil menemukan perangkat, termasuk nomor seri yang dilaporkan ADB ketika bekerja dengan benar.

Saya telah mencoba beberapa perintah yang agak timpang untuk "menyegarkan" semua aktivitas USB, tetapi saya tidak ke mana-mana. Bukannya Anda dapat memasang / melepas perangkat, tapi jujur ​​saja saya bahkan tidak yakin di mana masalahnya, saya tidak cukup tahu tentang protokol USB tingkat rendah, apalagi untuk Mac. Saya mengintai kode sumber ADB adalah kesempatan yang sangat, sangat lama.

Jadi pada titik ini saya semua mendengar solusi yang akan memungkinkan kami menjalankan Android secara konsisten di server CI kami. Baik itu beberapa perintah sebelum setiap pekerjaan Jenkins, menambal ADB atau trik sulap hitam lainnya.

Jawaban:


9

Menemukan cara penyelesaiannya, jadi posting di sini untuk kelengkapan. Harap dicatat bahwa saya tidak mengatakan ini adalah cara terbaik untuk menyelesaikannya, tetapi ini berhasil bagi kami.

Jadi, kami menyadari masalah terjadi setelah lama tidak aktif CI (dalam kisaran jam). Jadi kami membuat skrip sederhana yang memanggil adb devicessetiap 10 detik. Dan masalahnya hilang, tidak ada lagi masalah "menunggu perangkat".

Di Linux Anda dapat melakukan ini dengan cronpekerjaan sederhana dan pada OSX dengan launchctldan saya yakin ada yang setara dengan Windows.

Apapun, "ping" perangkat setiap 10 detik menyelesaikannya untuk kita.


1
Terima kasih! Sepertinya saya mengalami masalah yang sama. Mencabut dan menyambungkan kembali kabel USB membuat perangkat muncul dalam daftar.
Jorge Pedret

5

Mengaktifkan debugging USB (Pengaturan => Opsi pengembang) di telepon membantu.


1

Kami memiliki beberapa masalah serupa dengan lingkungan Integrasi Berkelanjutan kami dengan perangkat Android dari mesin OSX (juga digunakan untuk iOS dan Android).

Saya percaya masalahnya adalah Anda mengizinkan Jenkins untuk memulai server adb. Penyebabnya masalah karena pekerjaan Jenkins dikaitkan dengan cangkang yang keluar-masuk. Jika Jenkins memulai daemon adb dengan panggilan "adb devices" (misalnya), maka daemon adb akan dimiliki oleh beberapa shell Jenkins yang berumur pendek, dan ketika shell selesai dieksekusi dan ditutup, daemon adb akan dibersihkan , sampai dimulai kembali secara otomatis oleh panggilan adb lain. Ini menghasilkan siklus memulai dan menghentikan daemon adb, tetapi yang Anda inginkan adalah agar hanya begadang tanpa batas.

Salah satu cara untuk memperbaikinya, adalah dengan menjalankan "adb devices" dari shell yang dibiarkan terbuka pada mesin CI. Anda dapat mengetahui apakah ini merupakan proses induk dengan apakah pesan ini ditampilkan setelah dijalankan

blah$ adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
xxxxxxxxxxx          device

Ini adalah langkah menjengkelkan yang harus dilakukan setiap kali mesin Anda restart, dan jika ada yang menutup jendela perintah itu, Anda akan kembali ke masalah sebelumnya.

Secara teori, cara yang lebih baik adalah membuat file .plist untuk memicu daemon adb saat bootup. Berikut ini contohnya: ~ / Library / LaunchAgents / server.adb.plist. Ini pada dasarnya hanya menjalankan adb start-server dari daemon peluncuran pengguna untuk menghindari Jenkins memilikinya.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>server.adb</string>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <false/>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/Shared/Jenkins/android-sdk/platform-tools/adb</string>
        <string>start-server</string>
    </array>
  </dict>
</plist>

Masalah dengan ini, bagaimanapun, adalah bahwa ia baru saja memulai adb, tetapi itu tidak memblokir, jadi Anda tidak dapat menggunakan fungsi kontrol peluncuran KeepAlive. Juga, sepertinya tidak berfungsi untuk tujuan yang diinginkan. Jika ada yang tahu cara menjalankan adb dalam mode "daemon", jadi itu tidak kembali, maka mekanisme launchctl ini dapat diatur untuk memulai kembali secara otomatis jika mati, karena itu memastikan bahwa Jenkins tidak pernah mendapatkan kepemilikan. Oh well, untuk saat ini saya hanya akan menjalankan "adb devices" di jendela shell dan membiarkannya terbuka.


1

Saya memecahkan ini dengan menggunakan strip daya yang dapat diprogram untuk me-reboot hub usb sebelum setiap tes dijalankan. Ini melakukan hal yang sama seperti mencabut dan memasang kembali kabel usb.


Bisakah Anda melakukan expalin lebih banyak?
Dinesh

1

Saya hanya ingin menindaklanjuti saran luar biasa dari juan-delgado . Saya temukan di MacOS High Sierra bahwa menjalankan adbsetiap 10 detik dengan watchperintah juga efektif sebagai solusi cepat:

watch -n 10 adb -d devices

Ini memungkinkan saya untuk menghindari membuat .plistfile, tetapi kekurangannya jelas itu bukan solusi permanen. The watchperintah tersedia pada versi sebelumnya dari OSX, jadi harus efektif di sana juga.


Saya tidak memilikinya watchdi macOS Catalina, tetapi dapat menginstalnya dengan mudah brew install watch.
mokagio

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.