In Appium, how can a test drive the emulator or simulator itself rather than the app under test?

## Driving the machine, not the app Almost every Appium command is aimed at the app: find an element, tap it, read an attribute. A virtual target adds a second class of command aimed at the **device itself** — the emulator or simulator as a piece of software running on your host. These commands are worth knowing precisely because they exist only on a virtual target, which makes them both powerful and a portability hazard for a hearing-aid fitting suite that must also run on real hardware. The two platforms solve this the same way in shape and completely differently in detail. ## Android: the emulator console A running Android emulator exposes a console channel of its own, and the Android drivers expose **`mobile: execEmuConsoleCommand`** to send a command down it. That single method is the general form. Beside it sits a family of named methods backed by the same channel, each modelling hardware state a virtual device can fake and a real phone cannot be made to produce on demand: - `mobile: gsmCall`, `mobile: gsmSignal`, `mobile: gsmVoice` — telephony state. - `mobile: sendSms` — deliver a message to the device. - `mobile: powerAc`, `mobile: powerCapacity` — charging and battery state. - `mobile: sensorSet` — sensor values. - `mobile: networkSpeed` — measured **emulator-only**, simulating a link speed. Note that these belong to *the Android drivers*, not to the UiAutomator2 repository specifically: the Android base driver carries the large device-facing surface and whichever driver you name in `appium:automationName` inherits it. ## Apple: simctl from inside the session The XCUITest driver's counterpart is **`mobile: simctl`**, which runs an Xcode simulator-control subcommand against the booted simulator. `simctl` is the same tool the driver used to boot the target in the first place, so this is genuinely an escape hatch to host tooling rather than a device API. There is no equivalence to draw between the two commands beyond that shape. `mobile: execEmuConsoleCommand` speaks to a running emulator's console; `mobile: simctl` invokes Xcode tooling that manages simulators. Their vocabularies, argument shapes and failure modes have nothing in common, and a suite that pretends otherwise is hiding the divergence rather than handling it. ## How both arrive at the driver Both are **execute methods**, not endpoints of their own. A client sends them to `POST /session/:sessionId/execute/sync` with the `mobile:` name and a single parameter map, which is why a language client such as java-client or the Python client needs no dedicated helper for either. In practice that means: 1. The method name identifies the driver that owns it — say the platform whenever you write one down. 2. Adding a new one to a suite is a data change, not a client upgrade. 3. An unknown `mobile:` name fails at the driver, mid-run, rather than at session start. ## The two costs The first cost is **portability**. Every one of these calls is a step your suite can take on a virtual target and cannot take on a physical one. A fitting flow that seeds a low-battery state through the emulator console has quietly become an emulator-only case. That is a legitimate choice; it is not a legitimate accident. The second cost is **trust in the host**. These methods reach outside the app and outside the device's own automation surface, and Appium keeps host-reaching features behind insecure-feature gating — the same mechanism that guards the Android drivers' shell access with `--allow-insecure=uiautomator2:adb_shell`. Before a suite leans on either method, confirm what the server it will run against actually allows. ## When it is the right tool - When the state you need is a property of the machine — battery, telephony, sensors — and no in-app path can produce it. - When you are seeding a precondition rather than asserting on one, so the virtual-only path never becomes the thing under test. - When the alternative is a manual step that would keep the case out of the suite entirely. And when not to: if the same precondition can be set through an ordinary driver command that works on every target, prefer that command. The escape hatch should be the smallest possible part of a suite's surface, because every use of it narrows where the suite can run.