Vega SDK 0.24 VVD: automation-toolkit crashes on every takeScreenshot (ECONNRESET), then dies after 3 calls until reboot

Vega Open Beta Bug Reports
1

Summary

On the Vega Virtual Device shipped with SDK 0.24.x, the Appium GET /session/:id/screenshot command (automation-toolkit JSON-RPC takeScreenshot) never succeeds. Each call resets the connection, and the toolkit process is restarted by systemd. After 3 crashes in a short window the service stops being restarted and every JSON-RPC method (including getPageSource and injectInputKeyEvent) is dead until the VVD is rebooted. Re-touching /tmp/automation-toolkit.enable does not recover it.

The same host setup against the SDK 0.23.8358 VVD works fine (screenshots and continuous ~7 fps screenshot polling for minutes).

Environment

Item Value
Vega SDK 0.24.9914 (also 0.24.9785 and 0.24.9859 – see below)
Vega CLI 1.2.18
Host macOS 15 (Apple Silicon)
Appium 3.7.0 (also reproduced with the recommended driver)
@amazon-devices/appium-kepler-driver 3.30.0
automation-toolkit on device /usr/bin/automationToolkitServer from the 0.24 system image (763,056 bytes, md5 120bc35a…)
Device VVD only (not tested on a physical Fire TV)

Steps to reproduce

  1. vega virtual-device start (SDK 0.24.9914), then vega exec vda shell 'touch /tmp/automation-toolkit.enable'.
  2. vega device start-port-forwarding --port 8383 --forward true.
  3. Alternate getPageSource and takeScreenshot against http://127.0.0.1:8383/jsonrpc with params: {}.

Observed (VVD freshly booted, launcher in foreground, no app needed):

Call Result
getPageSource 200, element tree returned
takeScreenshot #1 connection reset after ~0.25 s; 3 s later getPageSource works again (service restarted)
takeScreenshot #2 same
takeScreenshot #3 connection reset; from now on getPageSource is refused instantly
wait 75 s / rm + touch /tmp/automation-toolkit.enable still refused; only a VVD reboot recovers

Through Appium the same shows up as:

GET /session/:id/screenshot -> 500 "getScreenshot: There was an error while fetching screenshot data"
Failed to take screenshot AxiosError: socket hang up (code: ECONNRESET)

The Kepler driver retries once on a fresh port-forward, so a single Appium screenshot call costs two toolkit crashes. Anything that polls screenshots (video recording helpers, Appium Inspector) kills the toolkit within a second.

What changed between 0.23 and 0.24

Extracting /usr/bin/automationToolkitServer from vvd/images/tv/image_files/system.ext4 of each SDK:

SDK size notes
0.23.8128 / 0.23.8358 523,728 B (identical) links libwayland-server.so.0; screenshot works on VVD
0.24.9785 / 0.24.9859 / 0.24.9914 763,056 B (identical; the whole system.ext4 is byte-identical across the three) new build (VegaUIAutomator-1.0.53564.0), no wayland dependency; screenshot now goes through com.amazon.kepler.graphics.IScreenshotManager2 / requestScreenShot2; contains the string Failed to take screenshot. Reason:

So the toolkit’s screenshot implementation was moved to the Kepler graphics screenshot manager in 0.24, and on the VVD that path crashes the process. No crash dump is written to SYSTEM_TOMBSTONE/acr, and nothing toolkit-related appears in loggingctl log.

Questions

  1. Is the VVD in 0.24 expected to support IScreenshotManager2? If not, could the toolkit return a JSON-RPC error instead of crashing (the crash also takes down getPageSource/key injection after the systemd start limit)?
  2. Is there a way to restart automation-toolkit.service from the developer shell without rebooting the VVD?
  3. Is a fixed VVD image planned for a 0.24.x patch?

Related but different threads: #28630 (real device, DRM, {"value": null}), #25113 (real device, “Buffer is null”).

4

Hi @r-ando

Thank you for the thorough report.

About your three questions: I’ll confirm with the internal teams and will follow up here.

One question to help scope it for the team: since your repro is VVD-only, have you been able to check whether takeScreenshot works on a physical Fire TV device on 0.24? That would tell us whether this is VVD-image-specific or a broader 0.24 toolkit issue.
I’ll note it as VVD-only for now.

Warm Regards,
Ivy

5

Thanks Ivy. I was able to test on a physical Fire TV, and the answer is: this crash does not reproduce on hardware — it looks VVD-image-specific.

Physical device details:

  • Fire TV stick, OS 1.1 (TV Ship), build 4.0.344088.0, June 18 2026.
  • Its automationToolkitServer is a different build from the VVD (476,896 bytes vs the 0.24 VVD’s 763,056 bytes), so this is not the exact same toolkit binary as the 0.24 SDK VVD image — worth keeping in mind.

Running the same alternating getPageSource / takeScreenshot loop against it (toolkit enabled, port-forwarded 8383):

  • takeScreenshot returned two real screenshots (~11 MB PNG each), and otherwise returned graceful JSON-RPC errors — Unable to take screenshot, timeout reached and Screenshot error: Buffer is null.
  • Crucially, the toolkit never crashed: every call got a proper JSON-RPC response, and getPageSource returned 200 after every single takeScreenshot, including after repeated errors. There was no connection reset and no service death.

So the behavior I originally reported (connection reset on takeScreenshot, and the toolkit dying after ~3 calls until reboot) is specific to the 0.24 VVD image; the physical device degrades gracefully instead. The Buffer is null I saw on hardware matches the existing thread 25113 (a headless stick with no active display buffer), which is a separate, non-fatal issue.

Net: on the VVD side the crash is deterministic and content-independent, and identical across 0.24.9785 / 0.24.9859 / 0.24.9914 (byte-identical system.ext4); the 0.23.8358 VVD works with the same host stack; and hardware doesn’t crash. That points at the 0.24 VVD image’s screenshot path (IScreenshotManager2 on the emulated graphics stack) rather than a universal 0.24 toolkit defect. Happy to run anything else on the VVD to help narrow it further.

6

Thanks @r-ando

That’s a really clean isolation, and exactly what we needed.
We are checking this internally.
No further testing needed from you for now - I’ll reach out if we need a specific VVD capture. Really appreciate the thorough investigation.

Warm regards,
Ivy

7

Hi team

I think this is affected also our tests
I am getting this issue trying to make a find element

POST /session/da8db603-e445-4df1-b398-c0b02dff5bac/element {"using":"xpath","value":"//child[@test_id='onboardingWelcomeText']"}

[da8db603][VegaDriver@3fc3] Calling AppiumDriver.findElement() with args: ["xpath","//child[@test_id='onboardingWelcomeText']","da8db603-e445-4df1-b398-c0b02dff5bac"]

Error
Encountered internal error running command: Error: socket hang up

On physical devices the restart is not working so we are completely blocked
Active SDK Version: 0.24.9914
Vega CLI Version: 1.3.4

Device info

{

  "idme": "XXXXXXXX",

  "os": "OS",

  "hostname": "firestick-XXXXXXXXX",

  "architecture": "armv7l",

  "profile": "tv",

  "product": "callie",

  "buildDescription": "OS 1.2 (TV Ship/44)",

  "deviceName": "",

  "kvdVersion": "",

  "simulated": false,

  "inDeveloperMode": true,

  "user": "app_user"

}