skip to content

In Appium, how do you take system animation out of a greenhouse climate run on Android and iOS?

level: middleimportance: must knowfreq 52%

answer

  1. stop the motion, do not time it
  2. scales on Android, a preference on Apple
  3. one is a capability, one is a setting
  4. disableWindowAnimation versus reduceMotion
  5. neither freezes app-drawn frames

basics

~20 s

Turn the motion off at the device. On Android the appium:disableWindowAnimation capability drops the system animation scales for the session; on Apple platforms the XCUITest driver's reduceMotion setting asks the OS to prefer non-motion transitions.

solid answer

~40 s

Two different levers, because the platforms animate differently. On Android, `appium:disableWindowAnimation` switches the device's global window, transition and animator scales off for the session, so platform-drawn motion simply does not play. On Apple platforms the equivalent is the accessibility Reduce Motion preference, reachable as the XCUITest driver's `reduceMotion` setting — driver settings can be sent at session start in the `appium:settings[reduceMotion]` form — with `animationCoolOffTimeout` as the settle-side companion for motion that still plays. Neither switch promises a still screen: they govern the platform's own transitions, not frames the greenhouse climate app draws itself, and Android's scales are device-wide state rather than a per-session sandbox. Write each platform's own switch; do not assume one shared flag.

code

python · 23 lines
python
from appium import webdriver
from appium.options.common import AppiumOptions

android = AppiumOptions().load_capabilities({
    'platformName': 'Android',
    'appium:automationName': 'UiAutomator2',
    'appium:appPackage': 'com.example.greenhouse',
    'appium:appActivity': '.ClimateActivity',
    'appium:disableWindowAnimation': True,
})

ios = AppiumOptions().load_capabilities({
    'platformName': 'iOS',
    'appium:automationName': 'XCUITest',
    'appium:bundleId': 'com.example.greenhouse',
    'appium:settings[reduceMotion]': True,
})

driver = webdriver.Remote('http://127.0.0.1:4723', options=android)
try:
    print(driver.get_settings())
finally:
    driver.quit()

go deeper

for a junior

Know that the two platforms have different switches and be able to say which is which: a capability on the Android side, a driver setting on the Apple side. Do not offer a single shared flag.

for a middle

Explain the mechanisms underneath — device-wide animation scales on Android, the accessibility Reduce Motion preference on Apple platforms — and say what each switch leaves untouched, starting with animation the app draws itself.

for a senior

Show where you would configure both sides so a fleet cannot be half-protected, and describe what you expect to see afterwards: one class of failures gone, and any data race it was hiding now visible.

for a principal

Argue when motion suppression belongs in the device image or fleet baseline rather than in every capability map, and own the trade-off that a suite running with animation off no longer exercises the transitions real users see.

## Why motion makes a mobile run intermittent Appium finds an element, gets back a handle and a rectangle, then sends an interaction that lands at a point. If the screen is mid-transition those three steps disagree with each other: the element existed when the tree was read, and it has moved by the time the pointer goes down. The failure is intermittent because it depends on the phase of an animation relative to the round trip between client, Appium server and device-side agent — a race that resolves differently on a loaded CI host than on a workstation. Both platforms animate by default and both offer a way to stop, but the two mechanisms are not the same kind of thing. A suite that configures one and assumes the other is quietly unprotected on half its fleet. ## Android: switch the animation scales off Android keeps device-wide animation scales — window, transition and animator. Setting them to zero is the platform's own way of saying "do not animate", and it is what instrumentation runners have always done. Appium exposes it as a capability: - `appium:disableWindowAnimation` — the driver turns the scales off for the session, so platform-drawn window and transition motion does not play. - The scales are **device state, not session state**. On a shared device or a long-lived emulator, expect the change to be visible to anything else running there while it is in effect. - Because the switch sits at the OS level it covers activity transitions and system-drawn motion at once. You do not disable animation screen by screen. ## Apple platforms: reduce motion, then cool off Apple's equivalent is not a scale factor but the accessibility preference **Reduce Motion**, which asks the platform to substitute low-motion transitions. The XCUITest driver exposes `reduceMotion`, one of the names in its settings reference, and driver settings can be supplied at session start through the `appium:settings[<name>]` capability form: - `reduceMotion` — asks the platform to prefer non-motion transitions for the run. - `animationCoolOffTimeout` — the settle-side companion: how long the driver lets animation quieten before it proceeds. Suppression and settling are different tools and the driver ships both. - Simulators and real devices differ in what an outside process may toggle, so treat the preference as something the environment provides rather than something a test asserts. ## The two side by side | | Android | Apple platforms, XCUITest driver | |---|---|---| | Mechanism | device-wide animation scales set to zero | the accessibility Reduce Motion preference | | Appium surface | `appium:disableWindowAnimation` capability | `reduceMotion` setting | | Settle companion | none of its own | `animationCoolOffTimeout` | | Scope of the change | device-wide while it is set | the platform's own transitions | ## What neither switch covers 1. **App-drawn motion.** A progress spinner, a chart that tweens its own bars, or a custom frame-by-frame loop is the app's own drawing. The platform switches govern platform transitions; they are not a global freeze. In a greenhouse climate app, the humidity chart that animates its own line after each poll keeps animating. 2. **Work hiding behind the motion.** A transition often overlaps a network call. Removing the animation removes the *visual* race and exposes the data race that was hiding under it — a better failure, not the absence of one. 3. **The other platform.** `appium:disableWindowAnimation` is an Android capability and does nothing on an XCUITest session; `reduceMotion` is an XCUITest setting with no Android twin. That is the whole point of the split. 4. **A device that is simply slow.** Suppressing motion makes screens settle sooner; it does not make an oversubscribed emulator or simulator fast. ## Getting it right in a real suite - Build both platforms' capabilities in one place, so a capability map cannot silently carry only the Android half. - Judge the change by whether the class of failure disappeared, not by whether the setting was accepted. - Keep the app's own transitions in mind: if the vent-schedule screen cross-fades its own chart, that motion survives both switches and is an app-side change, not a driver setting. - Do not reach for these switches to paper over a control that is genuinely not ready yet. Suppressing motion narrows the window in which the screen lies to you; it does not tell you the screen is finished. - Remember that Android's scales are global: if a device is shared with a manual tester or another suite, the change is visible to them for the life of the session.

  • Does turning animation off guarantee the screen is still?
    No. Both switches govern platform-drawn transitions — Android's animation scales and Apple's Reduce Motion preference. An app running its own drawing loop, such as a tweened humidity chart, keeps moving. Suppression removes one class of races and often exposes the data race that was hiding under the transition, which is a more honest failure than a mid-animation mis-tap.
  • Where would you set these so a cross-platform suite cannot end up configuring only one side?
    In one capability factory that builds both option sets from the same call, so the Android branch adds `appium:disableWindowAnimation` and the Apple branch adds the `reduceMotion` setting. A suite that hand-writes two capability maps in two files is exactly how a fleet ends up protected on one platform and exposed on the other.

saying these in an interview costs you the question

  • Says one animation flag works on both Android and iOS
  • Calls reduceMotion a UiAutomator2 setting
  • Believes disabling animation freezes app-drawn motion too
  • Treats Android's animation scales as per-session sandboxed state
  • Confuses waiting for animation to settle with removing it