Link Degradation

## Two platforms, no shared machinery Appium lets a running session change the network the device sees, but **Android and Apple share nothing here** — not a command name, not a mechanism, not even the same kind of effect. On Android a driver execute method flips the device's radios. On Apple the XCUITest driver switches on a *condition profile* that the operating system itself provides. Any sentence that describes the Appium way to take the network away is describing one of those two and silently ignoring the other, and on this subject that is exactly what an interviewer is listening for. ## Android: mobile: setConnectivity The command is `mobile: setConnectivity`, and it is declared by **`appium-android-driver`**, the base driver that both the UiAutomator2 driver and the Espresso driver extend. That matters twice over: the command is available in an Android session whichever of those two `appium:automationName` selected, and hunting for it in the UiAutomator2 repository will not find it, because that repository's own execute-method map carries only gesture and window commands. Like every `mobile:` method it travels as `POST /session/:sessionId/execute/sync` with the script name and one parameter map; a language client such as java-client wraps that in `executeScript`. The map carries the three radios Android exposes to the driver: - **wifi** — the Wi-Fi radio on or off - **mobile data** — the cellular data connection on or off - **airplane mode** — the umbrella switch that takes the others with it You send only the keys you mean to change. `mobile: getConnectivity` is the read-back twin, and it is worth calling: it reports the state the device actually settled on rather than the state you asked for. These execute methods are also the current spelling of something older. Appium 3's migration guide points the previous `toggle_wifi`, `toggle_data` and `toggle_airplane_mode` device routes at `mobile: setConnectivity`, so a helper in an inherited suite that still posts to those paths has an obvious replacement. ## Apple: a facility the driver borrows The XCUITest driver's answer is a trio: `mobile: enableConditionInducer`, `mobile: disableConditionInducer` and `mobile: listConditionInducers`. The important word is *inducer*. Appium is not simulating a bad link; the operating system ships a set of condition profiles, and the driver's whole job is to switch one on by naming a condition and one of its profiles. Because those identifiers belong to the platform rather than to Appium, the honest way to use them is to call `mobile: listConditionInducers` first and take the pair out of the response. Three properties define the feature: - It is **real-device only** — a Simulator has no condition inducer to switch on. - It **degrades**; it does not disconnect a radio, and there is no Wi-Fi switch anywhere in this API. - It has an **explicit undo**, `mobile: disableConditionInducer`, which a run should call rather than hope the session teardown covers it. There is a documentation trap here too, and it is the kind that survives a careless copy-paste: the driver's own reference prose prints `mobile: availableConditionInducer`, a name that appears in no method map in the driver. The listing command is `mobile: listConditionInducers`. ## Side by side | Concern | Android drivers | XCUITest driver | |---|---|---| | set it | `mobile: setConnectivity` | `mobile: enableConditionInducer` | | inspect it | `mobile: getConnectivity` | `mobile: listConditionInducers` | | effect | radios on or off | one operating-system condition profile | | targets | emulator or handset | real devices only | | undo | write the flags back | `mobile: disableConditionInducer` | ## Putting it in a run Take a parking-permit renewal app that must show a queued-renewal notice when the handset has no data. On Android the step is direct: switch data off with `mobile: setConnectivity`, drive the renewal, assert the notice, switch data back on. On Apple the same step cannot exist in that shape — on a real iPhone you enable a network condition profile and the request degrades instead of vanishing, and on a Simulator the driver offers you nothing at all. The practical consequence is that a cross-platform suite has **two implementations behind one intent**, not one shared call. Suites that pretend otherwise grow a helper named something like setOffline() that works on Android, throws on Apple hardware, and quietly does nothing on a Simulator. ## What a good answer sounds like 1. Name the Android command, `mobile: setConnectivity`, and the package that declares it. 2. Name the Apple trio and say that it enables an operating-system condition profile, on real devices only. 3. State the asymmetry out loud rather than describing one platform and stopping. If a follow-up asks about throttling rather than switching, that is `mobile: networkSpeed` — a different Android command with its own restriction, and not a synonym for `mobile: setConnectivity`.