ADB “cihaz bekleniyor” sorunu etrafında çalışma

Android geliştirmemiz için sürekli bir entegrasyon sunucusu kuruyoruz ve hızla ADB'nin cihaz sorununu beklemeye başladık .

Kayıt için, zaten kombinasyonları bir sürü denedim adb kill-server, adb start-server, adb devicesboşuna vb.

Ne yazık ki, internette bulduğum tek şey, "cihazın fişini çekin ve yeniden takın" varyasyonlarıdır, bu bizim için bir çözüm değildir (daha önce cihazları çıkarmak ve çıkarmak için CI sunucusu tarafından oturmak için bir insanı yedekleyemeyiz) her yapı).

Arka plan olarak, bir Mac'te Jenkins kullanıyoruz, çünkü iOS için CI'mızı da çalıştırıyor.

Soruna yaklaşırken, işletim sistemi düzeyinde cihaz bulunursa, bunun en azından bir başlangıç ​​olduğunu düşündüm. Gerçekten, system_profiler SPUSBDataTypeADB'nin doğru çalışırken raporladığı seri numarası da dahil olmak üzere, başarılı bir komut gibi bir komutu çalıştırmak cihazı bulur.

Tüm USB aktivitelerini "yenilemek" için oldukça basit komutlar denedim, ama hiçbir yere gitmedim. Cihazı bağlayabileceğiniz / çıkarabileceğiniz değil, ama dürüst olmak gerekirse, sorunun nerede olduğundan bile emin değilim, Mac'ler için, düşük seviyeli USB protokolleri hakkında yeterince bilgim yok. ADB kaynak kodunu gizlice izlemem çok ama çok uzun sürdü.

Bu noktada, Android'i CI sunucumuzda sürekli olarak çalıştırmamıza izin veren bir çözüm için kulaklarım. Her Jenkins işinden önce birkaç komut olsun, ADB'yi veya diğer kara büyü hilelerini yamalayın.

Bunu çözmenin bir yolunu buldum, bu yüzden tamlık için buraya gönderiyorum. Bunun çözmenin en iyi yolu olduğunu söylemediğimi lütfen unutmayın , ama bizim için işe yaradı.

Bu nedenle, sorunun uzun süredir CI hareketsizliğinden (saat aralığında) sonra gerçekleştiğini fark ettik. Bu yüzden adb devicesher 10 saniyede bir çağıran basit bir betik oluşturduk . Sorun ortadan kalktı, artık "cihaz bekleniyor" sorunları kalmadı.

Linux'ta bunu basit bir croniş ve OSX ile yapabilirsiniz launchctlve eminim bir Windows eşdeğeri vardır.

Ne olursa olsun, cihazların her 10 saniyede bir "pinglenmesi" bizim için çözdü.

Telefonda USB hata ayıklamanın etkinleştirilmesi (Ayarlar => Geliştirici seçenekleri) yardımcı oldu.

Bir OSX makinesinden Android cihazlarla Sürekli Entegrasyon ortamımızda bazı benzer sorunlar yaşadık (hem iOS hem de Android için de kullanılıyor).

Sorunun Jenkins'in adb sunucusunu başlatmasına izin verdiğinize inanıyorum. Nedeni sorunlara neden olur çünkü Jenkins işleri var olan ve çıkan mermilerle ilişkilidir. Jenkins adb daemon'unu bir "adb device" çağrısıyla (örneğin) başlattıysa, adb daemon'u kısa ömürlü bir Jenkins kabuğuna ait olacak ve bu kabuk çalıştırmayı ve bitirmeyi bitirdiğinde adb daemon'u temizlenecek , başka bir adb çağrısı tarafından otomatik olarak başlatılıncaya kadar. Bu, adb daemon'unu başlatma ve durdurma döngüsüyle sonuçlanır, ancak istediğiniz şey, süresiz olarak kalmasıdır.

Bunu düzeltmenin bir yolu, sadece "adb cihazlarını" CI makinesinde açık bırakılan bir kabuktan çalıştırmaktır. Çalıştırdıktan sonra bu iletinin gösterilip gösterilmeyeceğini ana işlem olup olmadığını anlayabilirsiniz

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

Bu, makineniz her yeniden başlatıldığında gerçekleştirilmesi gereken sinir bozucu bir adımdır ve herhangi biri bu komut penceresini kapatırsa önceki soruna geri dönersiniz.

Teorik olarak, daha iyi bir yol açılışta adb arka plan programını tetiklemek için .plist dosyası yapmak olacaktır. İşte bir örnek: ~ / Library / LaunchAgents / server.adb.plist. Bu temelde Jenkins'in sahip olmasını önlemek için adb start-server'ı kullanıcı başlatma arka plan programından çalıştırır.

<?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>

Bununla birlikte, sorun sadece adb başlatması, ancak engellememesi, bu nedenle KeepAlive başlatma kontrol işlevini kullanamazsınız. Ayrıca, istenen amaç için çalışmıyor gibi görünüyor. Herkes "daemon" modunda adb'yi çalıştırmanın bir yolunu biliyorsa, geri dönmezse, bu launchctl mekanizması ölürse otomatik olarak yeniden başlatacak şekilde ayarlanabilir, böylece Jenkins'in hiç sahiplenmediğinden emin olunur. Ah, şimdilik sadece "adb cihazlarını" bir kabuk penceresinde çalıştırıp açık bırakacağım.

Bunu, her test çalışmasından önce usb hub'larını yeniden başlatmak için programlanabilir bir uzatma kablosu kullanarak çözdüm. Bu, usb kablolarını çıkarıp tekrar takmakla aynı şeyi yaptı.

Sadece juan-delgado'nun mükemmel önerisini takip etmek istedim . MacOS High Sierra'da komutla adbher 10 saniyede bir çalışmanın watchda hızlı bir çözüm olarak etkili olduğunu buldum :

watch -n 10 adb -d devices

Bu, bir .plistdosya oluşturmayı bırakmama izin veriyor , ancak bariz dezavantajı, kalıcı bir çözüm değil. watchO da orada etkili olmalı, böylece komut, OSX önceki sürümleri mevcuttur.

USB kablosunu değiştirerek burada çözüldü