In an Appium fleet, how do you stop a degraded link on Android or iOS from outliving its session?

## Degradation is device state, not test state Most of what a test does dies with the session: the app is closed, the element cache is dropped, the driver goes away. Network degradation does not. `mobile: setConnectivity` writes to the device's radios and `mobile: enableConditionInducer` turns on a profile in the operating system, and both of those outlive the process that asked for them. On a laptop with one attached phone that is a nuisance; on a shared fleet it is a defect that shows up in someone else's run. ## Android: what stays behind On Android there are two separate leftovers, and they are cleaned differently. - **Radios**, set by `mobile: setConnectivity`. Nothing in the session teardown puts them back. If a parking-permit renewal case switched mobile data off to assert the queued-renewal notice and then failed the assertion, the device is still without data when the next session starts. - **Emulator link speed**, set by the emulator-only `mobile: networkSpeed`. A re-used emulator carries that profile forward; a freshly booted one does not, which is why the symptom looks intermittent on a pool that sometimes recycles instances. The read-back is what turns cleanup from hope into verification: `mobile: getConnectivity` reports the state the device is actually in. Assert on it after restoring, and the difference between a leaked setting and a genuinely sick device stops being guesswork. ## Apple: pair every enable with a disable On Apple real devices, `mobile: enableConditionInducer` has an explicit counterpart, `mobile: disableConditionInducer`. Call it. There are two places worth calling it from: 1. **Teardown**, unconditionally, so a failing assertion cannot skip it. 2. **Session start**, defensively, so a device abandoned mid-run by an earlier crash starts clean rather than inheriting a profile. `mobile: listConditionInducers` tells you what the device can impose, which is also how you avoid hardcoding an identifier that a given device does not offer. The one thing not to do is rely on the session ending as the cleanup mechanism — the run should undo what it did, on the same path where it did it. ## Do not cut the branch you are sitting on There is a hazard on this leaf that other environment controls do not have: **the degradation can sever your own control channel**. Appium commands reach the device over a host connection. If that connection runs over the network rather than a cable, switching Wi-Fi off with `mobile: setConnectivity` kills the transport the next command needed, and the session dies holding the device in the state you were about to undo. On a fleet, prefer wired attachment for cases that take the radios down, and if that is not possible, degrade something narrower than the radio your control path is using. ## Undo, side by side | Left behind | Android | Apple real device | |---|---|---| | what leaks | radio state, emulator link profile | an enabled condition profile | | the undo | write the flags back with `mobile: setConnectivity` | `mobile: disableConditionInducer` | | the check | `mobile: getConnectivity` | `mobile: listConditionInducers` before enabling | | clears on reboot | emulator profile does, handset radios do not | not something to rely on | ## A restore that actually runs The practices that separate a suite that leaks from one that does not are unglamorous: - Put the restore in unconditional teardown, never as the last line of the test body, so a throw cannot skip it. - Restore before you assert wherever the assertion does not need the link down. - Verify the restore rather than assuming the write landed. - Reset defensively at session start, because the previous run may have died before its own teardown. - Log the degraded window with timestamps, so a later failure on the same device can be traced to a leak instead of to hardware. ## The symptom to recognise The reason this is a senior question is the shape of the bug report it produces. Nobody reports a leaked setting. They report that a device in the pool is unreliable, that installs time out on it, or that one device fails cases the others pass. A device stuck in airplane mode or holding a condition profile presents exactly like failing hardware, and the fix is a teardown fifty lines away in a case that already passed. Knowing that these two commands write through to the device — and that Appium keeps no snapshot to roll back to — is what lets you look in the right place.