As soon as you have more than one Android emulator profile, the question changes from can this macro run? to where should this macro be available? A login macro may belong to every profile. A diagnostic macro may belong only to one test instance. A variant captured at one resolution should not be mixed into a profile that renders the app differently.
EmuloAgent handles that operational layer with profile pins. A macro can be pinned to the profiles where it should appear, started on one profile, started across pinned profiles, or stopped from the same Automations workflow. This guide explains how to use pins deliberately so your emulator automation stays organized before you scale it.
Use automation only where the app, game, or service allows it. Profile pins organize execution; they do not change the rules of the software you automate.
Pinning is an operating decision
Building a macro defines the sequence: what the automation checks, taps, waits for, and stops on. Pinning defines where that sequence is meant to be operated.
That distinction matters. If every macro is visible everywhere, the Automations screen becomes noisy and the wrong profile is easier to start. If pins are too narrow, a routine that should be available to a group of profiles turns into manual searching.
Use pins when a macro has passed a controlled test and you know which profiles should use it. Treat the pin as a small release decision: the macro is ready enough to appear in that profile’s working set.
Prepare profiles before assigning macros
Before pinning, each target profile should represent a real emulator setup: name, emulator instance, ADB connection, and detected resolution. EmuloAgent also supports demo profiles for testing the product, but a real automation routine should be checked on the emulator profile that will run it.
For visual macros, resolution is not cosmetic. Reference images and coordinates are captured against a screen size. If a macro and a profile have incompatible resolutions, EmuloAgent prevents that profile from being pinned or run from the Automations detail controls. That avoids a common failure: starting a macro on a profile where its templates cannot match the screen.
If your emulator environment is not ready yet, start with the MuMu, BlueStacks, LDPlayer, and Nox setup guide before assigning macros broadly.
How to pin a macro to selected profiles
Open Automations, select the macro, and review the Profiles section in the detail panel. Each profile row shows whether the macro is running there and provides profile-level actions.
Use the star control on a profile row to pin or unpin the macro for that profile. When the macro is pinned, it also appears in the profile detail area as one of that profile’s attached automations. From there, you can start, stop, or remove the pin without returning to the full Automations list.
A practical pinning flow looks like this:
- Build or edit the macro from a profile that has the expected screen and resolution.
- Run it once on that profile from a known starting state.
- Confirm that the macro stops, loops, or waits exactly as intended.
- Pin it to that profile.
- Repeat the supervised test on the next compatible profile before pinning it there.
This keeps the profile list honest: pinned means tested enough to belong there, not merely “might work.”
Use single-profile run for the first pass
The run button on a profile row starts the selected macro only for that profile. Use it when you are testing a new macro, validating a variant, or checking a profile that recently changed emulator resolution, app language, theme, or starting state.
Single-profile execution is the right choice when:
- the macro has just been created or edited;
- one profile has a different app state from the others;
- you are confirming that a copied or duplicated macro still points at the right screen elements;
- an emulator was just restarted and you want one clean pass before a broader run.
If the emulator for that profile is not active, the run control is disabled rather than sending the macro into an ADB failure. Start the emulator first, confirm the profile is ready, then run the macro.
Use Run all only for pinned profiles
The aggregate Run all control starts the selected macro across pinned profiles that are not already running it. That is useful when several emulator profiles share the same routine and have already passed individual checks.
It is not a shortcut for validation. Before using it, confirm:
- every target profile is pinned intentionally;
- each pinned profile uses a compatible resolution;
- the macro has a known starting state or guards its first action with a reliable condition;
- no profile is already in the middle of a conflicting routine;
- the PC can handle the number of emulator instances you are about to operate.
For longer runs, pair this with the macro stabilization checklist. Pins decide where the macro is allowed to appear; stabilization decides whether the macro is ready to run there.
Stop from the same operational surface
When the macro is running, EmuloAgent exposes stop controls at the profile row and aggregate level. Use profile-level stop when only one emulator needs attention. Use Stop all when the selected macro should be stopped everywhere it is currently running.
This is especially helpful when you are comparing variants. Keep the baseline pinned to the production-like profiles, pin the experiment only to a test profile, and stop the experiment without touching the baseline. If a copied macro needs to become the new standard, pin it deliberately after the test rather than letting both versions compete across the same profiles.
For controlled experimentation, see the guide on duplicating an Android emulator macro and creating a safe variant.
Example: one macro, three emulator profiles
Imagine a QA-support routine that opens a settings screen, checks that a label appears, takes a screenshot when the expected state is reached, and then stops.
You have three profiles:
qa-blue-01, the main BlueStacks profile used to build the macro;qa-blue-02, another profile with the same resolution and app build;qa-legacy, an older profile with a different resolution.
Start with qa-blue-01. Run the macro once, confirm the screenshot and stop behavior, and pin it there. Then open qa-blue-02, place the app in the same starting state, run one supervised pass, and pin it if the result matches.
Do not pin qa-legacy just because it exists. If its resolution differs, EmuloAgent’s controls should block pinning or running from the profile row. If that profile needs the same routine, create or adapt a macro for that resolution, then test it separately.
After qa-blue-01 and qa-blue-02 are pinned and idle, Run all can start the routine across those pinned profiles. If one profile is already running the macro, EmuloAgent skips starting a duplicate there.
Keep the profile map clean
Review pins whenever a macro changes purpose. A macro that used to be safe for all profiles may become specific after you recapture images, change a condition, or adjust a coordinate. Unpin it from profiles that no longer match the new behavior.
Use this short review before a broader run:
- The macro name describes the current routine, not an older version.
- The macro is pinned only to profiles where it was tested or intentionally assigned.
- Incompatible resolutions have been handled by recalibration or a separate macro.
- Test-only variants are pinned only to test profiles.
- Profiles with closed emulators are started before running the macro.
- The stop behavior is clear before using Run all.
If the macro should be reused on another Windows PC later, combine profile discipline with cloud sync and sharing so the macro itself is available without losing control over where it runs locally.
Turn profiles into a usable control surface
Profile pins make EmuloAgent easier to operate once you have multiple Android emulators. They keep each macro attached to the profiles where it belongs, expose run and stop controls in the right place, and make multi-profile execution a deliberate step instead of a guess.
Explore EmuloAgent to build visual Android emulator macros on Windows, organize them by profile, and operate them with clearer run and stop controls.