Same Katalon Test Cases Pass on Android POS Devices but Fail on Tablet

Mobile Testing
1

Hi Katalon Community,

I’m facing an issue with my Android automation using Katalon Studio + Appium and would appreciate some guidance.

The same test cases and same automation code are working successfully on multiple Android POS devices, but when I execute them on an Android Tablet, some of the test cases fail.

Environment

  • Automation Tool: Katalon Studio
  • Automation: Appium
  • Platform: Android
  • Application: Android POS application
  • Devices: Android POS devices and Android Tablet
  • Test Cases: Same test cases
  • Automation Code: Same code
  • Application Build: Same build

Current Behavior

The automation works as expected on the Android POS devices.

I have tested the POS application automation on multiple Android versions/devices, and the test cases are working fine.

However, when I execute the same test cases on the Android Tablet, some test cases fail.

So the issue appears to be specific to the tablet environment rather than the test case itself.

What I would like to understand

Could anyone help me understand what could cause the same Katalon/Appium test case to behave differently between an Android POS device and an Android Tablet?

For example, could differences such as:

  • Screen size
  • Screen resolution
  • Screen density/DPI
  • Device configuration
  • Android UI rendering
  • Element hierarchy
  • Jetpack Compose UI behavior
  • Appium element detection
  • Synchronization/timing
  • Orientation
  • Tablet-specific application layout

cause the same automation to pass on a POS device but fail on a tablet?

My Questions

  1. What are the main things I should compare between the working POS device and the failing tablet?
  2. How can I identify whether the issue is related to element identification, UI layout, Appium, or Katalon?
  3. Is there any recommended approach in Katalon for running the same Android automation across different screen sizes and device types?
  4. Are there any specific Katalon/Appium capabilities or settings that should be checked when executing on tablets?
  5. What logs or information should I collect from the tablet to identify the root cause?

I am not using coordinate-based actions in my automation.

The same POS application and automation framework are already working across multiple Android POS devices/versions. The problem occurs when running the same automation on the tablet.

I can provide the following if required:

  • Katalon Studio version
  • Appium version
  • Android version
  • POS device details
  • Tablet model/details
  • Screen resolution and DPI
  • Appium Inspector element hierarchy
  • Katalon execution logs
  • Appium server logs
  • Screenshot/video of the failure
  • Failing test case and locator details

Any suggestions on how to troubleshoot this difference between the POS device and tablet would be greatly appreciated.

Thank you!

2

Can you provide the actual failure/stack trace as your issue is like generic

3

This is a classic tablet-specific UI/locator issue — the app likely renders differently on tablets (different layouts, element hierarchies, or timing). Here’s how to systematically troubleshoot:

1. Compare Element Hierarchies First

Use Appium Inspector on both devices:

  • POS device: Capture the element tree for a failing step

  • Tablet: Capture the same element tree

  • Look for differences:

    • Different resource-id, class, or content-desc

    • Elements nested under different parent containers

    • Tablet using a two-pane layout (common in Android tablets) while POS uses single-pane

Action: If locators differ, use relative XPath or Android UI Automator strategies that work across both:

groovy

// Instead of absolute XPath:
// //android.widget.Button[@text='Submit']

// Use Android UI Automator:
Mobile.tap(findTestObject('Object Repository/Btn_Submit'), 0)
// With selector: 'new UiSelector().text("Submit").className("android.widget.Button")'

2. Check for Tablet-Specific Layouts

Android apps often have adaptive layouts:

  • POS: Single-column, compact UI

  • Tablet: Two-column, expanded UI with sidebars or split views

Common issues:

  • Buttons move to a different screen region

  • Dialogs appear as inline panels instead of popups

  • Navigation changes from hamburger menu to bottom nav or side drawer

Action: Inspect the app on the tablet — does it use Jetpack Compose or ConstraintLayout with different constraints? If so, update locators to be layout-agnostic.

3. Verify Synchronization/Timing

Tablets may have different performance characteristics:

  • Slower rendering on older tablets

  • Different animation durations

  • Different CPU/GPU performance

Action: Add explicit waits or increase timeouts for tablet runs:

groovy

// In Project Settings > Execution > Mobile > Android
// Increase "Default wait for element timeout" from 30s to 45s [156]

// Or add explicit waits in test:
Mobile.waitForElementPresent(findTestObject('Object Repository/Btn_Submit'), 45)

4. Check Appium Capabilities

Ensure you’re using the same capabilities for both devices:

groovy

// In Project Settings > Mobile > Android
"appium:automationName": "UiAutomator2"
"appium:deviceName": "Tablet_Model_Name"
"appium:platformVersion": "13.0"
"appium:appPackage": "com.your.app"
"appium:appActivity": ".MainActivity"

Key capability to check: appWaitActivity — if the tablet launches a different activity (e.g., tablet-specific launcher), add it:

groovy

"appium:appWaitActivity": "com.your.app.*"

5. Collect Diagnostic Logs

From the tablet, gather:

  • Appium server logs (set log level to DEBUG in Katalon Preferences > Mobile

  • Katalon execution logs (check for element not found or timeout errors)

  • Screenshot/video of the failure (enable in Katalon test settings)

  • Android logcat output:

    bash

    adb logcat -d > tablet_logcat.txt

Look for:

  • ElementNotFoundException — locator issue

  • TimeoutException — synchronization issue

  • SessionNotCreatedException — capability mismatch

6. Recommended Katalon Approach for Multi-Device Testing

  • Use device-specific Test Object repositories if layouts differ significantly

  • Create conditional logic in tests:

    groovy

    if (DriverFactory.getWebDriver().getCapabilities().getCapability("deviceName").contains("Tablet")) {
    // Use tablet-specific locators
    } else {
    // Use POS locators
    }

  • Consider separate test suites for tablet vs. POS if the divergence is too large

Quick Checklist

Check POS Tablet Action
Element hierarchy (Appium Inspector) :white_check_mark: :cross_mark: Update locators
App layout (single vs. two-pane) :white_check_mark: :cross_mark: Use layout-agnostic selectors
Element timeouts 30s 30s Increase to 45s for tablet
appWaitActivity capability Set Not set Add wildcard com.your.app.*
Appium log level DEBUG INFO Set both to DEBUG
4

Okay let me try to answer all your 5 questions

  1. What should I compare between the working POS and failing tablet?

Since the same Katalon test cases pass on the Android POS devices but fail on the tablet check below as listed

I would compare the below listed five areas:

A. Device/environment

  • Android version/build
  • Device model
  • Screen resolution
  • Screen density/DPI
  • Orientation – portrait vs landscape
  • Display/font scaling
  • Navigation mode
  • Developer options
  • USB debugging/ADB connection
  • App permissions
  • Same APK/version/build number

B. Application UI

For the exact step that fails, better inspect the element on both devices using Katalon Mobile Spy/Appium Inspector and compare:

  • resource-id
  • content-desc
  • text
  • className
  • bounds
  • clickable
  • enabled
  • displayed
  • Parent/ancestor hierarchy

The above comparison would be the most most important comparison.

The same application can expose a different Android UI hierarchy on a tablet because the application may use a different layout for larger screens.

C. Locator

Check whether the Test Object uses something fragile such as:

//android.widget.LinearLayout[2]/android.widget.TextView[1]

or indexes/positions.

Prefer stable attributes such as resource-id, content-desc, or another unique attribute.

D. Timing

Check whether the tablet is simply slower to render the screen. Compare how long the application takes to reach the failing state.

Katalon’s Mobile execution settings include a default element wait, delay between actions, and Appium newCommandTimeout.

E. Appium session

Compare the effective desired capabilities for both devices, especially:

  • platformName
  • platformVersion
  • deviceName
  • udid
  • automationName
  • appPackage
  • appActivity
  • appWaitActivity
  • noReset
  • newCommandTimeout

Katalon allows Android desired capabilities to be configured per device under Project > Settings > Desired Capabilities > Mobile > Android.

5

2. How do I determine whether the problem is element identification, UI layout, Appium, or Katalon?

A very simple decision tree helps here.

Case 1 – Element does not exist in the tablet hierarchy

If the element is present on the POS but completely absent from the tablet hierarchy:

Most likely application/UI-layout/device configuration issue.

The application may be rendering a different tablet layout.

Case 2 – Element exists on tablet but the Katalon locator cannot find it

Most likely element identification/locator issue.

Compare the attributes and hierarchy and make the locator device-independent.

Case 3 – Katalon finds the element but cannot click/type/swipe

check:

  • element not actually clickable
  • overlay
  • keyboard
  • scrolling
  • element outside viewport
  • animation
  • synchronization
  • enabled/disabled state

This is generally an interaction/synchronization issue, not an object-recognition issue.

Case 4 – Appium cannot start the application/session

Investigate Appium/device/capability configuration.

Look at the Appium log and capabilities.

Case 5 – Appium session is healthy but Katalon reports an internal/runtime exception

Then investigate Katalon version, plugin/driver compatibility, or a Katalon-specific defect.

We cannot classify something as a Katalon defect until the same failure has been reproduced after ruling out the locator, application UI, device and Appium layers.

6

3. Is there a recommended Katalon approach for different screen sizes/device types?

Yes. The main principle should be:

Make the automation semantic, not coordinate- or layout-position-dependent.

Avoid:

  • absolute coordinates
  • hard-coded screen positions
  • XPath based heavily on indexes
  • assumptions about a particular screen size
  • assumptions about portrait/landscape

Instead, identify controls using stable attributes such as:

resource-id

content-desc

text

or a robust relative XPath.

For example, avoid:

//android.widget.LinearLayout[3]/android.widget.TextView[2]

and prefer something based on a unique application identifier:

//*[@resource-id='com.company.app:id/submitButton']

If the application genuinely renders two different layouts for phone/POS and tablet, then better create device/layout-aware Test Objects, while keeping the test logic itself common.

In other words:

Test logic should remain common; only the object identification should vary when the application UI genuinely varies.

Katalon’s current mobile guidance also recommends starting with one representative device and then adding different screen sizes/OS versions to expose layout, keyboard, permission and timing issues systematically rather than debugging a large device matrix at once.

7

4. Are there any specific Katalon/Appium capabilities or settings that should be checked when executing on tablets??

I would first compare the capabilities between the working POS and tablet.

At minimum:

platformName
platformVersion
deviceName
udid
automationName
appPackage
appActivity
appWaitActivity
noReset
newCommandTimeout
orientation

orientation is particularly worth checking if the POS is landscape and the tablet is portrait, or vice versa. Katalon supports configuring orientation through desired capabilities.

Also check Katalon’s:

Project > Settings > Execution > Mobile

In current Katalon versions, the Mobile execution settings include:

  • New Command Timeout
  • Default Wait for Element Timeout
  • Delay Between Actions

The default newCommandTimeout is currently 60 seconds for new projects, and an appium:newCommandTimeout capability can override the project-level value.

I would not blindly increase all timeouts, though. First determine whether the tablet is actually slower or whether the element is different/missing.

Also verify the Appium environment itself. Current Katalon documentation supports Appium 3 and the UiAutomator2 driver for Android.

If the POS and tablet are being executed through different machines/agents, also make sure they are not actually using different Appium/Katalon/Android driver environments.

8

If possible please provide these details

9

whether you issue got resolved?

10

If not, then provide us some specific information

11

it’s not about locator or other issues, the latest tab or mobile devices are blocking the background actions, due to that appium servers are stopping. so I have made some changes for run in background. so now it’s working.

Thankyou for your response

12

My issue got resolved, Thankyou.

13

kindly share the working solution foe everyone’s knowledge