Auto-tools/Projects/SUTAgent

Team

jmaher, mcote, wlach

Problem

Automated testing of mobile devices requires a platform-independent system-level interface with the device.

Goals & Considerations

The SUTAgent requires a simple network interface that can be used for access to the remove filesystem and processes.

Non-Goals

Functionality should be limited to basic building blocks as much as possible. It should be up to higher-level applications to do more complex operations using the lower-level features of the agent.

Design and Approach

The SUTAgent starts up when the device boots so that it is already running. If configured appropriately, it immediately connects to an agent server and sends a short description of the phone and agent. If it is restarting after a SUTAgent-initiated reboot (see below), it connects to a callback server to indicate that it is back up.

The SUTAgent maintains two open ports: a command port and a monitor port. The command port receives line-based commands and, depending on the command, returns data. The monitor port sends a periodic heartbeat and log messages. At a minimum, all command lines should be logged.

Logs are also kept in a file on the device and rotated periodically to ensure they don't take up too much disk space.

Note that, regardless of the device's platform, paths are always in POSIX format (using forward slashes). The SUTAgent is responsible for translating these to and from the native format (e.g. c:\dir\ might be translated as /c/dir/).

The SUTAgent shall also remember the current working directory for the duration of a command-socket connection. The default cwd is implementation-specific.

When errors are printed in response to commands, they should be of the form "##AGENT-WARNING## <detailed error message>".

See Auto-tools/Projects/SUTAgent/CommandReference for supported commands.

Implementation

See SUTAgentImplementation.