HeadSpin Appium Capabilities

In addition to the standard Appium capabilities^1 (including each driver specific capabilities) and the W3C WebDriver spec^2, the Appium server running on each HeadSpin host supports a number of custom capabilities below. In addition, the HeadSpin Appium load balancer running in the cloud supports additional capabilities that control device selection and redundancy.

Unless otherwise stated, these capabilities work for any Android, iOS, or TV device in the pool.

Supported drivers

HeadSpin supports

Host capabilities

Note, that HeadSpin allows <code class="dcode">deviceName</code> to be blank in the capabilities and will automatically use the device <code class="dcode">udid</code> instead.

Appium session

HeadSpin session and capture

Apps

If <code class="dcode">appium:app</code> capability has http/https scheme, and the URL has <code class="dcode">.ipa</code> extension name, HeadSpin's provisioning profile will be applied by default to avoid possible installation failure. <code class="dcode">headspin:app.resign</code>, <code class="dcode">headspin:app.resignTimeout</code>, <code class="dcode">headspin:appId.resignIpa</code> and <code class="dcode">headspin:appId.resignIpaTimeout</code> capabilities can handle the resigning as same.

TV devices

TV devices support limited capabilities as below.

HeadSpin commands

These HeadSpin commands are designed to be run by the Execute Mobile Command interface.

<code class="dcode">app</code> standard Appium capability

HeadSpin drops the <code class="dcode">app</code> capability when <code class="dcode">*</code> is provided as the value.

The value <code class="dcode">*</code> is invalid for standard Appium, but some Appium client tools require the app capability even when it is not necessary. In these cases you can set * as the value to establish an Appium session using another capability.

<code class="dcode">appium:autoLaunch</code> and <code class="dcode">headspin:capture.autoStart</code>

Appium uses an <code class="dcode">appium:autoLaunch</code> capability to control if Appium launches the application under test. This is documented in the Appium documentation for creating a new session. The application under test launches when the capability is <code class="dcode">true</code>. The default is <code class="dcode">true</code>.

When <code class="dcode">appium:autoLaunch</code> is false, Appium does not launch the application under test automatically in creating a new session. Then, you are responsible for launching the application under test manually with one of Launch App, Activate App, Reset App or a few mobile commands. HeadSpin session capture starts when Appium receives one of these commands.

If you have a scenario where you need to launch the application under test without the standard application launch commands, for example, when you test a Progressive Web Application (PWA) on iOS, then HeadSpin session capture does not start automatically as described above. Instead, you can combine the <code class="dcode">"appium:autoLaunch"</code>: false capability with the <code class="dcode">"headspin:capture.autoStart"</code>: <code class="dcode">true</code> capability to start HeadSpin capture anyway. Then you may launch the application under test in any available manner, for example, by tapping the PWA application icon on the home screen.

Setting the Appium Version

New Appium versions are made available to customers as soon as they are certified on the platform. HeadSpin works with the Appium team to test and provide new versions ^3. A few select versions are available on every host by default. You can always confirm what versions are available in a host via the version API below. Please contact us if you need a specific version that is not in the result.

You should always set <code class="dcode">headspin:appiumVersion</code> to the version you are using, to avoid changes related to system updates in the future.

Appium 2.0 support

HeadSpin supports Appium 2.0 and drivers, which are available over Appium 2.0. The session needs to specify Appium 2.0 with <code class="dcode">headspin:appiumVersion</code> right now, such as <code class="dcode">"headspin:appiumVersion": "2.0.0-beta.53"</code>. The available Appium versions and driver versions are listed in the result of Check available Appium versions below. The default keys/values in the drivers are the default driver version for each <code class="dcode">appium:automationName</code> session.

Check available Appium versions

HeadSpin host provides the list of available Appium versions as API. It helps to confirm which Appium versions can run on the host machine. Please contact us if you want to use a particular Appium version which is not available on the host machine.

The minimum supported version is <code class="dcode">1.11.0</code>.

Example

curl -X GET https://proxy-jp-tyo-1.headspin.io:7001/v0/{your-api-token}/wd/hub/versions

Response

{
    "status": 0,
    "session_id": null,
    "value": {
        "default": "1.22.3",
        "available": ["1.21.0", "2.0.0-beta.53", "1.22.3"],
        "drivers": {
            "default": {
                "xcuitest": "4.12.1"
            }
        },
        "plugins": {
            "default": {}
        }
    }
}

The <code class="dcode">available</code> is available Appium versions. You can specify them as <code class="dcode">headspin:appiumVersion</code>. The <code class="dcode">default</code> is chosen if a create session capabilities has no <code class="dcode">headspin:appiumVersion</code>.

The <code class="dcode">default</code> in the <code class="dcode">drivers</code> is the pairs of <code class="dcode">appium:automationName</code> and the available version on the host. The pair will be used when you create a new session with the Appium 2.0 as <code class="dcode">appiumVersion</code>.

Please contact us if you would like to use a version which is not in the list.

Setting <code class="dcode">appiumOptions</code> for Appium 2

<code class="dcode">headspin:appiumOptions</code> capability is available to configure the Appium server in a session, using the capabilities suggested by the Appium team for providers supporting Appium 2.0*.

Available keys

Example

{
    "headspin:appiumOptions": {
        "version": "2.0.0",
        "plugins": ["images", "relaxed-caps"]
    }
}

Without <code class="dcode">headspin:appiumOptions</code>, you also can specify them as individual HeadSpin Appium capabilities.

• <code class="dcode">version</code> works as same as <code class="dcode">headspin:appiumVersion</code>
• <code class="dcode">plugins</code> works as same as <code class="dcode">headspin:appiumPlugins</code>

The individual capabilities will take priority over those inside <code class="dcode">headspin:appiumOptions</code>. For example, if a capabilities set has both <code class="dcode">"headspin:appiumOptions": { "version": "2.0.0" }</code> and <code class="dcode">"headspin:appiumVersion": "1.22.3"</code>, the session will use Appium 1.22.3 provided as <code class="dcode">headspin:appiumVersion</code>.

Network Config

User Flow Status

To mark sessions passed, failed, or in some error state, you can either use a HeadSpin Appium command to end the session, or use the Performance Monitoring API at any time. In either case, the session must be attached to a user flow by specifying <code class="dcode">headspin:testName</code> (this in turn requires that capture is turned on for the session, see description in the Appium capabilities section).

Valid user flow status strings are: <code class="dcode">passed</code>, <code class="dcode">failed</code>, <code class="dcode">excluded</code>, and <code class="dcode">not_set</code>.

Set user flow status using the <code class="dcode">headspin:quitSession</code> command

1. Set <code class="dcode">headspin:testName</code> when starting the session. This is required for the next step to work.
2. End the session by sending the command <code class="dcode">headspin:quitSession</code> with the argument <code class="dcode">{"status": <user flow status>}</code>.

For example, the Python script below sets the session's status to <code class="dcode">excluded</code>:

from appium import webdriver

caps = {
    ...  # Other capabilities
    "headspin:testName": "test user flow",  # Required to link session to user flow
    "headspin:capture": True                # Required to have a capture session
}

driver = webdriver.Remote('<Web Driver URL>', caps)

# Perform tests
...

response = driver.execute_script('headspin:quitSession', {'status': 'excluded'})

This will end the session and set its user flow status at the same time. It can be used in place of the <code class="dcode">driver.quit()</code> command to end the session. When called without any argument, it has the same effect as <code class="dcode">driver.quit()</code>.

If the command is successful, there will be no return value (<code class="dcode">response is None</code> is <code class="dcode">True</code>). However, if an argument is given but it could not be processed into a valid user flow status, then a string containing information about the problem will be returned. The session will still end, but no user flow status will be set.

Set user flow status using Performance Monitoring API

1. Set headspin:testName when starting the session, or link the session to a user flow after it has started using the Performance Monitoring API.
2. POST to the Performance Monitoring API to set the status of the session, using the session ID from the driver.

For example, the Python script below sets the session's status to <code class="dcode">passed</code> using <code class="dcode">requests</code> to post to the API:

from appium import webdriver
import requests

# Start a session with capture
driver = webdriver.Remote(...)

# Set api_token in the header
headers = {
    'Authorization': 'Bearer <your_api_token>'
}

perf_data = {
    'session_id': driver.session_id,
    'status': 'passed'
}
requests.post('https://api-dev.headspin.io/v0/perftests/upload', headers=headers, json=perf_data)

BYOD and <code class="dcode">appInstallStrategy</code>

Bring Your Own Device allows you to add your own devices to HeadSpin platform. You can run appium sessions against the devices, but the application installation might fail in iOS for some reason. You can try the Appium capability <code class="dcode">"appium:appInstallStrategy": "ios-deploy"</code> to help complete the installation successfully.

Resolving Errors

HeadSpin Appium sessions return errors directly from the underlying Appium driver without modification. Additionally, the HeadSpin platform may return the following extra errors: