In Appium, which commands does the UiAutomator2 driver declare itself, and which does it inherit?
answer
- two packages, not one
- the driver is a subclass
- gestures and windows only
- sixty methods come from the base
- Espresso extends the same base
basics
~20 sAppium's UiAutomator2 driver declares only gesture, scroll, window, viewport, clipboard and device-info commands of its own on Android. The rest of its Android surface, roughly sixty methods, is inherited from appium-android-driver, the shared base the Espresso driver also extends.
solid answer
~40 sOn Android, Appium's UiAutomator2 driver owns a surprisingly small execute-method map. Its own map declares the gesture family (`mobile: swipeGesture`, `flingGesture`, `dragGesture`, `pinchOpenGesture`, `scrollGesture`), the scroll helpers, window/display/viewport commands, clipboard and device info, plus a short tail such as `mobile: installMultipleApks` and `mobile: replaceElementValue`. Almost everything else an Android session can call — `mobile: installApp`, `activateApp`, `clearApp`, `shell`, `setConnectivity`, `setGeolocation`, `changePermissions`, `pushFile`, `hideKeyboard` and about sixty more — is declared by **`appium-android-driver`**, the base the UiAutomator2 driver extends. Appium's Espresso driver extends the same base and inherits the same list. The practical consequence: when an Android command misbehaves, the source and issue tracker you want is usually `appium-android-driver`, and the honest phrase is "the Android drivers", not "the UiAutomator2 repo".
go deeper
Be ready to say that Appium's UiAutomator2 driver builds on a shared Android base driver, and that not every mobile: command you call is defined in the UiAutomator2 project itself.
Explain the mechanics: the UiAutomator2 driver extends appium-android-driver and spreads its execute-method map, so gestures and window commands are its own while app, shell, network and file commands are inherited.
Show the diagnostic payoff. Say which repository you would open for a given misbehaving Android command, and note that Appium's Espresso driver inherits the same base, so a base-driver defect shows on both backends.
Own the vocabulary discipline across a team: insist that docs, bug reports and test helpers attribute each command to a named driver, because near-twin names like swipeGesture and swipe make unattributed sentences silently wrong.
## Appium's Android automation is two packages, not one A session that sets `appium:automationName` to `UiAutomator2` loads `appium-uiautomator2-driver`. That package is not self-contained. It extends `appium-android-driver`, a shared base, and spreads the base's execute-method map into its own — so most of the `mobile:` methods an Android session can call are declared in the base rather than in the UiAutomator2 package. Appium's Espresso driver extends that same base, which is why the two Android backends share most of their command vocabulary while differing sharply in how they actually reach the screen. This is not trivia. Which package declares a command decides which repository you read when a behaviour surprises you, which issue tracker a bug belongs in, and whether what you are seeing is specific to the UiAutomator2 backend or common to every Android driver Appium ships. ## The commands the UiAutomator2 driver declares itself Its own execute-method map is short and thematically narrow — broadly, the work only the on-device UiAutomator2 server can do: - the gesture family: `mobile: clickGesture`, `longClickGesture`, `doubleClickGesture`, `dragGesture`, `flingGesture`, `swipeGesture`, `scrollGesture`, `pinchOpenGesture`, `pinchCloseGesture` - the scroll helpers `mobile: scroll` and `mobile: scrollBackTo` - window, display and viewport commands: `mobile: listWindows`, `mobile: listDisplays`, `mobile: viewportRect`, `mobile: viewportElementRect`, `mobile: viewportScreenshot`, `mobile: screenshots`, `mobile: getDeclaredOrientation` - on-device input and chrome: `mobile: type`, `mobile: pressKey`, `mobile: acceptAlert`, `mobile: dismissAlert`, `mobile: openNotifications`, `mobile: replaceElementValue`, `mobile: resetAccessibilityCache` - clipboard and device facts: `mobile: getClipboard`, `mobile: setClipboard`, `mobile: deviceInfo`, `mobile: batteryInfo` - a short tail: `mobile: installMultipleApks`, `mobile: deepLink`, and the scheduled-action trio `mobile: scheduleAction`, `mobile: unscheduleAction`, `mobile: getActionHistory` ## The commands that arrive from appium-android-driver Almost everything else in an Android session's vocabulary — on the order of sixty further methods — is declared by the base driver and inherited. App management (`mobile: installApp`, `removeApp`, `isAppInstalled`, `activateApp`, `terminateApp`, `backgroundApp`, `queryAppState`, `clearApp`, `startActivity`, `getCurrentActivity`, `getCurrentPackage`), the device shell (`mobile: shell`), connectivity and emulator conditioning (`mobile: setConnectivity`, `getConnectivity`, `networkSpeed`, `execEmuConsoleCommand`), location (`mobile: setGeolocation`, `getGeolocation`, `toggleGps`), permissions (`mobile: changePermissions`, `getPermissions`), the keyboard (`mobile: hideKeyboard`, `isKeyboardShown`, `performEditorAction`), file transfer (`mobile: pushFile`, `pullFile`, `pullFolder`), recording (`mobile: startMediaProjectionRecording`, `stopMediaProjectionRecording`) and a long tail of sensor, telephony and UI-mode commands all live there. | Concern on Android | Declared in | |---|---| | Gestures, scrolling, viewport, windows, displays | `appium-uiautomator2-driver` | | Clipboard, device info, battery | `appium-uiautomator2-driver` | | App install, launch, terminate, clear, activities | `appium-android-driver` | | Shell, connectivity, geolocation, permissions, files | `appium-android-driver` | | Screen recording, performance data, emulator console | `appium-android-driver` | ## Working the split in practice Suppose a suite drives a food-truck pre-order app and `mobile: setConnectivity` behaves oddly while the order-queue screen is open. Searching the UiAutomator2 repository for that method finds nothing, and the tempting conclusion — that the command is undocumented magic — is wrong. It is declared in `appium-android-driver`, and that is where its arguments, its constraints and its issue history live. The reasoning runs the other way too: a defect in `mobile: swipeGesture` while dragging the food truck's menu carousel is the UiAutomator2 driver's, because that gesture is one of the commands the driver owns outright. Two refinements keep the rule honest: 1. Inheritance is not uniform. Appium's Espresso driver inherits the same base list, yet it also declares `mobile: startActivity` itself with its own signature — so "Espresso has it too" is not proof that a command came from the base. 2. Where a command is declared is a different question from whether an HTTP endpoint still exists. Appium 3 pushed much of the old Android work into per-driver `mobile:` execute methods, yet several classic routes are still declared in the core route table. Grep the route tables before asserting that anything was removed. ## Saying it precisely in an interview - Say "the Android drivers" when you mean the inherited surface, and "the UiAutomator2 driver" only for what that package declares. - Attribute every command to a driver by name: `mobile: swipeGesture` is UiAutomator2's, while `mobile: swipe` is XCUITest's and Espresso's. The names are close enough that a careless sentence is simply false, and no spell-check catches it. - Remember that Apple's side is a different repository again — the XCUITest driver's on-device surface is WebDriverAgent — so an Android answer never transfers to iOS by analogy. The payoff is diagnostic speed. An engineer who knows the split reads one repository instead of three, and describes an Android defect in terms the maintainers can route on the first read.
- Why does it matter to a working engineer which package declares an Android mobile: method?Because it decides where you read source and file bugs. A `mobile: setConnectivity` problem belongs to `appium-android-driver` and affects Appium's Espresso driver equally; a `mobile: swipeGesture` problem is the UiAutomator2 driver's alone. Naming the wrong package sends a report to maintainers who cannot act on it, and sends you searching a repository that never contained the code.
- Appium's Espresso driver inherits the same base list. Does that make every Android command identical across the two drivers?No. Inheritance covers the base driver's methods, but a driver may declare its own version. Appium's Espresso driver declares `mobile: startActivity` itself with its own signature, and it adds Espresso-only methods the UiAutomator2 driver never has. Shared ancestry means a shared starting point, not an identical surface.
- How would you phrase an Android gesture command's ownership without risking a false statement?Name the driver every time: "the UiAutomator2 driver's `mobile: swipeGesture`". The near-twin `mobile: swipe` belongs to Appium's XCUITest and Espresso drivers, so "UiAutomator2's `mobile: swipe`" reads plausibly and is false. Attribution, not the identifier alone, is what makes the sentence checkable.
saying these in an interview costs you the question
- Assuming every Android mobile: method lives in the UiAutomator2 driver's own repository
- Calling mobile: swipe a UiAutomator2 command when it is XCUITest's and Espresso's
- Thinking Appium's Espresso driver keeps a separate copy of the Android command set
- Claiming Appium 3 deleted the app-management endpoints outright without checking the route tables
- Treating appium-android-driver as an internal detail with no user-visible command surface
- Answering about Android command ownership with WebDriverAgent, which is the Apple side