calabash-android within travis

问题

I am trying to get calabash-android running within travis. calabash-android works fine within my machine without any problems. I have the following 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

It works with the 1st scenario of the feature and then once it starts 2nd scenario, it shows this error:

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

Any ideas? or suggestion?

回答1:

Delete -no-boot-anim option, android-wait-for-emulator script depends on boot animation to detect when the emulator is ready.

This is a great explanation I recommend: 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.

Using -no-boot-anim the value is stopped before your emulator is fully-booted:

# 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"

Now I was doubting due to the first scenario works (I never used calabash-android) but I see that it doesn't depend on the emulator being 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.

The second scenario does it:

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.

Perhaps exist other issues in this case but fixed the same issue here deleting -no-boot-anim.

来源：https://stackoverflow.com/questions/38446407/calabash-android-within-travis

标签

android

continuous-integration

travis-ci

calabash-android