Use a fresh Android sandbox when a known starting state matters more than retained setup. Reuse a parked sandbox when saved app state is part of the task. Closing an app, uninstalling it, parking a phone and deleting a phone are different operations; none is a generic substitute for “reset”.
This distinction affects both correctness and cost. A returning-user test that accidentally starts fresh can lose the very login you meant to exercise. A first-run test on a reused phone can skip onboarding and permissions without telling you.
Name the state you want to keep
Before choosing a lifecycle operation, identify the relevant state: a running process, app data, installed packages, Android settings, or a record stored on a remote server. Ask which boundary the test is meant to cross.
| Operation | Useful purpose | Do not assume |
|---|---|---|
| close_app then open_app | Restart an app process and verify saved state | App data was erased |
| Park then start | Stop compute while retaining the phone’s stored data | Unsaved buffers or processes survived |
| Uninstall then install | Recreate an app’s local installation state | Remote account records were removed |
| Delete then create | Start with a different disposable sandbox | External services forgot previous actions |
The supported operations are documented in the API reference. Mobilebox does not expose an arbitrary public shell or a general clear-app-data endpoint. Choose among the actual lifecycle and app-management operations rather than inventing an ADB command in an agent prompt.
Prove that the app has saved
A visible text field is not necessarily persisted data. In our recorded Notes workflow, an immediate park after typing initially failed the later persistence assertion. The successful capture leaves the editor, terminates and reopens the app, verifies the note, then parks and resumes and verifies it again.
That is evidence for the specific app and sequence. It is not a guarantee that sending Home saves every application. Use the app’s explicit Save operation when available and verify through a fresh read. Android’s activity lifecycle guide distinguishes visible activity state, background lifecycle transitions and persistent storage; applications decide how they handle their own data.
{
"actions": [
{ "type": "home" },
{ "type": "close_app", "package": "your.app.package" },
{ "type": "open_app", "package": "your.app.package" }
]
}This illustrates a process-restart check. Replace the package, inspect each result and assert the actual saved value. Do not run it blindly while an important unsaved form is open.
Keep retained phones owned
A parked phone stops running compute, but it remains a retained sandbox with an owner and stored app data. Keep names meaningful, decide who may resume it and remove it when the task no longer needs that state. Default retained-phone limits still apply to parked phones.
Separate long-lived agent workspaces from disposable CI phones. Two keys in the same project share access to the same phones; they do not provide separate test inventories. Accidental reuse is a workflow problem to prevent, not something an agent should solve by guessing which phone is safe to reset.
Clean up the external side too
Deleting the Android sandbox does not delete an order, message, uploaded file or account record already created on a remote service. Use staging accounts and unique harmless markers. Define how those remote records will be removed or reconciled separately.
For a persistence-focused task, finish by checking both the saved result and the phone’s final state. For a disposable test, delete the phone in finally and inspect failures to delete. Read park and resume for lifecycle details and workflow evaluation for assertions that survive a fresh process.