In Appium, which capability bounds the on-device agent's startup on Android, and which on iOS?
answer
- two platforms, two different agents
- one Android ceiling is per command
- a build on one side, a push on the other
- uiautomator2ServerLaunchTimeout versus wdaLaunchTimeout
basics
~10 sAndroid bounds the UiAutomator2 helper server's launch with appium:uiautomator2ServerLaunchTimeout and each adb call with appium:adbExecTimeout. iOS bounds WebDriverAgent's build, install and launch with appium:wdaLaunchTimeout. Neither platform's capability has any effect on the other.
solid answer
~40 sBefore a single test command can run, the driver has to get an agent onto the device, and the two platforms bound different work. On Android the UiAutomator2 driver installs and starts `io.appium.uiautomator2.server` (with `io.appium.settings` alongside it); `appium:uiautomator2ServerLaunchTimeout` is the ceiling on that server coming up and answering, and `appium:adbExecTimeout` is a separate, **per-invocation** ceiling on each `adb` call the driver makes along the way. On iOS the XCUITest driver builds, signs, installs and launches **WebDriverAgent**, normally by shelling out to `xcodebuild`; `appium:wdaLaunchTimeout` bounds that whole sequence producing an agent that responds. All three are milliseconds. They are strictly startup budgets — once the session exists, the timer that matters is `appium:newCommandTimeout`, a different clock in a different unit.
code
json · 15 lines{
"androidLane": {
"platformName": "Android",
"appium:automationName": "UiAutomator2",
"appium:uiautomator2ServerLaunchTimeout": 90000,
"appium:adbExecTimeout": 40000,
"appium:newCommandTimeout": 120
},
"iosLane": {
"platformName": "iOS",
"appium:automationName": "XCUITest",
"appium:wdaLaunchTimeout": 240000,
"appium:newCommandTimeout": 120
}
}go deeper
Be able to name the capability that bounds agent startup on each platform and say that the two do not substitute for each other. Knowing appium:uiautomator2ServerLaunchTimeout is Android's and appium:wdaLaunchTimeout is iOS's is the baseline.
Explain what each ceiling is actually waiting for: a helper server installed and started over adb on Android, versus a WebDriverAgent build, signing, install and launch on iOS. Say why appium:adbExecTimeout is per invocation.
Show how you set these numbers from measurement on the slowest real host rather than by copying a value, and how you tell a ceiling that is too low apart from an agent that genuinely cannot come up.
Own the shape of the configuration: separate per-platform startup budgets, each recorded with the measurement behind it, and a policy for when the answer is to attack the startup work rather than raise the ceiling again.
## What "startup" means in an Appium session A `POST /session` request does not merely allocate a session id. Before the server can answer a single find or click, the driver has to get an **agent** onto the device: a program that runs on the device itself, talks to the platform's own UI-automation framework, and answers the driver's requests. All of that happens between the moment the client posts its capabilities and the moment it receives a session id, and it is the slowest part of most Appium runs. The startup timeout capabilities are the ceilings on that work. The important thing is that the agent is not one thing. Android and iOS put a different program on the device, get it there by a different mechanism, and therefore need different ceilings with different names. A bakery pre-order suite that runs on both cannot share one number. ## Android: a helper server pushed onto the device The UiAutomator2 driver installs and starts `io.appium.uiautomator2.server` on the device, together with the `io.appium.settings` helper app, and then waits for that server to accept a connection. Two capabilities bound it: - `appium:uiautomator2ServerLaunchTimeout` — how long the driver waits for the helper server to come up and answer once it has been started. - `appium:adbExecTimeout` — the ceiling on **each individual `adb` invocation** the driver makes. Strictly speaking this is not a startup budget at all; it is a per-command budget that bites hardest during startup, because startup is where the driver runs the most `adb` calls back to back. That distinction earns its keep. Raising `appium:uiautomator2ServerLaunchTimeout` does nothing for a host where `adb` itself is slow, and raising `appium:adbExecTimeout` does nothing for a device where the helper server is slow to answer once it has been started. ## iOS: an agent that has to be built first The XCUITest driver's agent is **WebDriverAgent**, and the default way to get it onto a device is to build it. The driver shells out to `xcodebuild`, which compiles the agent, signs it, installs it and launches it as an XCTest run; only then does the driver connect. `appium:wdaLaunchTimeout` is the ceiling on that whole sequence producing an agent that responds. Because a build sits in the middle of it, the honest budget is far larger on a cold machine than on a warm one, and it differs between a simulator and a real device. The driver does support skipping the build — `appium:usePreinstalledWDA` and `appium:webDriverAgentUrl` point it at an agent that is already present — but whether that trade is worth its upkeep is a separate decision. The point here is that the ceiling is large because the work behind it is a build rather than a push. ## The two ceilings side by side | | Android (UiAutomator2 driver) | iOS (XCUITest driver) | |---|---|---| | the agent | `io.appium.uiautomator2.server` plus `io.appium.settings` | WebDriverAgent | | how it arrives | installed and started over `adb` | built, signed, installed and launched, normally via `xcodebuild` | | launch ceiling | `appium:uiautomator2ServerLaunchTimeout` | `appium:wdaLaunchTimeout` | | per-step ceiling | `appium:adbExecTimeout`, per `adb` call | nothing of this shape | | unit | milliseconds | milliseconds | | effect on the other platform | none | none | ## Choosing values without guessing 1. Measure the phase you are bounding on the slowest host and device you actually run against, cold — not on a developer laptop with a warm cache. 2. Set the ceiling above the observed worst case with headroom, and record what you measured next to the number so the value can be defended later. 3. Keep the Android and the iOS values as separate configuration entries. One shared startup number forces the smaller platform's budget onto the larger one, or the other way round. 4. Re-measure when the agent changes. A driver upgrade that forces WebDriverAgent to rebuild, or an Android device fleet swap, moves the worst case underneath you. ## What these capabilities do not cover - They do not cover waiting inside a live session. Once the session id is issued, element waits and the server's idle reaper are separate mechanisms with their own settings. - They do not cover the app under test starting. Getting the bakery pre-order app itself to the foreground is a later phase with its own capabilities. - They do not diagnose anything. A ceiling that is too low and an agent that genuinely cannot start produce the same symptom; telling them apart is a triage exercise, not a configuration one. - They do not travel. `appium:wdaLaunchTimeout` sitting in an Android capability set is an unrecognised key that changes nothing, and the reverse holds just as firmly.
- Why does an iOS lane usually need a much larger startup ceiling than an Android lane on the same hardware?Because the work differs in kind. Android installs and starts an already-built helper server over `adb`; iOS normally has `xcodebuild` compile, sign, install and launch WebDriverAgent before the driver can connect at all. A compile-and-sign step is minutes-scale work on a cold machine, while a push is seconds-scale.
- Does appium:adbExecTimeout stop mattering once the Android session has started?No. It bounds every `adb` invocation the UiAutomator2 driver makes, and the driver keeps making them for the life of the session — installing, clearing, querying device state, pulling logs. A value tuned only for a quiet startup can trip mid-run on a loaded host.
saying these in an interview costs you the question
- Naming one startup timeout capability that covers both Android and iOS
- Thinking appium:adbExecTimeout bounds the whole Android session startup
- Assuming iOS pushes a prebuilt agent the way Android does
- Believing appium:wdaLaunchTimeout affects an Android session
- Raising the launch ceiling when adb itself is the slow part