キャバレー・アンドロイド・イン・トラビス

Question

私はトラビス内でカラバッシュ・アンドロイドを走らせようとしています。 calabash-androidは問題なく私のマシンで正常に動作します。私は、次のtravis.ymlがあります

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 

それは機能の第一のシナリオで動作し、それが第二のシナリオを開始したら、それはこのエラーを示しています

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

任意のアイデア？または提案？

Answer 1

削除-no-boot-animオプション、android-wait-for-emulatorスクリプトは、エミュレータの準備ができたときに検出するブートアニメーションに依存します。

これは私がお勧め偉大な説明です：あなたのエミュレータが完全に起動する前に値がstoppedある-no-boot-animを使用して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.

：

# Originally written by Ralf Kistner <ralf@embarkmobile.com>, 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 - 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.

第2のシナリオはそれをしない：

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を削除します。