Fix missing screenshots in Testinium Suite after upgrading to Appium 2
If your mobile tests run on Testinium Suite but screenshots no longer appear in the test report after an Appium 2 upgrade, start by checking the driver integration.
Testinium Suite captures screenshots automatically and links them to test steps. You don’t need to add a custom takeScreenshot() method to enable this. The Appium session needs to be registered with Testinium Suite through the appropriate driver.
This guide covers Java projects that use Maven and have migrated from Appium 1 to Appium 2.
Check your Maven configuration
Open pom.xml and check that the Maven repository used by Testinium Suite is included under <repositories>:
<repositories>
<repository>
<id>testinium-mvn</id>
<url>https://mvn.testinium.com/repository/public/</url>
</repository>
</repositories>If you already have a <repositories> section, add the repository entry to it.
Next, check that your <dependencies> section includes testinium-appium2-driver, the Appium 2 driver library for Testinium Suite.
Choose the latest release compatible with your project’s Appium and Java dependencies from the Maven repository. Replace YOUR_DRIVER_VERSION below with that exact version before building. If you’re unsure which release to use, confirm it with Testinium Suite support.
<dependency>
<groupId>com.testinium</groupId>
<artifactId>testinium-appium2-driver</artifactId>
<version>YOUR_DRIVER_VERSION</version>
</dependency>Keep the selected version pinned in pom.xml so builds use the same release. If you migrated an older project, also check for driver dependencies left over from the Appium 1 setup.
Confirm the dependency resolves
Build the project:
mvn clean installThen inspect the dependency tree:
mvn dependency:treeFind com.testinium:testinium-appium2-driver in the output and confirm that its resolved version matches the version you selected.
If Maven reports any of the following errors, check the repository configuration and access before continuing:
- Could not resolve dependencies
- Could not find artifact
- Failed to read artifact descriptor
- 401 Unauthorized
- Connection refused
Use the Testinium Suite driver classes
Adding the dependency is only part of the setup. Your project also needs to create its Testinium Suite mobile sessions with TestiniumAndroidDriver or TestiniumIOSDriver.
Check DriverFactory, DriverManager, hooks, and any helper that creates a driver.
For Android, replace direct driver creation such as:
new AndroidDriver(hubUrl, capabilities);with:
new TestiniumAndroidDriver(hubUrl, capabilities);For iOS, use:
new TestiniumIOSDriver(hubUrl, capabilities);Review any remaining calls that create Testinium Suite mobile sessions directly through AndroidDriver, IOSDriver, AppiumDriver, or RemoteWebDriver.
Why the driver matters
The driver registers the Appium session with Testinium Suite. That registration allows Testinium Suite to recognize the session and associate screenshots with its test steps.
Internally, the registration includes this call:
TestiniumDriver.registerDriver(this.getSessionId(), this);This is handled by the driver library. You don’t need to copy it into your test code. Upgrading the Appium dependency alone doesn’t complete the Testinium Suite integration.
Check the active profile and capabilities
When the testinium profile is active, the driver classes prepare capabilities using values from the Testinium Suite environment. Outside that profile, the implementations described here return the supplied capabilities unchanged.
Check that your run uses the expected profile, then review the final capabilities in the execution logs. Look for:
[FINAL CAPS] Final Overridden CapabilitiesCompare the logged values with the device and application selected for the run.
Check | Android | iOS |
|---|---|---|
Platform | platformName: Android | platformName: iOS |
Device | appium:udid | appium:udid |
Automation engine | appium:automationName: UiAutomator2 | appium:automationName: XCUITest |
Application identifiers | appium:appPackage, appium:appActivity | appium:bundleId |
Application location | Application path or URL supplied by the Testinium Suite environment | Application path or URL supplied by the Testinium Suite environment |
Additional settings | Permissions, command timeout, reset strategy, and Device Park options | Alerts, command and WDA timeouts, prebuilt WDA, derived data path, reset strategy, and Device Park options |
Remove conflicting capability overrides
Check whether DriverFactory, hooks, configuration classes, or other helpers redefine values managed by the Testinium Suite driver classes.
For example, another configuration layer might set a different automation engine or device:
capabilities.setCapability("appium:automationName", anotherAutomationName);
capabilities.setCapability("appium:udid", anotherDevice);Review these assignments for conflicts. Let TestiniumAndroidDriver and TestiniumIOSDriver manage the capabilities they derive from the Testinium Suite environment, and make sure any project-specific configuration stays compatible with those values.
Pay particular attention to the platform, device ID, automation engine, application identifiers, application location, command timeout, and WDA or Device Park settings.
Run a test and check the report
After updating the configuration, run a test on Testinium Suite and check that screenshots appear against its steps.
Before investigating further, confirm that:
- Maven resolves testinium-appium2-driver with the exact version you selected.
- Testinium Suite mobile sessions use TestiniumAndroidDriver or TestiniumIOSDriver.
- The testinium profile is active for the Testinium Suite run.
- The final capabilities match the device and application selected for the run.
- Other configuration layers don’t introduce conflicting capability values.
If screenshots are still missing, continue with the Testinium Suite executor, Appium session, and Device Park logs for the affected run. These are the next places to investigate once the dependency, driver, and capability checks are complete.