“Tap succeeded” proves that an input was delivered. It does not prove that the note saved, the form submitted, or the app reached the right account. A useful Android demo shows the result and enough evidence to explain how it got there.
Define the outcome before writing the action sequence. “Create a note containing a unique test string and find it again after reopening” is testable. “Show that the agent works” is too vague to fail.
Evidence at three layers
| Layer | Capture | What it establishes |
|---|---|---|
| Transport | HTTP status or MCP result | The service answered |
| Action | Per-action success/failure | An input ran or failed |
| Outcome | Observed saved state, screenshot when needed | The intended task actually completed |
Use screen text for structured assertions and screenshots for visual content absent from the accessibility tree. A screenshot alone may look convincing while omitting a failed save. A text tree alone may miss a chart, image, or canvas.
Make failure part of the demonstration
Run a missing-element case and inspect the returned error. Introduce a permission dialog. Park and resume before checking persisted state. Verify that the agent can recover from the actual app state without repeating destructive operations.
A polished replay should say that it is a replay. A live demo should identify its real device session and evidence. Do not present simulated screen transitions, an animation, or hardcoded success text as a current successful API run.
A small acceptance contract
- Use a known build and a disposable test account.
- Record the phone id, app package, and operation to verify.
- Observe before acting on unfamiliar state.
- Check every action result, including HTTP 200 responses.
- Reopen or revisit the saved outcome where practical.
- Park or delete the phone, including on failure.
For a disposable smoke test, opening Android Settings and reading a visible label proves the basic control path. It does not establish third-party app compatibility, performance under load, or hardware behavior. Add those checks only when you can run and document them.
The quickstart provides a runnable first loop. The error guide explains recovery. Keep the proof narrow enough to be true and useful enough to reproduce.