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…)
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
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)?
Is there a way to restart automation-toolkit.service from the developer shell without rebooting the VVD?
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”).
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.
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.
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.
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
Thanks. I confirmed that 0.24.12112 fixes the crash (400+ screenshots, no toolkit restarts).
A new problem shows up on the VVD, though: takeScreenshot returns a stale frame on every other call inside apps. After a focus change, the first screenshot still shows the previous state, even 2 s later, while the page source and the actual VVD window already show the new state. On an idle screen, consecutive calls alternate between the current and the old image indefinitely. It reproduces with the stock helloWorld-rn72 template (6/6), but not on the built-in Settings screen. It looks like the capture alternates between the buffers of a double-buffered surface.
Attached:
Two comparison images: host window capture vs. Appium screenshots after a key press, and consecutive screenshots on an idle screen
A data point that may help narrow this down: the frame that the emulator itself returns does not alternate on the same VVD.
The Android emulator underneath the VVD has its own gRPC API (EmulatorController), which it turns on once its console has been sent grpc <port>. On the VVD from SDK 0.24.12112 (OS 1.2), inside an RN 0.83 app, we polled EmulatorController.getScreenshot back to back: 168 calls in 4 s gave 8 distinct frames, each at a real change (a key press, then a 220 ms piece slide captured frame by frame). Between them the idle screen came back identical on every call, with no current/old alternation. That suggests the alternation comes from the automation toolkit’s capture path rather than from the display itself.
