Summary
After agent-device snapshot returns, the Android snapshot-helper instrumentation (am instrument -w … SnapshotInstrumentation) is left running, which holds the single Android UiAutomation connection and blocks any other accessibility consumer (uiautomator dump, Espresso, Appium) until it's manually killed.
This is platform-agnostic — not specific to React Native / Fabric. It surfaced alongside a separate Fabric snapshot-content problem, filed separately (see linked issue).
Environment
Reproduced on two different devices spanning Android 10 → 14 and two OEM skins (LG and Xiaomi):
- agent-device: 0.17.6 (latest 0.17.7)
- OS / Node: Fedora Linux 43, Node v22.22.2
- Android SDK / adb: platform-tools, adb 1.0.41
- Device A: LG V35 (LM-V350N), Android 10 (SDK 29), USB
- Device B: POCO
23049PCD8G (Xiaomi marble), Android 14 (SDK 34), USB
Problem — helper instrumentation is left running and locks out UiAutomation
After agent-device snapshot returns, the helper instrumentation is still alive:
$ ps aux | grep "am instrument"
adb -s … shell am instrument -w -e waitForIdleTimeoutMs 500 -e waitForIdleQuietMs 100 \
-e timeoutMs 5000 -e maxDepth 128 -e maxNodes 5000 -e emitChunks false -e sessionPort 41245 \
com.callstack.agentdevice.snapshothelper/.SnapshotInstrumentation
Because only one UiAutomation connection can exist at a time, plain uiautomator is now blocked (silent failure — no output, no file written):
$ adb shell uiautomator dump /sdcard/x.xml
$ adb shell ls /sdcard/x.xml
… No such file or directory
Killing the helper restores it immediately:
$ adb shell am force-stop com.callstack.agentdevice.snapshothelper
$ adb shell uiautomator dump /sdcard/x.xml
UI hierchary dumped to: /sdcard/x.xml # works again
Minimal reproduction
agent-device snapshot --platform android on any device.
ps aux | grep "am instrument" → helper still running after the command returned.
adb shell uiautomator dump /sdcard/x.xml; adb shell ls /sdcard/x.xml → now fails/empty. (On Android 11+, use /data/local/tmp/x.xml.)
adb shell am force-stop com.callstack.agentdevice.snapshothelper → step 3 works again.
Impact
The leaked instrumentation breaks fallback tooling (uiautomator / Espresso / Appium) in the same session. (Possibly adjacent to #791, which reported a leftover/suspended iOS runner app.)
Summary
After
agent-device snapshotreturns, the Android snapshot-helper instrumentation (am instrument -w … SnapshotInstrumentation) is left running, which holds the single AndroidUiAutomationconnection and blocks any other accessibility consumer (uiautomator dump, Espresso, Appium) until it's manually killed.This is platform-agnostic — not specific to React Native / Fabric. It surfaced alongside a separate Fabric snapshot-content problem, filed separately (see linked issue).
Environment
Reproduced on two different devices spanning Android 10 → 14 and two OEM skins (LG and Xiaomi):
23049PCD8G(Xiaomimarble), Android 14 (SDK 34), USBProblem — helper instrumentation is left running and locks out UiAutomation
After
agent-device snapshotreturns, the helper instrumentation is still alive:Because only one
UiAutomationconnection can exist at a time, plain uiautomator is now blocked (silent failure — no output, no file written):Killing the helper restores it immediately:
Minimal reproduction
agent-device snapshot --platform androidon any device.ps aux | grep "am instrument"→ helper still running after the command returned.adb shell uiautomator dump /sdcard/x.xml; adb shell ls /sdcard/x.xml→ now fails/empty. (On Android 11+, use/data/local/tmp/x.xml.)adb shell am force-stop com.callstack.agentdevice.snapshothelper→ step 3 works again.Impact
The leaked instrumentation breaks fallback tooling (uiautomator / Espresso / Appium) in the same session. (Possibly adjacent to #791, which reported a leftover/suspended iOS runner app.)