2015-03-09 10 views
17

Widzimy wiele błędów konstrukcyjnych przy pierwszym, a nawet drugim wykonaniu żądań ściągnięcia dla naszego projektu Android na Travis. Jeśli jednak ponownie uruchomimy dokładnie tę samą kompilację, w końcu się ona zakończy.Testy Androida kończą się niepowodzeniem na Travis z ShellCommandUnresponsiveException

Oto co błąd wygląda na awarie:

:onebusaway-android:connectedAndroidTest 
09:48:14 E/Device: Error during shell execution: null 
Unable to install /home/travis/build/OneBusAway/onebusaway-android/onebusaway-android/build/outputs/apk/onebusaway-android-debug.apk 
com.android.ddmlib.InstallException 
at com.android.ddmlib.Device.installPackages(Device.java:927) 
at com.android.builder.testing.ConnectedDevice.installPackages(ConnectedDevice.java:105) 
at com.android.builder.internal.testing.SimpleTestCallable.call(SimpleTestCallable.java:125) 
at com.android.builder.internal.testing.SimpleTestCallable.call(SimpleTestCallable.java:48) 
at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745) 
Caused by: com.android.ddmlib.ShellCommandUnresponsiveException 
at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java:513) 
at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java:390) 
at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java:359) 
at com.android.ddmlib.Device.executeShellCommand(Device.java:566) 
at com.android.ddmlib.Device.createMultiInstallSession(Device.java:987) 
at com.android.ddmlib.Device.installPackages(Device.java:884) 
... 9 more 
com.android.builder.testing.ConnectedDevice > runTests[test(AVD) - 5.0.1] FAILED 
com.android.builder.testing.api.DeviceException: com.android.ddmlib.InstallException 
    at com.android.builder.testing.ConnectedDevice.installPackages(ConnectedDevice.java:108) 
null 
com.android.builder.testing.api.DeviceException: com.android.ddmlib.InstallException 
at com.android.builder.testing.ConnectedDevice.installPackages(ConnectedDevice.java:108) 
at com.android.builder.internal.testing.SimpleTestCallable.call(SimpleTestCallable.java:125) 
at com.android.builder.internal.testing.SimpleTestCallable.call(SimpleTestCallable.java:48) 
at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745) 
Caused by: com.android.ddmlib.InstallException 
at com.android.ddmlib.Device.installPackages(Device.java:927) 
at  com.android.builder.testing.ConnectedDevice.installPackages(ConnectedDevice.java:105) 
... 8 more 
Caused by: com.android.ddmlib.ShellCommandUnresponsiveException 
at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java:513) 
at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java:390) 
at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java:359) 
at com.android.ddmlib.Device.executeShellCommand(Device.java:566) 
at com.android.ddmlib.Device.createMultiInstallSession(Device.java:987) 
at com.android.ddmlib.Device.installPackages(Device.java:884) 
... 9 more 
:onebusaway-android:connectedAndroidTest FAILED 
FAILURE: Build failed with an exception. 

Biegniemy testy na emulatorze na Travis wykorzystaniem gradlew connectedTest.

Oto nasz .travis.yml:

# Test format changes to this .travis.yml file before submitting a PR with: 
# http://lint.travis-ci.org/OneBusAway/onebusaway-android 

language: android 
jdk: oraclejdk7 
# Turn off caching to avoid any caching problems 
cache: false 
# Use the Travis Container-Based Infrastructure (see #203) 
sudo: false 
env: 
    global: 
    - ANDROID_API_LEVEL=21 
    - ANDROID_BUILD_TOOLS_VERSION=21.1.2 
    - ANDROID_ABI=google_apis/armeabi-v7a 

android: 
    components: 
    - platform-tools 
    - tools 
    - build-tools-$ANDROID_BUILD_TOOLS_VERSION 
    - android-$ANDROID_API_LEVEL 
    # For Google Maps API v1 
    - addon-google_apis-google-$ANDROID_API_LEVEL 
    # Google Play Services 
    - extra-google-google_play_services 
    # Support library 
    - extra-android-support 
    # Latest artifacts in local repository 
    - extra-google-m2repository 
    - extra-android-m2repository 
    # Specify at least one system image 
    - sys-img-armeabi-v7a-addon-google_apis-google-$ANDROID_API_LEVEL 

before_script: 
    # Create and start emulator 
    - echo no | android create avd --force -n test -t "Google Inc.:Google APIs:"$ANDROID_API_LEVEL --abi $ANDROID_ABI 
    - emulator -avd test -no-skin -no-audio -no-window & 

script: 
    - ./wait_for_emulator 
    - ./gradlew connectedCheck -PdisablePreDex 

# Integration with Gitter (https://gitter.im/OneBusAway/onebusaway-android) 
notifications: 
    webhooks: 
    urls: 
     - https://webhooks.gitter.im/e/493b93a98ed03a010c4c 
    on_success: change # options: [always|never|change] default: always 
    on_failure: always # options: [always|never|change] default: always 
    on_start: false  # default: false 

Odpowiedz

15

Można ustawić zmienną środowiskową ADB_INSTALL_TIMEOUT na Travisa do wartości takich jak 8 minut, aby uniknąć tego problemu.

Na przykład w swoim .travis.yml:

language: android 
jdk: oraclejdk7 
# Turn off caching to avoid any caching problems 
cache: false 
# Use the Travis Container-Based Infrastructure 
sudo: false 
env: 
    global: 
    - ANDROID_API_LEVEL=21 
    - ANDROID_BUILD_TOOLS_VERSION=21.1.2 
    - ANDROID_ABI=armeabi-v7a 
    - ADB_INSTALL_TIMEOUT=8 # minutes (2 minutes by default) 

android: 
    components: 
    - platform-tools 
    - tools 
    - build-tools-$ANDROID_BUILD_TOOLS_VERSION 
    - android-$ANDROID_API_LEVEL 

ShellCommandUnresponsiveException jest związane AOSP issue 69735: Ddmlib is too agressive with timeouts in Device.java, co powoduje ddmlib do Timeout szybko, jeśli nie otrzyma wejście. Powyższa zmienna środowiskowa wydłuża ten okres czasu na maszynie Travis VM.

Upewnij się również, że używasz najnowszego zestawu SDK poziomu API i narzędzi do kompilacji (przynajmniej wersja powyżej), ponieważ wcześniejsze wersje nie zezwalają na ustawianie tej zmiennej środowiskowej.

Należy pamiętać, że może to rozwiązać problem tylko wtedy, gdy testy czasami przechodzą na Travis - jeśli kompilacja zawsze kończy się niepowodzeniem, mogą wystąpić inne problemy.

EDIT marca 2016

Należy pamiętać, że jeśli nadal widząc porażki, zwłaszcza na poziomie API 23 emulator, emulator jest inny problem, że czas oczekiwania może być przyczyną Ci problemów.

Aby obejść ten problem, musisz zaktualizować wtyczkę Gradle przynajmniej 2.0.0-beta3 - na przykład:

dependencies { 
    classpath 'com.android.tools.build:gradle:2.0.0-beta5' 
} 

Szczegółowe informacje patrz:

+3

Przyjechałem tutaj przez wyszukiwarkę Google, każdy, kto to widzi; znasz poprawkę do tego w CircleCi? Otrzymanie tego samego błędu, ale nie mam pojęcia, jak to naprawić w CircleCi –

+0

@RED_ Możesz ustawić tę samą zmienną na CircleCI: https://circleci.com/docs/configuration#modifiers – Peeja

+2

Dzięki, ale zrobiłem to wiele innych rzeczy. Nawet CircleCi mówią, że teraz nie mają na to rozwiązania. może po prostu przenieść się do Travis. –

Powiązane problemy