In Appium on Android, what does mobile: toggleGps control that no iOS command does?

## Android models the provider and the position separately On Android, *where the device thinks it is* and *whether the device has a working location provider* are two different pieces of state, and Appium exposes them through two different execute methods. `mobile: setGeolocation` installs a mock position. `mobile: toggleGps` flips the device's GPS location provider on or off. Neither implies the other: setting coordinates does not switch a disabled provider on, and switching the provider on does not hand the device a position. That separation is not an Appium invention. It mirrors how the platform itself is built, where an application asks a location provider for a fix and the provider may simply be unavailable. Appium's Android surface just makes both halves reachable from a test, and the Apple surface does not. ## The Android family, command by command All of these are declared by `appium-android-driver` and inherited by both the UiAutomator2 driver and the Espresso driver, and all are posted as `mobile:` execute methods: - `mobile: setGeolocation` — install a mock position from a latitude and a longitude; - `mobile: getGeolocation` — read back the position the device currently reports; - `mobile: resetGeolocation` — drop the mock and hand control back to the device; - `mobile: toggleGps` — switch the GPS location provider on or off; - `mobile: isGpsEnabled` — read whether that provider is currently on; - `mobile: refreshGpsCache` — ask the device to refresh its cached fix. Six commands for what a casual reader thinks of as one feature. The reason there are six is that Android lets a device sit in states a single set-position command cannot express: provider on with no fix, provider off with a stale fix, provider on with a mocked fix. ## What the XCUITest driver offers instead The Apple side is smaller and flatter. The XCUITest driver declares `mobile: setSimulatedLocation`, `mobile: getSimulatedLocation` and `mobile: resetSimulatedLocation` — set, read, clear — and that is the whole location surface. There is no `toggleGps` equivalent, no provider read-back, and no cache refresh. The driver simulates a position for the target; it does not model a location provider you can switch off. | Capability of the test | Android drivers | Apple XCUITest driver | |---|---|---| | Put the device somewhere | `mobile: setGeolocation` | `mobile: setSimulatedLocation` | | Read the current position | `mobile: getGeolocation` | `mobile: getSimulatedLocation` | | Clear the override | `mobile: resetGeolocation` | `mobile: resetSimulatedLocation` | | Turn the location provider off | `mobile: toggleGps` | not available | | Read the provider state | `mobile: isGpsEnabled` | not available | | Refresh the cached fix | `mobile: refreshGpsCache` | not available | ## A worked example The swimming-lesson booking app opens on a pool finder that sorts pools by distance and falls back to an alphabetical list when it cannot get a fix. Two different Android runs reach those two screens: 1. Call `mobile: setGeolocation` with the city-centre coordinates, confirm with `mobile: getGeolocation`, then open the finder and assert the nearest pool sorts first. 2. Call `mobile: toggleGps` so the provider is off, check with `mobile: isGpsEnabled`, then open the finder and assert the alphabetical fallback. The second run has no direct XCUITest translation. On Apple hardware a suite reaches a comparable state by other means — for example by never setting a simulated position at all, or through the permission surface, which is a separate subject with its own commands — but not by toggling a provider, because there is no provider toggle to call. ## Where teams go wrong - Assuming `mobile: setGeolocation` implies the provider is on, then wondering why the app still reports nothing. - Writing a cross-platform *disable location* helper and discovering it has no XCUITest command to call. - Confusing the provider switch with the application's runtime location permission — the permission is a different driver surface with different commands, and turning the provider off is not the same as denying the app access. - Treating `mobile: toggleGps` as a setter: it is a toggle, so calling it without reading `mobile: isGpsEnabled` first can put the device in the opposite state to the one the case wanted. - Leaving the provider switched off at the end of a run on shared hardware, so the next session starts in a state nobody configured. - Calling Android's six-command family *Appium's location API*, when half of it does not exist on the other platform. The honest summary is the one this corner of the driver surface keeps repeating: both platforms can put a device somewhere, and only Android lets a test decide whether the device can find itself at all.