How to combine AND and OR conditions in Android emulator macros

A visual macro becomes risky when one weak signal can release the wrong action. A button image may also appear in a menu, a color may be shared by two states, and the same label may exist in more than one dialog. Adding more conditions helps only when the relationship between them is explicit.

EmuloAgent lets each action combine image, image-count, text, color, profile, and variable conditions. The important part is deciding whether every condition must pass (AND), any condition may pass (OR), or one complete set of conditions may replace another. This guide turns those choices into a practical macro-building workflow.

Use automation only where the app, game, or service allows it. Logical conditions help control when an action runs; they do not change third-party rules.

Start with a sentence before opening the builder

Describe the gate in plain language. For example:

Tap Continue when the confirmation title is visible and the button is enabled.

That sentence has one AND group:

• text Confirmation is visible;
• the enabled-button image is visible.

Now consider a screen with two valid success messages:

Take a screenshot when Completed or Approved is visible.

That is one OR group. The action can run as soon as either text condition passes.

Writing the sentence first prevents a common error: placing related checks in separate groups and accidentally turning them into alternatives.

Understand the three levels of logic

EmuloAgent displays an AND/OR badge for each condition group. Selecting that badge changes how the conditions inside the group are evaluated.

• AND inside a group: all conditions in that group must pass.
• OR inside a group: one condition in that group is enough.
• OR between separate groups: one entire group or another may pass. The builder displays an OR label between them.

The third rule is easy to overlook. If you create Group 1 with title visible AND button enabled, then create Group 2 with fallback image visible, the action means:

(title visible AND button enabled) OR fallback image visible

Separate groups are useful for genuinely different valid screen states. They should not be used just to make a card look more organized.

How to create an AND group

Use AND when every signal is required to identify a safe state.

1. Open the macro and locate the action you want to guard.
2. Choose Add condition on the action.
3. Create a new condition or reuse an existing condition from another action.
4. Configure the first signal, such as the confirmation title detected by text.
5. Choose Add condition again and configure the second signal, such as the enabled button detected by image or color.
6. Leave the group badge on AND.
7. Save the macro and test the action on the expected screen.

The action does not run if either check fails. That makes AND appropriate for destructive taps, confirmations, submissions, or any step where one visual clue is not specific enough.

For better detection choices, use image, color, and text according to the signal each one represents. Logic cannot compensate for a poorly selected template or an ambiguous OCR region.

How to create an OR group

Use OR when several signals independently mean the same action is valid.

Imagine that an app shows either Finished or Completed after the same process. Add both text conditions to the same group, then select its badge to change AND to OR. The action may run when either label is found.

Keep the consequences equivalent. If one signal means success and another means error, placing them in one OR group hides an important distinction. Use separate actions so each state receives the correct response.

How to add an alternative group

Choose Add condition (New Group) when the action has another complete valid route.

For example, a Continue tap may be allowed in either of these states:

• Group 1: dialog title is visible AND enabled-button image is visible;
• Group 2: compact-dialog image is visible AND profile equals small_resolution.

EmuloAgent evaluates the groups as alternatives. Group 2 does not weaken Group 1; it defines another complete way to admit the same action.

This is different from creating one OR group with all four conditions. A flat OR would allow the action when only the profile matches, even if the compact dialog is absent. Group boundaries preserve the required pairs.

Use a subgroup for a condition with alternatives

Sometimes one required condition must be paired with one of several secondary signals:

confirmation title AND (green button OR blue button)

On a top-level condition card, use +group to attach a subgroup. Add the green and blue button conditions there, and set the subgroup badge to OR. The top-level condition remains required; the subgroup provides its alternatives.

Subgroups are intentionally limited to one nested level. If the expression becomes difficult to explain in one sentence, split the behavior into separate actions or clearer screen states. Readable logic is easier to test and maintain.

Practical example: guard a Continue tap

Suppose a Continue button should be tapped only after a confirmation dialog loads. The app uses a green button in one theme and a blue button in another.

Build this expression:

dialog title visible AND (green Continue visible OR blue Continue visible)

Configure it as follows:

1. Add a text condition for the stable dialog title.
2. Select +group on that condition.
3. Add an image condition for the green Continue button.
4. Use +group again on the same top-level condition to add the blue variant.
5. Set the subgroup badge to OR.
6. Keep the main group badge on AND.
7. Test the action with the title absent, with each theme, and with neither button available.

The expected test matrix is simple:

• title present + green button present: run;
• title present + blue button present: run;
• title absent + either button present: do not run;
• title present + neither button present: do not run.

Testing the false cases matters as much as testing the happy path. A guard is useful only when it blocks the wrong state.

Combine visual, profile, and variable conditions deliberately

The same group can mix different kinds of evidence. A visual condition answers what the emulator currently shows. A profile condition identifies the configured execution context. A variable condition represents what the macro has already counted or decided.

A retry action might require:

Retry button visible AND attempts less than 3

The image prevents a tap on the wrong screen; the variable limits the behavior. A profile condition can select a variant that is valid only for a particular emulator setup. Keep each condition responsible for one fact instead of duplicating the same visual check in several forms.

Test the logic before running across profiles

Use the action-level test with a small truth table:

1. list every condition in the group;
2. record which combinations should run;
3. place the emulator in each important state;
4. confirm both successful and blocked outcomes;
5. save, close, and reopen the macro to review the final grouping;
6. run one complete pass on one profile before expanding execution.

Then follow the macro stabilization checklist before running across profiles. Conditions should identify state; waits should handle timing; explicit stop behavior should handle outcomes that must end the run.

Build gates that explain themselves

Good conditional automation is readable: every AND represents required evidence, every OR represents a true alternative, and every separate group describes a complete route to the same action. Start with the sentence, reproduce it in the builder, and test the combinations that must stay blocked.

Explore EmuloAgent and build visual Android emulator macros with condition groups on Windows.