Changing a working Android emulator macro just to try a different threshold, delay, or path creates an avoidable risk: the experiment and the known baseline now share the same file. If the new settings do not work, you have to remember every change before you can return to the stable version.
EmuloAgent provides a Duplicate automation command for this situation. It creates a separate macro with its own identity and image assets, leaves the source intact, and selects the new entry so you can edit it. This makes duplication useful for controlled variants, not merely for collecting copies.
This guide shows what duplication preserves, what it deliberately does not inherit, and how to validate the result before using it in a recurring workflow.
Duplicate the whole macro when the baseline matters
Duplicate a macro when the new work should begin with the complete structure of an existing automation. Practical cases include:
- testing a stricter image threshold without changing the stable flow;
- adapting a known journey to another app theme or language;
- trying different waits around a slow transition;
- creating a shorter diagnostic version of a long routine;
- keeping a known baseline while reorganizing several steps.
If the destination needs only one proven step, duplicating everything creates unnecessary maintenance. Use the guide to reusing actions between macros for that narrower job. The distinction is simple: copying an action adds one behavior to another macro, while duplicating creates an independent version of the entire automation.
Prepare a useful baseline before making a copy
Run the source macro once in a controlled profile before duplicating it. Confirm its starting screen, emulator resolution, visual conditions, and expected final state. A copy preserves the source configuration; it does not turn an uncertain flow into a reliable one.
Give the source a name and description that identify its purpose. The duplicate keeps the description and receives a localized suffix such as (copy). If that name already exists, EmuloAgent adds a number, starting with (copy) 2. Clear names make it easier to distinguish the baseline from the experiment in the Automations list.
If the source still fails intermittently, use the Android emulator macro stabilization checklist before branching it into variants.
How to duplicate an automation in EmuloAgent
1. Select the source in Automations
Open Automations and select the macro you want to use as the baseline. Its detail panel shows the macro name, status, profiles, and action controls.
2. Choose Duplicate automation
In the header beside the edit control, use the duplicate icon. Its tooltip reads Duplicate automation. EmuloAgent performs the copy in the background, so a macro with several image files does not need to block the main interface while those files are copied.
3. Wait for the new entry to be selected
After the operation finishes, the Automations list refreshes and selects the new macro. Check the (copy) suffix before editing. If duplication cannot finish because of a disk or source-file problem, EmuloAgent reports an error instead of presenting an incomplete copy as ready.
4. Open the copy and define its purpose
Edit the selected copy and make the smallest change that tests your hypothesis. For example, change one detection threshold or one post-action delay. Changing several unrelated settings at once makes it harder to tell which adjustment caused the result.
What the duplicate includes
EmuloAgent gives the copy a new internal macro identifier. The flow structure and description are saved under that new identity, and the local image-asset tree is physically copied when the source has one. Existing asset folders for different captured resolutions travel with the duplicate.
This separation has an important consequence: later edits to the copied flow or its copied image files do not rewrite the source macro. You can recapture a reference in the variant and still return to the original reference in the baseline.
Duplication is not a promise that every copied reference fits a new environment. A template captured at one resolution remains a template from that resolution. If the variant targets another emulator layout, app version, theme, or language, review its image regions, coordinates, text, and color conditions before execution. The image, color, and text detection guide provides a focused review process.
What the duplicate does not inherit
The new macro starts without profiles pinned to it. This is deliberate: inheriting those links could leave the baseline and the variant both prepared for the same profiles. Choose where the copy belongs only after you have tested it.
Also note that an automation received through sharing cannot be duplicated. The duplicate control is disabled for that source type. If you need a related workflow, create your own automation and reuse only behavior you are authorized to reproduce.
These boundaries keep duplication from silently changing how the source is operated or bypassing the sharing rules attached to a received macro.
Practical example: compare a conservative and a faster variant
Suppose a stable QA-support macro waits for a confirmation image before opening the next screen. It works consistently, but the post-action delay may be longer than the current app build needs.
Use a controlled comparison:
- Run the baseline and confirm the expected transition.
- Duplicate the macro from its Automations detail panel.
- Keep the original name as the baseline and rename the copy by purpose, such as Confirmation flow — shorter delay.
- Change only the delay in the copy.
- Leave the copy unpinned while testing it on one compatible profile.
- Test both the normal transition and a deliberately slow response.
- Keep the faster setting only if the next action still waits for an observable ready state.
- Pin the variant only after deciding which version belongs in the recurring workflow.
The goal is not to make a macro as fast as possible. It is to compare one change against a known reference without sacrificing that reference.
Validate the variant before relying on it
Use this checklist after duplication:
- The new name clearly distinguishes the copy from the source.
- The source macro still opens and runs with its previous configuration.
- The copy contains the expected steps, conditions, and image references.
- The selected emulator profile uses a compatible resolution.
- Coordinates and detection regions still point to the intended interface areas.
- Only the planned variables were changed in the first test.
- The variant was run from a known starting screen.
- Success and failure paths both produce an observable result.
- Profiles were pinned only after the variant passed the controlled test.
When the chosen variant is stable, the cloud sync and sharing workflow can keep that macro available through your Sertta account. Duplication itself remains a local editing operation; cloud upload and sharing are separate decisions.
Experiment without giving up the known baseline
Duplicating a macro creates room for a controlled change: preserve the working source, make one purposeful adjustment in an independent copy, test it on a compatible profile, and decide which version should be used. That is safer than turning the only known baseline into an untracked experiment.