Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Android: snapshot helper exits without parseable output after a screen transition (still on 0.21.33)

Offen
  • Stimmt etwas nicht?
#4,005 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
android, react-native, typescript
Bereich
mobile, testing

Rechercherichtung

Start by tracing the Android snapshot helper’s persistent session and one-shot am instrument fallback, then inspect how instrumentation output and failures become COMMAND_FAILED. Reproduce snapshots immediately after a screen transition on the Android 36 Google ATD emulator and capture the instrumentation exit status and result bundle. Done means the intermittent failure is understood and addressed, with a regression check for the transition case.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug in-progress ready-for-agent

Summary

On an Android emulator in CI, snapshot intermittently fails because the snapshot helper exits without returning parseable output. The client gets COMMAND_FAILED with details.androidSnapshotHelperFailureReason: "Android snapshot helper failed before returning parseable output". It reproduces on 0.21.28 and 0.21.33, so the vanished-child fix in #3901 (0.21.31) did not remove it for us.

Environment

  • Emulator: system-images;android-36;google_atd;x86_64 (API 36, Google ATD), in CI
  • Driven through @e2e-dev/mobile 0.12.4 (persistent snapshot-helper session, then the one-shot am instrument fallback)
  • App: React Native (Expo)
Run agent-device Helper versionCode Result
A 0.21.28 21028 helper exit after 629 ms
B 0.21.28 21028 session returned truncated XML → force-kill → one-shot fallback exits after 947 ms
C 0.21.33 21033 persistent session didn't answer → instrumentation fallback failed (1022 ms, then 602 ms)

Frequency: an A/B over the same suite gave 1 failing run of 5 on 0.21.33 and 1 of 3 on 0.21.28.

Repro shape

In the 0.21.33 failure, the step was an assertion polling snapshots right after a screen transition (a peer mention opened from the notifications list). Failure is intermittent, and the request logs also show it on repeated snapshots.

Evidence excerpts

Run A, 0.21.28:

command=snapshot; helper version=0.21.28; versionCode=21028
android_snapshot_helper_capture durationMs=629: failed before returning parseable output
request_failed code=COMMAND_FAILED: Android snapshot helper failed: ...

Run B, 0.21.28:

android_snapshot_helper_session_stop: forceKilled=true
android_snapshot_helper_session_fallback: "Android snapshot helper session returned truncated XML"
android_snapshot_helper_capture durationMs=947: failed before returning parseable output
request_failed code=COMMAND_FAILED

Run C, 0.21.33 (two requests):

helper version=0.21.33; versionCode=21033
persistent-session answered=false; instrumentation fallback failed
capture durations: 1022 ms and 602 ms
reason: Android snapshot helper failed before returning parseable output
request_failed code=COMMAND_FAILED

Logcat:

  • In run C, the Android automation logcat shows Force stopping com.callstack.agentdevice.snapshothelper ...: start instr, then the process start and UiAutomation: Initialized. No FATAL EXCEPTION, AndroidRuntime or NullPointerException line follows.
  • The adb logcat -d -b crash dump taken after the suite is empty (run C; runs A/B predate that dump).
  • So the artifacts show the helper exiting, but not an in-process exception.

Asks

  1. Is there a helper-side log, or a flag such as --debug, that would record why the instrumentation exited (exit code, instrumentation result bundle, a INSTRUMENTATION_ABORTED / shortMsg)? Our host only records "failed before returning parseable output".
  2. Could the one-shot fallback be retried once by agent-device itself when the persistent session has just been force-killed? In our logs, both paths fail inside the same ~1 s window right after a transition.

Related: #3901 (vanished-child NPE, 0.21.31), #3929 (persistent helper frozen on ColorOS; a different symptom).

Vorherrschende Sprache
TypeScript
Sterne
5.2k
Forks
359
Ø Merge
12 Std. 43 Min.
Gemergte PRs (30 T.)
666

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus callstack/agent-device

Alle Issues in callstack/agent-device

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.