When an Android emulator macro does not move, the visible symptom is often the same: no next tap, no new screen, and no completed routine. The cause can still be very different. A macro may have failed before execution, be waiting because a condition is false, be recovering its emulator connection, or have stopped after an unrecoverable action error.
EmuloAgent treats those cases differently. It does not stop a whole routine just because an image was not found once, but it does block a start when the macro and emulator resolutions are incompatible. It can also keep trying after a temporary screen-capture failure and stop when continuing would be unsafe.
This guide gives you a practical diagnosis order so you can fix the failing layer instead of changing thresholds, delays, and profiles at random.
First identify when the macro stopped progressing
Before editing the automation, place the symptom in one of these stages:
- It never started: the profile or macro could not pass the startup checks.
- It started but keeps waiting: the runner is active, but the current conditions do not release an action.
- It lost contact with the emulator: EmuloAgent cannot capture a current frame and is trying to reconnect.
- It stopped after an explicit error: an action reported a fatal problem or the runtime accumulated internal errors.
- You stopped it on purpose: a Stop command ends the current run and is not a product failure.
Do not use one fix for all five. A looser image threshold cannot repair an ADB connection, and reconnecting ADB cannot make a reference captured at the wrong resolution reliable.
If the macro never started, check profile and resolution
EmuloAgent checks the environment before entering the macro loop. Startup can end in a failed state when:
- the selected profile has no detected resolution;
- the saved macro cannot be loaded;
- the macro was calibrated at one resolution and the emulator is currently running at another.
The resolution check is deliberate. Coordinates, capture regions, and reference images are tied to a pixel layout. Running a macro calibrated at 960x540 against a different frame size would spend time looking in the wrong places and could send a tap to an unintended area.
Confirm the resolution shown by the emulator, then open the profile for editing. If the emulator should keep the macro’s original size, restore that size before starting again. If the new resolution is intentional, open the Macro Builder with that profile and recapture or review the visual references for the new layout.
If EmuloAgent does not detect the emulator at all, use the MuMu, BlueStacks, LDPlayer, and Nox connection guide before changing the macro.
If it keeps waiting, inspect the current condition
A macro that is still running but does not act is not necessarily frozen. Each action can wait behind image, image-count, text, color, profile, or variable conditions. When the condition is false, the action is skipped and the loop continues looking at the screen.
Start with the first observable difference:
- Is the emulator on the screen the action expects?
- Does the captured image still match the current theme, language, and scale?
- Is the detection region covering the target’s current position?
- Does the text include punctuation or spacing that changed?
- Is the color sampled from a stable part of the interface?
- Is the action restricted to a different profile?
Test the smallest suspect step from the Macro Builder on the current screen. If it works alone, reproduce the steps immediately before it. The earlier action may be leaving the emulator in another state even though the suspect action is configured correctly.
The image, color, and text detection guide helps you choose a stronger signal. Change one variable at a time; lowering every threshold hides the original fault and can create false matches.
A normal action failure does not stop the whole macro
This distinction prevents a common misdiagnosis. In EmuloAgent, an ordinary action failure—such as a reference image not being found—does not automatically pause the complete routine. The result is recorded as a warning, the flow continues according to its structure, and the macro can begin another loop.
That behavior is useful for screens that are optional or temporary, but it also means a weak flow can look busy without making progress. For important transitions, model both sides:
- protect the action with a condition that proves the target screen is ready;
- perform the action;
- add a later check that proves the screen changed;
- define what the macro should do when that confirmation never appears.
Do not rely on “the action was attempted” as proof of success. Use an observable post-action state.
If the emulator stops responding, let reconnection do its job
Screen capture is the feedback loop for visual automation. If EmuloAgent cannot obtain a frame repeatedly, it warns that the emulator is not responding and continues trying to reconnect. When capture succeeds again, the failure streak is cleared and execution can continue.
While it is recovering, check the environment without rebuilding the macro:
- confirm that the emulator process and the intended instance are still open;
- verify that the profile points to the correct ADB host and port;
- avoid restarting several emulator instances at once;
- check whether the host is under heavy CPU or memory pressure;
- keep the emulator resolution unchanged during the run.
If the connection returns, confirm the app is still on a state the macro recognizes. Reconnection restores screen access; it does not restore the Android app to the screen that was visible before the interruption.
If EmuloAgent stops after an error, read the reason before restarting
Some failures are explicitly fatal because blindly continuing would be unsafe or pointless. Implemented examples include a Virtual Keyboard action without a password for the active profile, missing digit references, a password that cannot be decrypted, repeated keyboard-solver failures, or an unavailable OCR engine required by a text action.
Internal runtime exceptions and detector timeouts can also open the safety circuit after repeated failures. In that case, EmuloAgent stops the current execution and includes the profile and available reason in its diagnostic message.
Open the logs at %APPDATA%\EmuloAgent\logs\ and search from the end of the newest file for the profile name and the first error before the stop. Later messages are often consequences. When a fatal action has a current screenshot, EmuloAgent also attempts to save a failure capture and records its path in the diagnostic entry.
Use the message to choose the repair:
- missing template or digit: recapture the reference in the correct resolution;
- password missing for this profile: edit the Virtual Keyboard action and register the secret for that profile;
- OCR unavailable: repair or update the EmuloAgent installation instead of replacing text checks with blind taps;
- resolution mismatch: align the emulator with the macro or recalibrate the macro;
- repeated internal error: preserve the log and failure capture when contacting support.
After fixing the cause, start a new controlled run. A fatal stop is a boundary for the current execution, not an instruction to keep pressing Play without changing anything.
Practical example: a confirmation button never advances
Suppose a QA-support macro waits for a Continue image, clicks it, and should then see a dashboard title.
Diagnose it in order:
- Confirm that the macro actually started and passed the resolution check.
- Put the emulator on the expected confirmation screen.
- Test the Continue image condition by itself.
- If it fails, inspect the saved crop, search region, theme, language, and current scale.
- If the condition passes, test the click and observe whether the target moves or is covered by another element.
- Check the dashboard-title condition after the click.
- If the emulator stops producing frames, repair the connection rather than editing the image threshold.
- If execution stops with an explicit fatal reason, fix that reason and preserve the related log entry.
This sequence separates four layers—startup, detection, action, and runtime—so one correction does not create a new problem elsewhere.
Use a short checklist before the next run
- The emulator instance is open and the profile points to it.
- The emulator resolution matches the macro calibration.
- The app is on a known starting screen.
- The first blocked condition passes in an isolated test.
- The action produces a visible result, not merely a successful command.
- The next condition confirms that result.
- A disconnected emulator has returned to a recognizable screen.
- The first relevant warning or error was reviewed in the current log.
- Only one setting changed before the next test.
Once the fault is fixed, apply the macro stabilization checklist before pinning the automation to more profiles or leaving it in a longer run.
Diagnose the layer, then run again
A stopped-looking macro is not one generic failure. Startup checks protect incompatible profiles, conditions can keep an active flow waiting, capture recovery handles temporary emulator loss, and fatal errors end a run that should not continue unchanged. Identify the stage, verify one layer at a time, and restart only after addressing the recorded cause.