Manually configurable emulator booting timeout

[Ioseph Knecht]

Problem
Marathon CLI hardcoded on its side timeout of waiting for the emulator boot state in 30 seconds.
This works fine locally, but on CI it periodically crashes with DeviceSetupException.

Solution
I would like to explicitly declare a timeout somewhere in configuration file to wait for emulator boot state.

For example, so:

---
name: "Marathon"
# omitted lines
vendorConfiguration:
  type: "Android"
  timeoutConfiguration:
    shell: 180.000000000
    listFiles: 20.000000000
    pushFile: 60.000000000
    pushFolder: 60.000000000
    pullFile: 30.000000000
    uninstall: 20.000000000
    install: 20.000000000
    screenrecorder: 200.000000000
    screencapturer: 0.300000000
    socketIdleTimeout: 30.000000000
    portForward: 20.000000000
    #declare booting timeout
    deviceBooting: 180.000000000

Workaround solution
At the moment, when running on CI, we poll the sys.boot_completed flag in bash scripts ourselves, and only after we make sure that all emulators have switched to boot state can we launch marathon.

In scripts, it looks something like this:

// https://stackoverflow.com/questions/41151883/wait-for-android-emulator-to-be-running-before-next-shell-command
adb wait-for-device shell 'while [[ -z $(getprop sys.boot_completed) ]]; do sleep 1; done;'

Additional context
Interestingly, in marathon version 0.7.6, such an error was practically not reproduced, probably because when setuping device, DeviceSetupException exceptions were not thrown before.
The problem started reproducing with move to marathon 0.8.2 and higher.
It was in marathon 0.7.6
It became a marathon 0.8.0+

[Anton Malinskiy]

To clarify the logic:
There is deviceInitializationTimeoutMillis timeout which is used during the first initial action on any device. If you don't use remote parsing, then this will be the timeout until one of the devices is booted. It is not the timeout of waiting to boot, though, it's just a timeout to wait for any device to be ready for test execution.

If you are using a remote parser then since a device is required for parsing tests deviceInitializationTimeoutMillis is going to apply for borrowing a device for test parsing. If none of the devices are available after this timeout including for reasons of not booting - execution will fail.

The PR above adds boot timeout to the timeoutConfiguration. You might still need to adjust deviceInitializationTimeoutMillis depending on your circumstances.

[Ioseph Knecht]

@Malinskiy Great, thanks.