* fix(storage-plugin): add fs.sanitizeName for the delete request
* move empty check as well
* fix: apply formatter
* return false for exception cases
* return false for exception cases
* tweak a bit
* fix format
* feat: add IPC channels per session for drivers and plugins to communicate (fix#22206)
* lint
* export AppiumIpc
* fix test issues
* import AppiumIpc directly from basedriver
* fakedriver is used directly outside of appium so can't rely on existence of IPC
* make ipc functions async with lock and better types
* fix assignIpc types
* deduplicate session object deletion
* ipcGuard -> withIpc
* address various review comments
* lint
* address copilot and other review comments
* store only last message. change model to use subscription object and async generator
* enforce max message size in bytes
* fix tests and call the message payload 'data' for clarity
* lint
* make assignIpc optional on drivers for backwards compatibility
* add error handling in startClock since it is usually not awaited
* add docs
* remove todo comment
* apply copilot and eglitise suggestions
* add typedoc
* add error handling to onIpcInit
* apply more suggestions
* fix schema unit test
* apply more suggestions
* add links to ipc examples
* make minimum ipc message size 1 instead of 0
* ensure publisher names are friendly to consumers
* fix ipc message time unit
* use already included sizeof for objs
* just pass error obj to log
* be more typescriptey about our ipc guard
* make max obj size part of opts for appiumipc
* let unsubscribe return whether it worked
* improve ipc types and shapes
* apply master package-lock.json
* update schema config
* use javascript naming conventions
* clarify distinction between message and payload (data)
* ensure async iterator loop ends when unsubscribe is called
* ensure the right things happen when you unsubscribe
* make require ipc more ergonomic
* remove unnecessary async locks and de-asyncify methods
* simplify interface and just use subscriber/plugin names
* fix docs
* fix lint
* document isActive
* add note about topic namespace
* use sleep instead of delay
* restrict the ipc payload data type to something that can be cloned
* clarify topic namespacing recommendation
* make sure listeners and promises are cleaned up in async iterator
* clean up ipc internal names
* readonly
* address review comments
* make ipcmessage readonly
* readonly cause why not
Appium's base-driver had no dedicated ProtocolError subclass for
the W3C WebDriver 'no such shadow root' error. Every such response
from an underlying browser (the GetShadowRoot command against an
element whose shadow DOM is absent) fell through the
w3cErrorCodeMap lookup to UnknownError, making client-side error
handling (Selenium's NoSuchShadowRootException in particular)
unreachable.
Add NoSuchShadowRootError with error='no such shadow root' /
w3cStatus=404 / code=65, register it in the errors map so
errorFromW3CJsonCode returns it, and extend the existing
errors.spec table-tests to lock the new mapping.
Fixes#22209
Signed-off-by: SAY-5 <say.apm35@gmail.com>
* ci: update publish docs workflow
* use docs:publish
* Add step to fetch gh-pages before publishing docs
* ci: run after 'Appium Server Release' completion
BREAKING CHANGE: The `Promise` object in the script context now matches the global `Promise` object instead of `bluebird`. Methods specific to `bluebird` are no longer supported.
* fix(appium): fix session id handling more
* modify the comment
* Refine comments in getSessionId and the log
Updated comments for clarity and corrected typos.
* chore(base-driver): update type of express-serve-static-core
* modify
* clean up a bit
* use debug
* remove error, address possible array case
* chore: remove a line
Check if the driver proxy is active before proceeding.
* Refine security documentation for clarity
Corrected formatting and phrasing for clarity and consistency throughout the document. Adjusted security feature descriptions and command examples.
* Fix typos in security documentation
* Update security.md for multiple insecure features
Clarified section on enabling multiple insecure features for drivers.
* Update security.md to remove insecure feature examples
Removed examples of insecure feature commands.
* Remove section on multiple insecure features
Removed the section on enabling multiple insecure features for specific drivers.
* Fix formatting of appium command examples in security.md
In repositories indexed by CodeGraph (a `.codegraph/` directory exists at the repo root), reach for it BEFORE grep/find or reading files when you need to understand or locate code:
- **MCP tool** (when available): `codegraph_explore` answers most code questions in one call — the relevant symbols' verbatim source plus the call paths between them, including dynamic-dispatch hops grep can't follow. Name a file or symbol in the query to read its current line-numbered source. If it's listed but deferred, load it by name via tool search.
- **Shell** (always works): `codegraph explore "<symbol names or question>"` prints the same output.
If there is no `.codegraph/` directory, skip CodeGraph entirely — indexing is the user's decision.
@@ -3,7 +3,6 @@ description: Create a new bug report.
title:'🐞 bug:<title>'
labels:[Bug, Needs Triage]
body:
- type:markdown
attributes:
value:':stop_sign:_Make sure you are reporting an issue. For general questions, please use [http://discuss.appium.io](http://discuss.appium.io)._'
@@ -13,9 +12,9 @@ body:
label:Is there an existing issue for this?
description:'Please [search :mag:the issues](https://github.com/appium/appium/issues) to check if this bug has already been reported.'
options:
- label:I have searched the existing issues
required:true
- label:I have searched the existing issues
required:true
- type:input
attributes:
label:Appium Version
@@ -49,7 +48,7 @@ body:
description:|
You can retrieve the latest server/driver/plugin version number by running `npm info <package-name> version`. If you are not up to date, please try to reproduce your issue after updating all affected components.
options:
- label:I confirm the issue is still reproducible with the latest component versions
- label:I confirm the issue is still reproducible with the latest component versions
- type:textarea
attributes:
@@ -82,10 +81,10 @@ body:
:warning: _Remember to redact or remove any sensitive information!_
value:|
- Debug details (`appium --show-debug-info`):
- Last component version(s) which did _not_ exhibit the problem:
- Platform and version of device under test:
- Real device or emulator/simulator:
- Debug details (`appium --show-debug-info`):
- Last component version(s) which did _not_ exhibit the problem:
When reviewing JavaScript or TypeScript changes, check new uses of Node.js built-in APIs against the supported Node.js versions declared in package.json#engines.node. The current supported range is ^20.19.0 || ^22.12.0 || >=24.0.0.
For each new Node.js built-in API or option, verify that it exists and is stable across all supported Node.js versions. If any supported version lacks the API, only supports it experimentally, or has different behavior, leave a review comment and suggest using the existing dependency, adding a fallback, avoiding the API, or raising the engine requirement.
Example: util.styleText exists in Node.js 20.12+, but only became stable in Node.js 22.13.0 and 23.5.0. Because this repository supports Node.js 20.19.0 and 22.12.0, replacing a color library with util.styleText should be flagged unless the project explicitly accepts relying on a non-stable API for those supported versions.
# This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs
name:Publish docs
on:
workflow_dispatch:
workflow_run:
workflows:['Appium Server Release']
types:
- completed
jobs:
build:
runs-on:ubuntu-latest
strategy:
matrix:
node-version:[18.x]
# See supported Node.js release schedule at https://nodejs.org/en/about/releases/
Appium is a piece of technology, but **the core of the Appium community is the people in it**. As such, we are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, gender identity and expression, sexual orientation, ability, physical appearance, body size, race, age, socioeconomic status, religion (or lack thereof), or other marginalized aspect of community members. We expect all members of the Appium community to abide by this Code of Conduct whenever interacting in Appium venues (pull requests, GitHub issues, 1-1 or group chat, meetups, conferences, etc...)
### Examples of inappropriate behavior
Because we come from a variety of backgrounds, we don't want to assume that everyone has the same assumptions about what is and isn't appropriate. Here are some examples of inappropriate behavior that are incompatible with our community's ethos:
* Spamming, trolling, intentionally disrupting conversations, or irrelevant solicitation or advertisement
* Making demeaning or discriminatory comments
* Making negative assumptions about someone's background, abilities, or intentions
* Harassing or stalking individuals (online or in person)
* Giving someone unwelcome sexual attention or making unwelcome physical contact (in the case of an IRL event)
* Sharing sexual images or using sexually explicit language
In general: treat others how you would like to be treated, were you in their place. Don't be a jerk. _Do_ ask questions. _Do_ keep conflicts productively focused on technical issues. _Do_ think before you speak; remember that what is perceived as a funny witticism in your group of friends might be hurtful or reinforce hurtful stereotypes in the context of our diverse online community. _Do_ remember that we are all people, not robots, and all equally deserving of sensitivity and respect. (If and when robots join our community, let's treat them with respect too!)
### What will organizers do about inappropriate behavior?
If we notice you doing or saying something inappropriate, an organizer will explain why it's inappropriate and ask you to stop. We won't demonize or vilify you. But please do stop the inappropriate behavior so we can get back to writing and discussing code in a safe environment. If you have philosophical disagreements about what's actually inappropriate, please take them to a separate public or private conversation with an Appium maintainer so we don't turn pull requests into an ethics debate.
If you keep doing unacceptable things, we'll likely ban you, report you to GitHub, or take other appropriate action.
### What if I see or am subject to what feels like inappropriate behavior?
Let us know! Please notify a community organizer as soon as possible. Full contact information is listed in the [Contact Info](#contact-info) section of this document. All communications will be kept strictly confidential, unless otherwise required by law. No issue will be considered too inconsequential or unimportant for us to have a conversation about.
### Contact Info
If you need to report an incident, please contact any of the following organizers directly:
* Isaac Murchie [email](mailto:isaac@saucelabs.com) [twitter](https://twitter.com/imurchie)
* Jonathan Lipps [email](mailto:jlipps@saucelabs.com) [twitter](https://twitter.com/jlipps)
### Credit, License, and Attribution
This Code of Conduct is distributed under a [Creative Commons Attribution-ShareAlike license](http://creativecommons.org/licenses/by-sa/3.0/).
It's inspired among other things by:
* [Citizen Code of Conduct](http://citizencodeofconduct.org/)
Appium is excited to participate as a [Google Summer of Code](https://summerofcode.withgoogle.com/) sponsor project. Here's a fun list of ideas that a Summer of Code student participant can use as a foundation for thinking about what to contribute to Appium!
|Idea|Description|
|----|-----------|
|Apple tvOS Support|Our users have been asking for an Appium driver for Apple tvOS apps. Is this possible? We're not entirely sure! Why not be awesome and build it?|
|Test App revamp|Appium uses a number of poorly-designed mobile applications in its own testing. We have to use a variety of apps because we need to test that Appium can automate all the various controls and platform features that mobile vendors provide. Really what we need is one cross-platform app (or one app per platform) that exhibit all and only the features we need to test. This would be a fun project to build some mobile apps used for testing and also demoing Appium at events and in training videos, etc...|
|Tooling and Performance|We haven't instrumented Appium with very many performance metrics, and don't really know if we're missing some low-hanging fruit in terms of performance. Maybe you can help us do that?|
|Babel|We have a lot of repos, and they're all on a really old version of Babel. They all need to stay in sync. How can we make this situation better, and upgrade to the latest and greatest?|
|Unity3d Driver|Historically, Appium hasn't been great at automating games. We don't have any particular support for the frameworks used to create games. Unity is a popular one, for example. What if we could write an Appium driver that talked to an embedded process in a test version of a Unity game, that allowed us to find and interact with 3d elements? It would be amazing! You can also be amazing and lead Appium into this new world.|
|Testing the Internet of Things|Appium's architecture makes it dead simple to integrate drivers for automating new technologies. What about _really_ new technologies like IoT devices? Help to redefine the semantics of the WebDriver protocol for use with IoT, and build a driver for an IoT device to prove it out.|
|Driver for X|Have an idea of something else Appium could automate that it doesn't already? Build a driver for it! This would involve some awesome Node.js code, plus whatever else is needed to integrate with the platform you have in mind.|
Hopefully this gives you some ideas of fun projects that would be substantial and long-lasting contributions to the Appium community.
* **storage-plugin:** add fs.sanitizeName for the delete request as well ([#22362](https://github.com/appium/appium/issues/22362)) ([5fee017](https://github.com/appium/appium/commit/5fee01752f2782e96fbe64fd13520b433d4a7535))
* add IPC channels per session for drivers and plugins to communicate ([#22211](https://github.com/appium/appium/issues/22211)) ([97c879c](https://github.com/appium/appium/commit/97c879cdd02e6fcccaaea45a8d1a7088bed4ae66)), closes [#22206](https://github.com/appium/appium/issues/22206)
* Limit the maximum count of topics per session and make it configurable ([#22279](https://github.com/appium/appium/issues/22279)) ([0264775](https://github.com/appium/appium/commit/0264775ecb8ecaca9dac2eae47784da02a653255))
* make assignIpc internal ([#22278](https://github.com/appium/appium/issues/22278)) ([25d922b](https://github.com/appium/appium/commit/25d922b7d3062c306c1631d6f5c227600ddd226a))
* use exact version for dependencies in monorepo packages instead of ^ ([#22090](https://github.com/appium/appium/issues/22090)) ([86c8f23](https://github.com/appium/appium/commit/86c8f23a670d0bbc2d359a8235828606bd36e6aa))
* Avoid attaching plugins to a non-existing session ([#21964](https://github.com/appium/appium/issues/21964)) ([9f5faf5](https://github.com/appium/appium/commit/9f5faf5bedffe6196742c09c6793a6450af48ac9))
* **logger:** Make sure we always have single logger instance per process ([#21991](https://github.com/appium/appium/issues/21991)) ([4daaa14](https://github.com/appium/appium/commit/4daaa14c29bed129d329d0881a93ecdb9de77676))
* Type imports ([#22025](https://github.com/appium/appium/issues/22025)) ([2f27425](https://github.com/appium/appium/commit/2f27425ea300ca1af1c1da6e4be68d48e7a94346))
* **appium:** Add repository links to verbose extensions list ([#21813](https://github.com/appium/appium/issues/21813)) ([ce91686](https://github.com/appium/appium/commit/ce91686852b0baab5f46990f5d40db4747922924))
### Bug Fixes
* **appium:** appium symlink behavior across drivers/plugins installations ([#21837](https://github.com/appium/appium/issues/21837)) ([529aeb4](https://github.com/appium/appium/commit/529aeb48f10419e21555cec05835ff07bb0e2e51))
* apply npm run lint:fix ([#21867](https://github.com/appium/appium/issues/21867)) ([5e28714](https://github.com/appium/appium/commit/5e28714442cf59ee35b085e01e82c3f5483891fd))
* **docs:** add missing verbose flag for CLI list command ([#21814](https://github.com/appium/appium/issues/21814)) ([dcfaa88](https://github.com/appium/appium/commit/dcfaa88830f6a5c608c92f5ae72445e065261d38))
<p>Copyright <a href="https://openjsf.org">OpenJS Foundation</a> and Appium contributors. All rights reserved. The <a href="https://openjsf.org">OpenJS Foundation</a> has registered trademarks and uses trademarks. For a list of trademarks of the <a href="https://openjsf.org">OpenJS Foundation</a>, please see our <a href="https://trademark-policy.openjsf.org">Trademark Policy</a> and <a href="https://trademark-list.openjsf.org">Trademark List</a>. Trademarks and logos not indicated on the <a href="https://trademark-list.openjsf.org">list of OpenJS Foundation trademarks</a> are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.</p>
# Announcing LambdaTest as Appium's Newest Development Partner
As part of our ongoing effort to recognize organizations that meaningfully support the Appium project through dedicated maintainer time, we are excited to welcome our newest Development Partner: LambdaTest!
LambdaTest has long been an active participant in the automated testing ecosystem. Today, they are officially formalizing their commitment by investing people—dedicated engineers who will directly support Appium's development, maintenance, and ecosystem growth.
This kind of hands-on contribution is crucial for ensuring Appium continues to evolve. We deeply value partners who empower their engineering teams to contribute code directly to open source rather than just sponsorship.
LambdaTest engineers are already contributing actively across several key Appium repositories. Their current focus includes:
**appium-mcp**– Supporting Appium's implementation of the Model Context Protocol (MCP) to drive forward modern AI-assisted capabilities.
**appium-remote-xpc**– Contributing to the native macOS/XPC-based remote execution layer, essential for iOS automation.
**appium-tun-tap**– Assisting in the development and maintenance of network virtualization and tunneling components for advanced testing scenarios.
These contributions strengthen critical infrastructure within the Appium ecosystem and demonstrate LambdaTest's commitment to deep technical involvement in the project's evolution.
About LambdaTest
LambdaTest’s platform already serves a massive community of Appium users. As a GenAI-powered Quality Engineering Platform, they provide a full-stack testing cloud with 10,000+ real mobile devices and 3,000+ browsers.
Beyond standard infrastructure, they are pushing the boundaries of test execution with AI-native test management and next-generation agents like KaneAI. By supporting Appium alongside Selenium, Playwright, and other major frameworks, LambdaTest helps teams orchestrate intelligent automation at cloud scale.
LambdaTest will continue contributing people, code, and development expertise to strengthen Appium's core functionality. Their commitment represents a significant investment into the future of the framework, and we're thrilled to have them collaborating with us at this deeper level.
The Appium project is proud to recognize LambdaTest as our newest official Development Partner. We can't wait to see what we'll build together!
| `platformName` | `string` | yes | The type of platform hosting the app or browser |
| `appium:automationName` | `string` | yes | The name of the Appium driver to use |
| `browserName` | `string` | no | The name of the browser to launch and automate, if the driver supports web browsers as a special case |
| `appium:app` | `string` | no | The path to an installable application |
| `appium:deviceName` | `string` | no | The name of a particular device to automate, e.g., `iPhone 14` (currently only actually useful for specifying iOS simulators, since in other situations it's typically recommended to use a specific device id via the `appium:udid` capability). |
| `appium:platformVersion` | `string` | no | The version of a platform, e.g., for iOS, `16.0` |
| `appium:newCommandTimeout` | `number` | no | The number of seconds the Appium server should wait for clients to send commands before deciding that the client has gone away and the session should shut down. `60` seconds by default. Setting it to zero disables the timer. |
| `appium:noReset` | `boolean` | no | If true, instruct an Appium driver to avoid its usual reset logic during session start and cleanup (default `false`) |
| `appium:fullReset` | `boolean` | no | If true, instruct an Appium driver to augment its usual reset logic with additional steps to ensure maximum environmental reproducibility (default `false`) |
| `appium:eventTimings` | `boolean` | no | If true, instruct an Appium driver to collect [Event Timings](./event-timing.md) (default `false`) |
| `appium:printPageSourceOnFindFailure` | `boolean` | no | If true, collect the page source and print it to the Appium log whenever a request to find an element fails (default `false`) |
Drivers are also able to place more complex constraints on capabilities as a group. For example,
the XCUITest driver recommends that at least one of `browserName`, `appium:app`, or `appium:bundleId`
is included in the capabilities, otherwise it will not be able to auto-install or auto-launch any
application. Each driver will document how it interprets these capabilities and any other
platform-specific requirements.
Some drivers place more complex constraints on capabilities as a group. For example, while the
`appium:app` and `browserName` capabilities are listed above as optional, if you want to launch
a session with a specific app, the XCUITest driver requires that at least one of `appium:app`,
`browserName`, or `appium:bundleId` are included in the capabilities (otherwise it will not know
what app to install and/or launch and will simply open a session on the home screen). Each driver
will document how it interprets these capabilities and any other platform-specific requirements.
The way to construct capabilities and start a session will likely differ depending on your Appium
client. For examples of doing this in each client library, head to the [Ecosystem Clients](../ecosystem/clients.md)
page and click through to the appropriate client documentation.
!!! note
Capabilities are like parameters used when starting a session. After the capabilities are sent
and the session is started, they cannot be changed. If a driver supports updating aspects of
its behaviour in the course of a session, it will provide a [Setting](./settings.md) for this
purpose instead of, or in addition to, a capability.
Each Appium client has its own way of constructing capabilities and starting a session. For
examples of doing this in each client library, head to the [Ecosystem](../ecosystem/index.md) page
and click through to the appropriate client documentation.
Once your capabilities are sent to the server and the session is started, they cannot be
changed. If a driver supports updating its behaviour during a session, it will use the
[Settings API](./settings.md) for this purpose.
## BiDi Protocol Support
Appium supports [WebDriver BiDi](https://w3c.github.io/webdriver-bidi/) protocol since base–driver 9.5.0.
The actual behavior depends on individual drivers while the Appium and the baseｰdriver support the protocol.
Please make sure if a driver supports the protocol and what kind of commands/events it supports in the documentation.
In addition to the standard WebDriver protocol (now known as WebDriver Classic), Appium supports the
[WebDriver BiDi](https://w3c.github.io/webdriver-bidi/) protocol. Support for this protocol is
opt-in, and requires the use of the standard `webSocketUrl` capability.
@@ -31,36 +31,28 @@ Appium when starting it from the command line:
|`--allow-insecure`|Turns on _only_ specified features, except those blocked by `--deny-insecure`. Has no effect when used in combination with `--relaxed-security`|
|`--deny-insecure`|Explicitly turns _off_ specified features, overriding `--relaxed-security` and `--allow-insecure`|
All of the above arguments can also be specified in the [Appium Configuration file](./config.md).
Features passed to `--allow-insecure`/`--deny-insecure` must be specified as a comma-separated list,
and each feature in the list must additionally include a prefix, indicating the driver to which the
feature should apply. The prefix can be either the driver's `automationName`, or the wildcard (`*`)
symbol, if the feature should be applied to all drivers. The prefix and feature name are separated
using the colon character (`:`).
and each feature in the list must additionally include a prefix, indicating the driver to whose
sessions the feature should apply. The prefix can be either the driver's `automationName`, or the
wildcard (`*`) symbol, if the feature should be applied to all drivers. The prefix and feature name
are separated using the colon character (`:`).
For example, `first:foo` refers to the `foo` feature for the `first` driver, whereas `*:bar` refers
to the `bar` feature for all drivers.
## Insecure Features
Each Appium driver is responsible for its own security, and can create its own feature names. Thus
you should read through the documentation for a particular driver to know which feature names it
might use. Here is an incomplete list of examples from some of Appium's official drivers:
Almost all insecure features are defined on a per-driver or plugin basis, so make sure to read the
documentation for a particular driver/plugin to know which feature names it might use.
Sets the storage access policy of the current browsing context.
#### Parameters
|Name|Description|Type|
|--|--|--|
|`blocked`|Whether storage access should be blocked (`true`) or allowed (`false`)|boolean|
|`origin`|The origin to which the policy should be applied. Must be either a valid URL, or an asterisk (`*`) if the policy should apply to all origins.|string|
#### Response
`null`
## Web Authentication Protocol
The [Web Authentication protocol](https://w3c.github.io/webauthn/) (WebAuthn) is an extension of
Lists all installed extensions, plus all official extensions that are not installed.
@@ -134,6 +140,7 @@ appium {driver|plugin} list
|`--installed`|Only list all installed extensions|boolean|
|`--json`|Return the result in JSON format|boolean|
|`--updates`|List all extensions along with information on whether newer versions are available. Only supported for extensions installed via `npm`.|boolean|
|`--verbose`|Show additional details for each extension|boolean|
|`--address`, `-a`|IPv4/IPv6 address to listen on|string|`0.0.0.0`|
|`--allow-cors`|Allow web browser connections from any host|boolean|`false`|
|`--allow-insecure`|List of [insecure features](../../guides/security.md) that should be allowed in this server's sessions. Individual features can be overridden by `--deny-insecure`. Has no effect in combination with `--relaxed-security`.|array<string>|`[]`|
|`--allow-unknown-args`|Do not exit if unrecognized command-line arguments are passed to the server; ignore them instead. Useful when the Appium CLI is wrapped by external tooling that appends extra flags.|boolean|`false`|
|`--base-path`, `-pa`|Base path to use as the prefix for all webdriver routes running on the server|string|`""`|
|`--callback-address`, `-ca`|Callback IP address|string|`0.0.0.0`|
| `platformName` | Type of platform hosting the app or browser | `string` |
| `appium:automationName` | Name of the Appium driver to use | `string` |
### Optional Capabilities
These capabilities are used in the Appium server/base driver, but are optional, and may have a
default value.
| <div style="width:19em">Capability</div> | Description | Type | Default |
|--|--|--|--|
| `webSocketUrl` | Toggle support of the WebDriver BiDi protocol | `boolean` ||
| `appium:eventTimings` (deprecated) | Toggle collection of [Event Timings](../../guides/event-timing.md). This capability is deprecated - please use the [`getLogEvents`](../api/appium.md#getlogevents) endpoint instead. | `boolean` ||
| `appium:newCommandTimeout` | Number of seconds the Appium server should wait for clients to send commands before stopping the session. A value of `0` disables the timeout. | `number` | `60` |
| `appium:printPageSourceOnFindFailure` | Toggle retrieval of the the page source and its printing to the Appium log, whenever a request to find an element fails | `boolean` ||
### Validated Capabilities
These capabilities are not directly used in the Appium server/base driver, but are still subject to
validation checks due to their relevance in other drivers. The actual handling of these
capabilities is optional and entirely driver-dependent.
Here you can find links to additional Appium resources around the web:
## Websites
- [Appium Pro](https://appiumpro.com) - a blog and newsletter written by one of Appium's
maintainers, Jonathan Lipps, with lots of useful guides
## Online Courses
- [Appium and Selenium Fundamentals](https://ui.headspin.io/university/learn/appium-selenium-fundamentals-2020) - a comprehensive video course on learning Python, Selenium, and Appium by Jonathan Lipps
@@ -26,3 +21,4 @@ maintainers, Jonathan Lipps, with lots of useful guides
# Announcing LambdaTest as Appium's Newest Development Partner
As part of our ongoing effort to recognize organizations that meaningfully support the Appium project through dedicated maintainer time, we are excited to welcome our newest Development Partner: LambdaTest!
LambdaTest has long been an active participant in the automated testing ecosystem. Today, they are officially formalizing their commitment by investing people—dedicated engineers who will directly support Appium's development, maintenance, and ecosystem growth.
This kind of hands-on contribution is crucial for ensuring Appium continues to evolve. We deeply value partners who empower their engineering teams to contribute code directly to open source rather than just sponsorship.
LambdaTest engineers are already contributing actively across several key Appium repositories. Their current focus includes:
**appium-mcp**– Supporting Appium's implementation of the Model Context Protocol (MCP) to drive forward modern AI-assisted capabilities.
**appium-remote-xpc**– Contributing to the native macOS/XPC-based remote execution layer, essential for iOS automation.
**appium-tun-tap**– Assisting in the development and maintenance of network virtualization and tunneling components for advanced testing scenarios.
These contributions strengthen critical infrastructure within the Appium ecosystem and demonstrate LambdaTest's commitment to deep technical involvement in the project's evolution.
About LambdaTest
LambdaTest’s platform already serves a massive community of Appium users. As a GenAI-powered Quality Engineering Platform, they provide a full-stack testing cloud with 10,000+ real mobile devices and 3,000+ browsers.
Beyond standard infrastructure, they are pushing the boundaries of test execution with AI-native test management and next-generation agents like KaneAI. By supporting Appium alongside Selenium, Playwright, and other major frameworks, LambdaTest helps teams orchestrate intelligent automation at cloud scale.
LambdaTest will continue contributing people, code, and development expertise to strengthen Appium's core functionality. Their commitment represents a significant investment into the future of the framework, and we're thrilled to have them collaborating with us at this deeper level.
The Appium project is proud to recognize LambdaTest as our newest official Development Partner. We can't wait to see what we'll build together!
@@ -31,36 +31,30 @@ Appium when starting it from the command line:
| `--allow-insecure` | Turns on _only_ specified features, except those blocked by `--deny-insecure`. Has no effect when used in combination with `--relaxed-security` |
| `blocked` | Whether storage access should be blocked (`true`) or allowed (`false`) | boolean |
| `origin` | The origin to which the policy should be applied. Must be either a valid URL, or an asterisk (`*`) if the policy should apply to all origins. | string |
#### Response
`null`
## Web Authentication Protocol
The [Web Authentication protocol](https://w3c.github.io/webauthn/) (WebAuthn) is an extension of
Lists all installed extensions, plus all official extensions that are not installed.
@@ -135,6 +141,7 @@ appium {driver|plugin} list
| `--installed` | Only list all installed extensions | boolean |
| `--json` | Return the result in JSON format | boolean |
| `--updates` | List all extensions along with information on whether newer versions are available. Only supported for extensions installed via `npm`. | boolean |
| `--verbose` | Show additional details for each extension | boolean |
| `--address`, `-a` | IPv4/IPv6 address to listen on | string | `0.0.0.0` |
| `--allow-cors` | Allow web browser connections from any host | boolean | `false` |
| `--allow-insecure` | List of [insecure features](../../guides/security.md) that should be allowed in this server's sessions. Individual features can be overridden by `--deny-insecure`. Has no effect in combination with `--relaxed-security`. | array<string> | `[]` |
| `--allow-unknown-args` | Do not exit if unrecognized command-line arguments are passed to the server; ignore them instead. Useful when the Appium CLI is wrapped by external tooling that appends extra flags. | boolean | `false` |
| `--base-path`, `-pa` | Base path to use as the prefix for all webdriver routes running on the server | string | `""` |
| `webSocketUrl` | Toggle support of the WebDriver BiDi protocol | `boolean` | |
| `appium:eventTimings` (deprecated) | Toggle collection of [Event Timings](../../guides/event-timing.md). This capability is deprecated - please use the [`getLogEvents`](../api/appium.md#getlogevents) endpoint instead. | `boolean` | |
| `appium:newCommandTimeout` | Number of seconds the Appium server should wait for clients to send commands before stopping the session. A value of `0` disables the timeout. | `number` | `60` |
| `appium:printPageSourceOnFindFailure` | Toggle retrieval of the the page source and its printing to the Appium log, whenever a request to find an element fails | `boolean` | |
### Validated Capabilities
These capabilities are not directly used in the Appium server/base driver, but are still subject to
validation checks due to their relevance in other drivers. The actual handling of these
capabilities is optional and entirely driver-dependent.
Here you can find links to additional Appium resources around the web:
## Websites
- [Appium Pro](https://appiumpro.com) - a blog and newsletter written by one of Appium's
maintainers, Jonathan Lipps, with lots of useful guides
## Online Courses
- [Appium and Selenium Fundamentals](https://ui.headspin.io/university/learn/appium-selenium-fundamentals-2020) - a comprehensive video course on learning Python, Selenium, and Appium by Jonathan Lipps
@@ -26,3 +21,4 @@ Here you can find links to additional Appium resources around the web:
We're thrilled to announce that Appium Conf is back and going online for 2024! This is the official Appium conference where you can learn all about what's new in Appium 2.0 and explore the latest in automating tests for devices, mobile apps, and desktop applications.
@@ -17,29 +17,29 @@ We're thrilled to announce that Appium Conf is back and going online for 2024! T
</a>
</div>
## Mark Your Calendars: September 13, 2024
## 标记您的日历：2024年9月13日
Join us on September 13, 2024, for a full day of inspiring and practical talks from the Appium team and the world's top mobile testing and automation experts. With Appium 2.0 now well-established, this is your opportunity to dive deep and learn how to maximize its potential.
1. **Gain Insights**: Hear interesting insights and inspiring case studies from global experts and the core Appium team.
2. **Improve Your Strategy**: Gain valuable knowledge to enhance your own automation strategy.
3. **Network**: Make connections with Appium users from around the globe.
4. **Learn from Specialists**: Benefit from Appium specialists' expertise on a variety of topics.
1. **获得见解**：听取全球专家和核心Appium团队的有趣见解和鼓舞人心的案例研究。
2. **改进您的战略**：获得有价值的知识，以增强您自己的自动化战略。
3. **网络**：与来自全球的Appium用户建立联系。
4. **向专家学习**：从Appium专家在各种主题上的专业知识中受益。
## Call for Proposals: Share Your Knowledge!
## 征集提案：分享您的知识！
We're looking for a diverse range of speakers from around the globe who are eager to share innovative ideas and use-cases of mobile test automation. If you have experience with Appium and insights that could benefit the community of test practitioners, we want to hear from you!
Don't miss this chance to contribute to the Appium community and showcase your expertise on a global stage.
不要错过这个机会，为Appium社区做出贡献，并在全球舞台上展示你的专业知识。
## How to Submit Your Proposal
## 如何提交您的提案
Visit our website at [https://appiumconf.com/](https://appiumconf.com/) and [Submit a Proposal](https://confengine.com/conferences/appium-conf-2024/proposals?utm_medium=referal&utm_source=appium.io&utm_campaign=launch). We're excited to see your innovative ideas and experiences with Appium!
Keep an eye on our website and social media channels for updates on the conference schedule, keynote speakers, and more exciting details about Appium Conf 2024.
# Announcing LambdaTest as Appium's Newest Development Partner
As part of our ongoing effort to recognize organizations that meaningfully support the Appium project through dedicated maintainer time, we are excited to welcome our newest Development Partner: LambdaTest!
LambdaTest has long been an active participant in the automated testing ecosystem. Today, they are officially formalizing their commitment by investing people—dedicated engineers who will directly support Appium's development, maintenance, and ecosystem growth.
This kind of hands-on contribution is crucial for ensuring Appium continues to evolve. We deeply value partners who empower their engineering teams to contribute code directly to open source rather than just sponsorship.
LambdaTest engineers are already contributing actively across several key Appium repositories. Their current focus includes:
**appium-mcp** – Supporting Appium's implementation of the Model Context Protocol (MCP) to drive forward modern AI-assisted capabilities.
**appium-remote-xpc** – Contributing to the native macOS/XPC-based remote execution layer, essential for iOS automation.
**appium-tun-tap** – Assisting in the development and maintenance of network virtualization and tunneling components for advanced testing scenarios.
These contributions strengthen critical infrastructure within the Appium ecosystem and demonstrate LambdaTest's commitment to deep technical involvement in the project's evolution.
About LambdaTest
LambdaTest’s platform already serves a massive community of Appium users. As a GenAI-powered Quality Engineering Platform, they provide a full-stack testing cloud with 10,000+ real mobile devices and 3,000+ browsers.
Beyond standard infrastructure, they are pushing the boundaries of test execution with AI-native test management and next-generation agents like KaneAI. By supporting Appium alongside Selenium, Playwright, and other major frameworks, LambdaTest helps teams orchestrate intelligent automation at cloud scale.
LambdaTest will continue contributing people, code, and development expertise to strengthen Appium's core functionality. Their commitment represents a significant investment into the future of the framework, and we're thrilled to have them collaborating with us at this deeper level.
The Appium project is proud to recognize LambdaTest as our newest official Development Partner. We can't wait to see what we'll build together!
# Generate reference and build the mkdocs site into the site dir
# 生成参考文档并将 mkdocs 站点构建到 site 目录
npx appium-docs build
# Same as build, but host the docs on a local dev server
# and watch for changes and rebuild when files change
# 与 build 相同，但会在本地启动开发服务器
# 并监听文件变化，在内容变更时自动重建
npx appium-docs build --serve
# Build the docs and deploy them with mike versioning to the docs-site branch
# using the included commit message.
# This is particularly useful for pushing content to a GitHub pages branch!
# 构建文档并使用 mike 进行版本化部署到 docs-site 分支
# 其中包含内置提交信息。
# 这对于把内容推送到 GitHub Pages 分支特别有用！
npx appium-docs build \
--deploy \
-b docs-site \
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
github-actions
