Docs

Frequently Asked Questions

Before contacting support, run through the following checks to rule out issues with your tests or test commands.

Reproducing the Issue Locally

Download your app build and test binary from RobusTest, then run the following ADB commands directly on a device to verify your test package is behaving as expected.

List all test classes in your test package:

adb shell am instrument -w -e log true -e class {test class name} {application package name}/{test runner name}

List all test methods in your test package:

adb shell am instrument -w -r -e log true -e class {test class name} {application package name}/{test runner name}

This confirms which classes and methods RobusTest will pick up when running your Espresso job.

Devices Show as Free but Job Stays in Queue

Possible reasons:

  1. Device pool mismatch — When submitting an Espresso job, you specify whether devices should be picked from the general pool or a specific device group. If you selected the general pool, devices in a specific group will not be used, and vice versa.

  2. Insufficient devices — The minimum number of devices requested is higher than the number currently available in the selected pool or group.

  3. Startup delay — There is typically a 2–3 minute window between job submission and when RobusTest picks it up and reserves devices. This is expected and temporary.

Setting a Job Timeout

If you need a job to close automatically after a certain time (common in CI pipelines), pass the runTimeout attribute under setting.job in your job request. The value is in seconds and represents the total time allowed for the job — including both waiting and running time.

{
  "setting": {
    "job": {
      "runTimeout": 3600
    }
  }
}

If the job exceeds this duration, RobusTest will end it automatically.

Closing a Job After Submission

You can close a running or queued job by sending a DELETE request to the job endpoint:

DELETE /v3/job/<JOB_ID>

Example:

DELETE /v3/job/abc123

Scheduled Job Did Not Trigger

Symptom: A scheduled job does not start at its configured time. The last execution is either missing or was triggered manually.

Cause: The minDeviceCount in the job payload was not met at the time the job was scheduled to run. If fewer devices are available than the configured minimum — due to devices being offline or occupied by other jobs — the job will not trigger.

Example: If minDeviceCount is set to 8 but only 6 devices are available at trigger time (because some are offline and others are running a different job), the scheduled job is skipped entirely.

Fix:

  1. Check how many devices were available at the scheduled trigger time and compare against minDeviceCount in the job payload.
  2. Reduce minDeviceCount if the full device count is not reliably available at that time.
  3. Ensure devices are online and not occupied by other jobs before the scheduled trigger time.
  4. If the issue recurs, review the scheduling of other jobs to avoid overlap with this job's trigger window.

Symptom: Opening a deeplink on a device shows an "Update App" prompt instead of navigating to the expected screen. Tests fail or are blocked at this screen.

Cause: A pre-installed version of the app (e.g., a production or older build) is present on the device alongside the test build. The system prompts an update because the installed version conflicts with the deeplink target.

Fix:

Remove the pre-installed app from the device before running tests. Once the conflicting app is uninstalled, retry the deeplink — it should open directly into the test build without the update prompt.

If the issue persists after removing the pre-installed app, report back with the device ID and test run link for further investigation.

Device Language Setting Not Enabled

Symptom: Tests fail or behave unexpectedly because the device language is not set to the expected locale (e.g., a local/regional language is active instead of English).

Fix:

Perform the following steps on the affected device:

  1. Go to Settings → General → Language & Region → Language
  2. Select the desired local language
  3. Tap Prefer English

This ensures the device defaults to English while keeping the regional language available, which prevents locale-related test failures.

Job Runs with Only One Device — No Parallel Execution

Symptom: A job starts with fewer devices than expected (e.g., only one device) even though other devices in the group appear free. No parallel runs are seen.

Cause:

The addMoreDevices option in Job Run settings is disabled. When this is off, the job starts as soon as the configured minDeviceCount is met using only the devices available at the exact moment the job is initiated. Devices that become free later are not added.

Example: If minDeviceCount is set to 1 and 4 out of 5 devices in the group are already occupied by another job, the new job starts immediately with the one free device and never picks up the others — even after they become free.

Fix:

Enable the addMoreDevices option in the Job Run settings. This allows RobusTest to assign additional devices to the job as they become available during execution.

App Installation Fails Due to Insufficient Device Storage

Error:

Not enough space for promise: <X> bytes needed, <Y> bytes available. Insufficient storage.

Possible reasons and fixes:

  1. Device storage is full — The device does not have enough free space to install the app or test binary. Clear unused apps and caches on the device before retrying.

  2. Large APK size — If the app or test APK is unusually large, try reducing the build size or running the job on a device with more available storage.

  3. Mark device offline — If the device consistently runs out of space, flag it offline in RobusTest until storage is freed or the device is reset. Contact your device lab administrator.

Devices Remain Offline After Restart or Maintenance

Symptom: After a scheduled device restart or maintenance activity, some devices do not come back online automatically and require manual intervention.

Possible reasons and fixes:

  1. Trust or authorization prompt — After a restart, the device may display a trust prompt that blocks reconnection. This requires physical access to dismiss.

  2. Escalate to device lab team — If devices consistently fail to reconnect after restart, escalate to the device lab administrator with the specific device IDs and restart schedule.