Full embrace of mobile testing, the mobile JSON wire Protocol Specification document translation

SELENIUM3 has announced that it does not support mobile testing. This is to retreat for the veteran test tool selenium, as the standard for mobile automation testing tools is still in the hands of the selenium team.

This article mildly translates this standard, the person who can see understands not to have the translation also to understand, cannot understand the person to turn the hype is also confused.

Note that this specification is for the developer of the tool to define the rules, for the user, as long as they know what must be supported by the tool, and the details of what is supported, others can not go into the drill.

This title is not translated by mobile JSON Wire PROTOCOL specification

Source Address

DRAFTDraft (note that this is a draft, which means it will change) Introduction introduction

The following paragraph is to the effect that the previous Jsonwireprotocol now needs to be expanded. Because of the need to support mobility.

This specification was designed to extend the JSON wire
Protocol (JSONWP),
A working draft for Web browser automation. The JSONWP has been greatly
Successful for that purpose. The need for automation of native and hybrid
Mobile applications can is met by the extension of the JSONWP, which already
Has a proven basic automation framework (architecture, Interaction model,
Etc ...).

The original version was created by the following herd of cows in Mozilla's office.

The initial details of this specification were worked off at a series of
Meetings held in Mozilla's offices in London in August of 2013. The
Participants were:

• David Burns (Mozilla)-Website-twitter
• Dominik Dary (EBay)-Website-twitter
• Jonathan Lipps (Sauce Labs)-Website-twitter
• Jason? (Facebook)-Website-twitter
• Fran?ois Reynaud (EBay)-Website-twitter
• Simon Stewart (Facebook)-Website-twitter
• Santiago Suarez Ordo?ez (Sauce Labs)-Website-twitter

Sessions session

Like Webdriver, post/session this URI, and then the server returns you a SessionID.
And then through this sessionid, you can take the push and do whatever you please.

If the server is not able to start session, then the returned status code is 500.

The session is destroyed by Delete/session/:id this URI, as with Webdriver.

The following paragraph is about AUT, which is interested in self-research.

Sessions work just like Webdriver:you POST to/session and receive a sessionId
as a response if the server can give You can send
further automation commands to which point. If the server can ' t start a session, for example
if another session was running and only one session can being handled at a Time,
The server must return the appropriate response. Sessions is ended with
a DELETE to/session/:id as per the original Webdriver spec.

The server may and is not required to launch the AUT, or a device/simulator in
The process of creating a session. Required to perform some
Kind of cleaning or resetting of the AUT in order to provide a clean test
Environment. It may but isn't required to stop the running AUT at the session
End. Required to remove the AUT from the device or otherwise
Reset the device state after the session was complete. In general, it's the
Responsibility of the user to manage the test environment; It isn't a part of
This specification. But the a server conforming to this specification
means provide that functionality as a convenience.

Desired capabilities don't know how to turn, anyway is to do configuration

There's a new key.

• automationName: Used to specify a test tool, yes appium ? Or is it? ios-driverselendroid
• platformName: Test platform. e.g., Android ,iOS
• platformVersion: Platform version e.g., 4.3 (for Android) or 6.1 (for IOS)
• deviceName: Test the device name for version information. , e.g.,,,, Nexus 4 iPhone 4S iPhone SimulatoriPad Mini
• app(optional): The path or URI of the AUT
• browserName(optional): The browser, in fact, is the webdriver session, e.g., SafariChrome

New desired capability keys:

• automationName: Specific automation tool, e.g.,,,, appium ios-driverselendroid
• platformName: platform to automate, e.g.,, AndroidiOS
• platformVersion: Platform version e.g., 4.3 (for Android) or 6.1 (for IOS)
• deviceName: Specific device names including version information, e.g.,,,, Nexus 4 iPhone 4S iPhone SimulatoriPad Mini
• app(optional): path or URI to AUT
• browserName(optional): Web browser to automate as a webdriver session, e.g., SafariChrome

Locator strategies new positioning strategy, focusing on

For non-HTML platforms, the following policies are required to be supported.

• class name: Just a string, which is actually the class name of the control in the SDK. Note that you need to bring the package name to Android. , e.g., for UIAPickerWheel IOS or for android.widget.Button Android
  • These should match exactly the class name provided by the Infrastructure automation framework (via Google Translate)
• accessibility id: is a string that represents an accessible ID or a label for an element. , e.g., for IOS the accessibility identifier and for Android the Content-description
• xpath: Old acquaintance, not wordy

The following locator strategies must is supported for non-html-based platforms:

• class name: A string representing the UI element type for a given platform, e.g., for UIAPickerWheel IOS or for android.widget.Button Android
  • These should exactly match the class names given by the underlying automation frameworks
• accessibility id: A string representing the accessibility ID or label attached to a given element, e.g., for IOS the accessibility identif Ier and for Android the Content-description
• xpath: A valid XPath string applied to the XML document this would be retrieved using the page Source command

The following are optional, that is to support the support, do not want to forget

The following locator strategies may is supported, depending on the automation
Platform

• id: String that represents the resource ID of the object
• -android uiautomator: string, which is the Uiautomator locator (Android only)
  • TODO: specifically describe
• -ios uiautomation: string, which is UIAutomation locator (ios-only)
• TODO: Indicate whether the server needs to indicate that it supports these policies.

If you are using Webdriver mode or a platform that uses HTML, you need to support Webdriver's positioning strategy. No wordy.

• id: A string corresponding to a resource ID
• -android uiautomator: A string corresponding to a recursive element search using the Uiautomator library (Android only)
  • Todo:specify this
• -ios uiautomation: A string corresponding to a recursive element search using the UIAutomation library (ios-only)
• Todo:figure out whether server should report support of these strategies

If Automating a mobile browser in Webdriver mode, or a platform that uses HTML
As its element hierarchy, the usual array of WEBDRIVER commands must is
Supported instead, with their usual semantics.

Page source pages source code, really farfetched

All platforms must support the get Source command. Returns the XML (HTML) that represents its UI level.

The others do not turn over.

All platforms must respond to the GET source command with a XML (or HTML in
The case of Html-based platforms) document representing the UI hierarchy. The
Precise structure of the document may differ from platform to platform. Schemas
That must is followed for IOS and Android Automation is as follows:

Todo:get together schemas for UIAutomation (IOS), Instruments (Android), and
Uiautomator (Android).

The elements in these documents is augmented with such attributes as, for
example, IDs, in order-to-support internal behaviors.

Touch gestures gestures

All platforms support the Multi-Action API proposed by Mozila (who can tell me how to flip), and in some cases, if not, return 500 directly.

All platforms must adopt the Multi-Action API pioneered by Mozilla. In some
Cases it won't be possible to support the full range of gestures potentially
Described by the this API on a given platform. In this case, the platform should
Respond with a when it cannot faithfully render the requested gesture.

Todo:show What is the gestures API actually looks like in terms of server
Endpoints that must is supported.

Device Modes Devices mode

The device has a lot of network connection status, in order to be able to control accurately, we provide the following endpoints.

• Get/session/:sessionid/network_connection
  • Back to ConnectionType
• Post/session/:sessionid/network_connection
  • Accept a ConnectionType
  • Back to ConnectionType

Remote terminal must be the corresponding "networkconnectionenabled" this capability.

Others see for themselves.

Devices has various states of network connectivity. In order to control
Those states we have the following endpoints:

• Get/session/:sessionid/network_connection
  • Returns ConnectionType
• Post/session/:sessionid/network_connection
  • Accepts a ConnectionType
  • Returns ConnectionType

Setting the network connection in the POST returns the ConnectionType because
The device might not being capable of the network connection type requested.

The remote end must reply with the capability "networkconnectionenabled"

ConnectionType-Connection Type

Here is the specific value specified, can not understand.

Value (Alias) | Data | Wifi | Airplane Mode

1 (Airplane Mode) | 0 | 0 | 1
6 (All network on) | 1 | 1 | 0
4 (Data only) | 1 | 0 | 0
2 (Wifi only) | 0 | 1 | 0
0 (None) | 0 | 0 | 0

If it is airplane mode, then return:

{"Name": "Network_connection", "parameters": {"type": 1}}

More types, such as 3g,4g,lte, will be supported in the future.

is a bit mask this should be translated to an integer value when serialized.

Value (Alias) | Data | Wifi | Airplane Mode

1 (Airplane Mode) | 0 | 0 | 1
6 (All network on) | 1 | 1 | 0
4 (Data only) | 1 | 0 | 0
2 (Wifi only) | 0 | 1 | 0
0 (None) | 0 | 0 | 0

Example payload for setting "Airplane Mode":

{"Name": "Network_connection", "parameters": {"type": 1}}

Data is the upper bits since in the future we may want to support setting
Certain types of Data the device is capable of. For example 3G, 4G, LTE.

Other Device Features

Mobile devices has a variety of sensors and input methods. These is automated
as follows:

• The virtual Keyboard:use SendKeys
• Acceleromator:todo @MDAs is working on this
• Geolocation:use Regular Webdriver Endpoints
• Rotation (different from orientation): TODO
• Battery Level:not in spec, perhaps exposed via executescript
• Network Speed:not in spec, perhaps exposed via executescript

Webviews and other contexts

One common feature of mobile platforms is the ability to embed a chromeless
WebBrowser inside of a ' native ' application. These is called ' Webviews ', and,
If possible, a server for a given platform should implement
Automating the webview using the full, regular, Webdriver API.

This creates a situation where there is the potential contexts for automation
In a given aut:the native layer and the webview layer. If providing WebView
Support, the server must has the following endpoints:

• Get/session/:sessionid/contexts
  • Returns an array of strings representing available contexts, e.g. ' WEBVIEW ', or ' NATIVE '
• Get/session/:sessionid/context
  • Returns one of:
  • A string representing the current context
  • null, representing the default context ("no context")
• Post/session/:sessionid/context
  • Accepts one of:
  • A string representing an available context
  • null, signifying a return to the default context

The first endpoint must return a possibly-empty array of strings. Each string
Must be the arbitrary name of a available context, e.g., one of possibly
Multiple webviews. The second must interpret the body of the request as the
Name of an available context. If that context isn't found, a nosuchcontext
Error must be returned. If the context is available, the server must switch
Automation to that context, such this all subsequent commands is taken to
Apply to that context. If null the body of the POST is, the server must
Return to the original context.

If a server receives a request at an endpoint which was valid in some context
But isn't the currently active context (for example if a user calls
driver.get()In a native context instead of a webview context), the server
Must respond with an invalidcontentexception.

Waiting for Conditions

The server must respond to the management commands for implicit wait timeouts,
such that if a user sets an implicit wait timeout and tries to find an
Element (s), the server keeps trying to find the element (s) until that timeout
Expires, rather than responding with the first failure to find the element (s).

Todo:figure out, what the serversidewait implementation would be
It.
Hide Details
Change Log
2A302804FC1D by Luke Inman-semerau linman-s ... @Salesforce.com on May 5, Diff
Using "Network_connectivity" Enpoint
Instead of toggling just airplane mode

Passing a ' bitmask ' for the types of
Network Connectivity Desired
Go to:

Double Click a line to add a comment
Older revisions
7a8d40f61557 by Jonathan Lipps <jlipps> on APR 2, Diff
Ba61c96e26c8 by Jonathan Lipps <jlipps> on Mar, Diff
5432d87357e0 by Jonathan Lipps <jlipps> on Feb, Diff
All revisions of the This file
File Info
size:9179 bytes, 198 lines
View Raw File