Build a Recoverable Android Game Automation Loop with State, Pause, and Resume

Description and use

Build a recoverable Android game automation loop by separating navigation, observation, and handling, using explicit state transitions, pausing before actions, bounded retries, and evidence capture.

Problem

Linear game automation macros fail when screen timing or target positions change, causing drift or missed actions.

Outcome

Automation becomes resilient to timing and target changes, reduces drift, and provides reproducible evidence for failures.

Workflow

• 1. Define a Navigation Map service with state, progress, and position data.
• 2. Implement a small state machine (idle, moving, paused, completed, stuck, lost, error).
• 3. In the orchestration loop, query router.status() to decide actions based on state and observations.
• 4. When a target is detected, pause navigation, re-observe if needed, handle the target, verify a concrete postcondition, then resume navigation.
• 5. Keep retries bounded at the narrowest layer with a maximum attempt count and exit state.
• 6. Separate stuck time from handling time so pauses and waits do not count as failures.
• 7. On lost or error states, capture evidence (screenshot, map ID, progress, position, confidence, etc.).
• 8. Test all edge cases: target during movement, invalid target after pause, pause without active route, duplicate continue, map switch, stop when idle, completion, confidence collapse, forbidden target, recovery success.
• 9. Use UI Automator’s performActionAndWait or similar condition-based synchronization instead of arbitrary sleeps.

Evidence

The fragile version of Android game automation is a long linear macro: move -> wait -> detect -> tap -> wait -> move -> repeat

Source

Use explicit state transitions

Source

Pause before acting on a moving screen

Source