Заохочення випуску ADB "в очікуванні пристрою"

Ми налаштовуємо сервер безперервної інтеграції для нашої розробки Android, і ми швидко стикаємося з очікуванням проблеми ADB на пристрої .

Для запису, ми вже пробували багато комбінацій adb kill-server, adb start-server, adb devicesі т.д., але безрезультатно.

На жаль, все, що я знайшов в Інтернеті, - це варіанти "відключити мережу та відключити пристрій від мережі", що, очевидно, не є рішенням для нас (ми не можемо пошкодити людину сидіти за сервером CI, щоб вимкнути і відключити пристрої раніше кожна збірка).

Як трохи тло, ми використовуємо Jenkins на Mac, оскільки він також запускає наш CI для iOS.

Підходячи до проблеми, я подумав, що якщо на рівні ОС пристрій знайдеться, це хоча б початок. Дійсно, запускаючи таку команду, як system_profiler SPUSBDataTypeуспішно, знаходить пристрій, включаючи серійний номер, про який повідомляє ADB при правильній роботі.

Я спробував декілька доволі кульгавих команд "оновити" всі USB-дії, але нікуди не пішов. Справа не в тому, що ви можете встановити / відключити пристрій, але якщо чесно, я навіть не впевнений, де проблема, я не знаю достатньо про протоколи USB низького рівня, не кажучи вже про Macs. Моє приховування вихідного коду ADB було дуже-дуже тривалим.

Тож на даний момент я все чую за рішення, яке б дозволило нам послідовно працювати Android на нашому сервері CI. Будьте кілька команд перед кожним завданням Дженкінса, виправлення ADB або будь-який інший чорний фокус.

Знайшов спосіб її вирішення, тому розміщуємо тут для повноти. Зверніть увагу, що я не кажу, що це найкращий спосіб вирішити це, але це працює для нас.

Отже, ми зрозуміли, що проблема трапилася після тривалих періодів бездіяльності ІС (в інтервалі годин). Тому ми створили простий сценарій, який дзвонить adb devicesкожні 10 секунд. І проблеми вже немає, більше немає проблем з "очікуванням пристрою".

В Linux ви можете це зробити за допомогою простої cronроботи, а на OSX - launchctlі я впевнений, що є еквівалент Windows.

Незалежно від того, «пінг» пристроїв кожні 10 секунд вирішував це за нас.

Увімкнення налагодження через USB (Налаштування => Параметри розробника) у телефоні допомогло.

У нас було певних подібних проблем із середовищем постійної інтеграції із пристроями Android від машини OSX (також для iOS та Android).

Я вважаю, що проблема полягає в тому, що ви дозволяєте Дженкінсу запускати сервер adb. Причини викликають проблеми, оскільки роботи Дженкінса пов'язані з оболонками, що входять і існують. Якщо Дженкінс розпочинає демон adb з викликом "adb devices" (наприклад), то демоном adb буде належати деяка недовговічна оболонка Дженкінса, і коли ця оболонка закінчиться виконанням і закриється, демон adb буде очищений , до тих пір, поки не буде автоматично запущено резервне копіювання іншого дзвінка adb. Це призводить до циклу запуску та зупинки демона adb, але те, що ви хочете, - це просто залишатися безстроково.

Один із способів виправити це - просто запустити "adb пристрої" з оболонки, яка залишається відкритою на машині CI. Ви можете сказати, чи це батьківський процес, показавши це повідомлення після запуску

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

Це дратівливий крок, який потрібно виконувати кожного разу при перезапуску машини, і якщо хтось закриє це вікно команд, ви повернетесь до попередньої проблеми.

Теоретично кращим способом було б зробити файл .plist для запуску демона adb під час завантаження. Ось приклад: ~ / Бібліотека / LaunchAgents / server.adb.plist. Це, в основному, запускає adb start-сервер від демона запуску користувача, щоб уникнути володіння ним Дженкінсом.

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

Проблема в цьому полягає в тому, що він просто запускає adb, але він не блокується, тому ви не можете використовувати функцію управління запуском KeepAlive. Крім того, це, здається, не працює для бажаної мети. Якщо хтось знає про спосіб запуску adb в режимі "демон", тому він не повертається, тоді цей механізм startctl може бути налаштований для автоматичного перезавантаження його, якщо він помре, тому гарантуючи, що Дженкінс ніколи не отримає право власності. Ну добре, поки що я просто запускаю "adb пристрої" у вікні оболонки і залишаю його відкритим.

Я вирішив це за допомогою програмованої смуги живлення для перезавантаження концентраторів usb до кожного тестового запуску. Це робилося так само, як відключення та підключення USB-кабелів назад.

Мені просто хотілося продемонструвати чудову пропозицію від Хуана-Дельгадо . На MacOS High Sierra я виявив, що запуск adbкожні 10 секунд watchкомандою також був ефективним як швидке вирішення:

watch -n 10 adb -d devices

Це дозволяє мені пройти під час створення .plistфайлу, але очевидний недолік - це не постійне рішення. watchКоманда доступна в попередніх версіях OSX, тому вона повинна бути ефективною і там.

Тут вирішено шляхом зміни кабелю USB