🔧 Desired Capabilities & wdio.conf.ts

Desired Capabilities & wdio.conf.ts: Think of capabilities as a multi-dimensional work order for a taxi dispatcher — not just "where to go" but which vehicle, which route, which

Think of capabilities as a multi-dimensional work order for a taxi dispatcher — not just "where to go" but which vehicle, which route, which passenger: `platformName: Android`, `deviceName: emulator-5554`, `appium:app: /apk/app.apk`, `appium:automationName: UiAutomator2`. But when you write a simple `ChromeOptions` in Java you don't need this many parameters — so why does Appium demand so much context upfront? Because a browser starts identically on every machine, while the mobile environment is massively fragmented: the same Android version behaves differently across devices, the same APK installs differently on ARM vs x86 architectures, and Appium must know the full context before it can select and initialize the right driver. This is exactly where the comparison with Java's `DesiredCapabilities` lands: in Appium 3, W3C standard requires that all Appium-specific capabilities like `appPackage` or `appActivity` are sent with the `"appium:"` prefix — just like vendor-specific annotations live under dedicated packages in Java. The critical QA truth: a test launched with a wrong or missing capability fails in CI with "session not created" — and reading which parameter was wrong from the logs can cost hours of debugging time.

Appium 3 Capability Prefix Rule

Java — UiAutomator2Options (Recommended)

Java — Appium 3.x Capabilities (Type-Safe)

Micro Lab: Code practice

Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.

Why Is UiAutomator2Options Safer Than DesiredCapabilities?

The CHAIN starting with new…

The CHAIN starting with `new UiAutomator2Options()` REPLACES the old string-based `DesiredCapabilities` + `capability("key", "value")` approach — TYPE-SAFE methods like `.setPlatformName(...)` let a misspelled key be CAUGHT at COMPILE time.

W3C STANDARD capabilities (platformName…

W3C STANDARD capabilities (`platformName`, `deviceName`) get NO prefix, but Appium-SPECIFIC ones (`automationName`, `app`) are AUTOMATICALLY sent with the `appium:` prefix by java-client — you don't hand-write this.

.setApp(...) OR .setAppPackage(...) +…

`.setApp(...)` OR `.setAppPackage(...)` + `.setAppActivity(...)` — TWO DIFFERENT scenarios: if the APK is NOT YET on the device, `setApp` INSTALLS it; if already installed, package+activity DIRECTLY OPENS the app.

.setNoReset(false) RESETS app data before…