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.
The SUTAgent shall support at least the following commands. 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/).
- cd
- cwd
- dirw
- exec
- hash
- isdir
- ls
- mkdr
- ps
- pull
- push
- quit
- rebt
- rm
- rmdr
- testroot
- tmpd
- unzp