2

Я пытаюсь запустить calabash-android в трейвисе. calabash-android отлично работает в моей машине без проблем. У меня есть следующий travis.yml:calabash-android in travis

language: android 
jdk: oraclejdk8 
before_cache: 
    - rm -f $HOME/.gradle/caches/modules-2/modules-2.lock 
cache: 
    directories: 
    - $HOME/.gradle/caches/ 
    - $HOME/.gradle/wrapper/ 
    - $HOME/.gradle/daemon 
    - $HOME/.gradle/native 
env: 
    global: 
    # wait up to 10 minutes for adb to connect to emulator 
    - ADB_INSTALL_TIMEOUT=20 
    - SLAVE_AAPT_TIMEOUT=40 

android: 
    components: 
    - platform-tools 
    - tools 
    - build-tools-23.0.3 
    - android-23 
    - extra-android-support 
    - extra-android-m2repository 
    - extra-google-m2repository 
    - sys-img-armeabi-v7a-android-23 

before_install: 
    # install ruby 2.0.0 
    - rvm install 2.0.0 
    # install calabash-android 
    - gem install calabash-android 

before_script: 
    - echo no | android create avd --force --name test --target android-23 --abi armeabi-v7a 
    - emulator -avd test -no-skin -no-audio -no-window -no-boot-anim & 
    - android-wait-for-emulator 
    - adb shell settings put global window_animation_scale 0 & 
    - adb shell settings put global transition_animation_scale 0 & 
    - adb shell settings put global animator_duration_scale 0 & 
    - adb shell input keyevent 82 & #for unlocking as "powerkey" 
    - sleep 3 # give screen some time to become unlocked 
    - ./gradlew clean assembleDebug -PdisablePreDex --continue --stacktrace 

script: 
    - calabash-android resign /home/travis/build/app/build/outputs/apk/app-debug.apk 
    - calabash-android run /home/travis/build/app/build/outputs/apk/app-debug.apk 

Он работает с 1-го сценария функции, а затем, как только он начинает 2-ой сценарий, он показывает эту ошибку:

App did not start (RuntimeError) 
./features/support/app_life_cycle_hooks.rb:5:in `Before' 

Любые идеи? или предложение?

+0

Могло быть много причин, по которым приложение не запускается. Я предлагаю запустить adb logcat, пытаясь запустить его, чтобы узнать, в чем проблема. – Tobias

ответ

0

Удалить -no-boot-anim option, android-wait-for-emulator сценарий зависит от анимации загрузки, чтобы определить, когда эмулятор готов.

Это великое объяснение, которое я рекомендую: Detecting when emulator is ready to be used

The second step is to wait for emulator to fully boot, so it can be used to run some code. This turned out to be the most tricky part. Especially for emulators with API Level 11+ (11-14 at the time of writing).

First, emulator should connect to adb and will be listed as “offline”. In this state emulator does not accept any shell commands. And nothing can be done in this state. This part is usually very stable and I haven’t seen the case when emulator was started but never connected to adb. Of course if some error occurs, it won’t connect to adb. So timeout should be used here to detect abnormal delays or hangs.

Next state device goes to called “device” state. This is when device is booting. As soon as it had booted, device goes to “online” state. This is when system starts booting and normal operation of emulator goes in.

From the moment device goes to “device” state, adb shell can be used to execute different commands on device and query some useful information about its state.

I’ve found several properties that should be tracked in order to reliably detect when device is ready. The first property is called dev.bootcompleted. As soon as device completes booting this property will be set to 1.

After dev.bootcompleted is 1, next property called sys.boot_completed should be tracked. It will be set to 1 as soon as system completed booting (this is usually when BOOT_COMPLETED broadcast is sent). This property is only set on emulators with API Level 9 or higher. On 8 and lower this property is never used (and shouldn’t be tracked).

But emulator is still not ready, even when sys.boot_completed is set to 1. You’ll notice that boot animation will still run for some (significant) period of time. And only then UI will appear. But luckily there is a way to detect this event too. For this we need to track value of init.svc.bootanim property. This property keeps state of boot animation service, that will be stopped as soon as UI appears. In other words, as soon as init.svc.bootanim has value stopped, its safe to assume that emulator is running and ready to be used.

Использование -no-boot-anim значение stopped, прежде чем ваш эмулятор полностью загружен:

# Originally written by Ralf Kistner <[email protected]>, but placed in the public domain 

set +e 

bootanim="" 
failcounter=0 
timeout_in_sec=360 

until [[ "$bootanim" =~ "stopped" ]]; do 
    bootanim=`adb -e shell getprop init.svc.bootanim 2>&1 &` 
    if [[ "$bootanim" =~ "device not found" || "$bootanim" =~ "device offline" 
    || "$bootanim" =~ "running" ]]; then 
    let "failcounter += 1" 
    echo "Waiting for emulator to start" 
    if [[ $failcounter -gt timeout_in_sec ]]; then 
     echo "Timeout ($timeout_in_sec seconds) reached; failed to start emulator" 
     exit 1 
    fi 
    fi 
    sleep 1 
done 

echo "Emulator is ready" 

Теперь я недоумевал из-за первый сценарий работает (я никогда не использовал calabash-android), но я вижу, что он не зависит от готовности эмулятора:

calabash-android - What does resign do?

The resign is used if you need to sign the app to match your keystore. Copied from GitHub docs https://github.com/calabash/calabash-android/wiki/Running-Calabash-Android

Instead of resigning you could also consider copying your debug keystore to your folder.

The apk calabash android runs must be signed with the same keystore as the test-server.

Use the command: calabash-android resign <apk> to resign your application.

Building the test-server using calabash-android build will build the test-server and sign it with the same key as the application you are testing.

Второй сценарий делает это:

Running test

To run your test: calabash-android run <apk>

Calabash-android will install an instrumentation along with your app when executing the app. We call this instrumentation for "test server". The "test server" has special permission that allows it to interact very closely with your app during test. Everytime you test a new binary or use an upgraded version of calabash a new test server will be build. The test server is an intrumentation that will run along with your app on the device to execute the test.

Возможно, существуют и другие проблемы, в этом случае, но fixed the same issue here удаление -no-boot-anim.