In Appium, which capability decides which driver handles a session?
answer
- One capability names the driver
- Not the platform, the engine
- Vendor-prefixed, unlike platformName
- UiAutomator2, XCUITest, Espresso, Flutter
basics
~20 sThe appium:automationName capability names the driver, such as UiAutomator2, XCUITest, Espresso or Flutter. The Appium server reads it when the session is created and hands the session to that installed driver; platformName says which platform, not which driver.
solid answer
~40 s`appium:automationName`. The Appium server ships with no platform support of its own, so the new-session request has to name which installed driver extension takes the session: `UiAutomator2` or `Espresso` for Android, `XCUITest` for Apple platforms, `Flutter` for the official Flutter driver. `platformName` still travels — it says which platform the fuel-card expense app is running on — but it cannot choose on its own, because more than one installed driver can serve the same platform. `platformName` is one of the twelve W3C standard capability names and goes unprefixed; `automationName` is not, so it must be sent as `appium:automationName` or nested under `appium:options`.
code
java · 15 linesimport io.appium.java_client.android.AndroidDriver;
import io.appium.java_client.android.options.UiAutomator2Options;
import java.net.URL;
public class FuelCardSession {
public static void main(String[] args) throws Exception {
UiAutomator2Options options = new UiAutomator2Options()
.setPlatformName("Android")
.setAutomationName("UiAutomator2")
.setApp("/builds/fuelcard-expense.apk");
AndroidDriver driver = new AndroidDriver(new URL("http://127.0.0.1:4723"), options);
System.out.println(driver.getSessionId());
driver.quit();
}
}go deeper
Recall that appium:automationName names the driver and that platformName does not. Be able to give the four common values and say which platform each targets.
Explain what actually changes underneath when the name changes: a different driver package, different locator strategies, different mobile: methods, and a different device-side component.
Show that you treat the automation name as an architectural choice: it determines the lower half of the stack, so a change to it invalidates assumptions in the rest of the capability set.
Be ready to justify standardising a suite on one automation name per platform, and to say what a second one would cost in maintenance, device estate and reviewer knowledge.
## The capability that routes the session Appium 2 split the server from the automation, and Appium 3 keeps that split. The server itself ships with no platform support: every engine lives in a separately installed driver extension. Something in the new-session request therefore has to say which of those extensions should take the session, and that something is `appium:automationName`. The values name **drivers**, not platforms and not devices. `UiAutomator2` and `Espresso` both target Android; `XCUITest` targets Apple platforms; `Flutter` selects the official Flutter driver. `platformName` matters too — it says which platform the session is aimed at — but on its own it cannot choose, because more than one installed driver can serve the same platform. A Flutter build of a fuel-card expense app running on Android can be driven by Android's UiAutomator2 driver or by a Flutter driver, and the automation name is what settles it. ## Why the prefix is there `platformName` is one of the twelve W3C standard capability names, so it is written bare. `automationName` is not on that list. Like almost every other Appium capability it must be sent as `appium:automationName`, or nested inside `appium:options`. Sent bare it is rejected at session creation rather than quietly ignored, which is a good failure: you find out immediately. ## What changes when the name changes Changing that one string changes the entire lower half of the stack: - a different driver package takes the session, with its own command implementations - a different set of locator strategies becomes available - a different set of `mobile:` execute methods exists - a different thing — or nothing at all — is deployed to the device - a different set of `appium:` capabilities is understood, because most capabilities are declared by drivers rather than by the core That is why the automation name is worth treating as an architectural decision rather than a line of configuration. Two sessions against the same app on the same handset, differing only in this string, are running against different software from the driver downwards. | `appium:automationName` | what it drives | the driver package | |---|---|---| | `UiAutomator2` | Android | `appium-uiautomator2-driver`, extending `appium-android-driver` | | `Espresso` | Android | `appium-espresso-driver`, also extending `appium-android-driver` | | `XCUITest` | Apple platforms — iOS and iPadOS, tvOS, and watchOS simulators | `appium-xcuitest-driver` | | `Flutter` | a Flutter app on Android or on Apple platforms | `appium-flutter-driver` | ## What the automation name does not decide It is a narrow capability with one job, and beginners routinely expect it to do more: 1. It does not pick a device. Which handset, emulator or simulator the session lands on is settled by the device-selection capabilities, not by the automation name. 2. It does not install anything on the server. The server can only hand a session to an extension that is already installed; naming an absent driver fails at session creation. 3. It does not decide where the server runs, or how many sessions the suite opens. 4. It does not change the client. The same language client drives every driver, because all of them speak the same wire protocol. ## Reading a wrong-name failure The failure mode is unusually clean. If the name does not match an installed driver, the session never gets past creation: the error comes from the server, before any device work has been attempted, and long before an app is installed or a find is issued. That makes it one of the few Appium failures where the first lines of a run's output are more useful than the last. It also means the reverse is diagnostic — if you *did* get as far as an app installing or an agent starting, then the automation name was accepted and the driver was found, and whatever is wrong lies further down the stack. ## A habit worth forming When you read someone else's capability set, read the automation name first and everything else in its light. `appium:` keys that look mysterious are usually declared by the driver that name selects, and half of a confusing capability set stops being confusing once you know which driver is meant to consume it. The same reflex helps when a suite is ported: the moment the automation name changes, every other `appium:` key in the set is up for re-checking, because the code that reads them has been replaced.
- Two drivers can automate an Android app — what makes you pick one automation name over the other?The lower two tiers differ. Android's UiAutomator2 driver deploys a helper server and drives the app from outside it; Android's Espresso driver installs a test package that runs in-process and requires a matching signature. That changes which locator strategies and `mobile:` methods exist, so the choice is about what the suite needs to reach, not about taste.
- What happens if the automation name refers to a driver that is not installed on the server?Session creation fails in the server, before any device work happens. The server can only hand a session to an extension it already has, so the error arrives immediately and names the missing driver rather than surfacing later as a mysterious find failure.
saying these in an interview costs you the question
- Says platformName alone chooses the driver
- Sends automationName without the appium: prefix
- Thinks the value names a device or an app
- Believes one driver serves both Android and Apple platforms
- Assumes changing the name keeps every capability meaningful