In Appium, what does appium:deviceName select on Android compared with iOS?
answer
- friendly key, unfriendly behaviour
- not a core capability at all
- one platform selects, the other only logs
- Android selects by udid or avd
basics
~10 sOn iOS, appium:deviceName together with appium:platformVersion picks a simulator by model and runtime. On Android the drivers accept the key but never select with it; appium:udid or appium:avd chooses the target there.
solid answer
~40 s`appium:deviceName` is not a core Appium capability — the core constraint list does not carry it. It is declared by the Android drivers and, separately, by the XCUITest driver, and the two do different things with it. On an Apple simulator it genuinely selects: it names the model, and `appium:platformVersion` names the runtime, so the pair narrows a Mac's several installed simulators to one. On Android it is accepted, logged, and never read for selection — the target is chosen by `appium:udid` (an attached handset or a running emulator, by the serial adb reports) or by `appium:avd` (an emulator by AVD name). An Android request carrying only `appium:deviceName` has stated a preference nothing acts on, and it fails silently.
go deeper
Be ready to say plainly that appium:deviceName selects a simulator on Apple platforms, alongside appium:platformVersion, and selects nothing on Android, where appium:udid and appium:avd do that job.
Explain the mechanics: the key is declared per driver rather than by the core, the XCUITest driver maps it onto how simctl identifies a simulator, and the Android drivers simply never read it for selection.
Show how you catch a silent mis-selection in a real suite: what the green-but-wrong run looks like, why the report agrees with the mistake, and what you change so every run names its own machine.
Own the guardrail rather than the fix — how a capability map is reviewed or validated before a fleet runs on it, so a key that is accepted but never acted on cannot quietly define your evidence.
`appium:deviceName` is the friendliest-looking key in an Appium session request and the one most likely to do nothing. Whether it selects anything at all depends on the platform, and that divergence is the content of this topic rather than a footnote to it. ## It is not a core capability Appium's own constraint list — the capabilities the base driver accepts for every session — does not carry `appium:deviceName`. The key is declared by the Android drivers and, separately, by the XCUITest driver. Two drivers declaring the same name is not the same as two drivers doing the same thing with it, and here they do not. That is worth holding onto, because it explains why nothing in the core enforces a single meaning for the key. ## On an Apple simulator it genuinely selects For a simulator, `appium:deviceName` is how you name the target. It carries the model name, and it works with `appium:platformVersion`, which carries the runtime. Both are load-bearing: a Mac usually has the same model installed against several runtimes, so a model name on its own is ambiguous, and the pair is what narrows it to one. The XCUITest driver reaches simulators through `simctl`, where a simulator really is identified by a name and a runtime, so the capability maps onto something the platform already has. For a real Apple device the answer changes again — there the request names the target with `appium:udid`. ## On Android it selects nothing The Android drivers declare `appium:deviceName`, so the server accepts it. Nothing warns. It rides along with the session and appears wherever the capability map is printed. What it does not do is choose which attached handset or which emulator the session drives. That job belongs to two other keys: - `appium:udid` — names a target by the serial adb reports for it, which covers a real handset and a running emulator alike. - `appium:avd` — names an Android Virtual Device by its AVD name. An Android request that carries `appium:deviceName` and neither of those has expressed a preference the driver never reads. ## Side by side | | Android | Apple simulator | Apple real device | | --- | --- | --- | --- | | does `appium:deviceName` select? | no | yes | no | | what selects instead | `appium:udid` or `appium:avd` | it is the selector | `appium:udid` | | companion key required | none | `appium:platformVersion` | none | ## Why it bites a dental-recall suite Picture the dental-recall booking app with two lanes and one shared capability template. The Apple lane was written first, so the template carries `appium:deviceName`. Someone adds the Android lane by copying it, changing `platformName` and `appium:automationName`, and setting `appium:deviceName` to the name of the reception tablet in the lab rack. Every run afterwards is green. Then the recall-reminder screen starts failing intermittently. The report says the run was on the reception tablet, so the investigation goes to that tablet and finds nothing. The Android requests never named a target the driver acts on, so the sessions were not necessarily on that tablet at all, and the failure turns out to be a layout problem on a screen size nobody believed was in the run. That is the shape of the whole failure class: 1. The session starts normally, so there is no error message to search for. 2. The capability map looks complete and reads sensibly to a human. 3. The report quotes the request, so the report agrees with the wrong belief. 4. The symptom surfaces as flakiness, or as a device-specific bug nobody can reproduce on the device they think ran it. ## What to write instead - On Android, name the target with `appium:udid` or `appium:avd`, and treat `appium:deviceName` as a comment. - On an Apple simulator, always send `appium:deviceName` and `appium:platformVersion` together. - On a real Apple device, use `appium:udid`. - Wherever a report or dashboard says device, make sure it prints the key that selected on that platform, not the friendliest key in the map. The rule that survives all of it: a capability is accepted by the server and acted on by the driver, and those are two different tests. `appium:deviceName` passes the first on both platforms and the second on only one.
- If Android ignores it for selection, why does the key exist there at all?The Android drivers declare it, so the server accepts it and it travels with the session — readable in logs and in whatever a report copies out of the capability map. What it is not is an input to target selection, which is `appium:udid` and `appium:avd` alone. Accepted and acted on are different things.
- Two Apple simulators of the same model are installed against different runtimes. What does a request with only appium:deviceName get?An under-specified request. The model name matches more than one installed simulator, so `appium:platformVersion` is what narrows it to the runtime you meant. Naming the model alone leaves the choice to something other than your request, and a dental-recall run can end up on a runtime it never named.
It is the name on an office door. In one building reception really does route visitors by that name; in the other the sign is decoration and only the badge number opens anything.
saying these in an interview costs you the question
- Thinks appium:deviceName picks the Android handset a session drives
- Expects an error when Android ignores appium:deviceName
- Names an Apple simulator by model alone, with no platformVersion
- Treats appium:deviceName as a core Appium capability
- Reads appium:deviceName in an Android report as proof of the device