Android snapshot helper suppresses TalkBack; no verified reader-compatible input path

Ouverte
#4,179 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
18/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
android, java

Piste de recherche

Start with the helper connection in android/snapshot-helper/src/main/java/com/callstack/agentdevice/snapshothelper/SnapshotInstrumentation.java, where getUiAutomation() is called without flags, and compare it with the Android UiAutomation flag the report cites. Reproducing needs an Android 16 emulator with TalkBack enabled, so check the report's dumpsys accessibility steps first. Done means TalkBack stays bound across a snapshot and an input, and a reader focus gesture produces the expected focus and speech events.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug ready-for-agent

Android snapshot helper suppresses TalkBack; no verified reader-compatible input path

On Android 16, the T3-managed agent-device 0.21.31 snapshot helper leaves
TalkBack enabled in secure settings but unbound. Closing my own agent-device
session releases UiAutomation and TalkBack binds again. A subsequent long press
leaves it rebinding. This blocks actual TalkBack focus and speech validation.

Environment

  • agent-device 0.21.31 through T3's device-bound command and managed daemon.
  • Linux host, Android 16 emulator, API 36, 1080 by 2400 display.
  • Android Accessibility Suite 16.0.0.738667889, version code 60149353.
  • App under test: RenovioMobile debug build, package io.renovio.mobile.
  • Observed on 2026-11-02 UTC. No installed helper patches or daemon configuration changes.

Reproduction

DEVICE below denotes the exact device-bound command returned by T3. Commands
must use the same owned session. These are the significant steps extracted from
the retained probes, not a separately executed standalone-daemon reproduction.

  1. Open the app and capture a snapshot with TalkBack off:

    "$DEVICE" open io.renovio.mobile --no-test-ime
    "$DEVICE" snapshot -i
    
  2. Enable the installed TalkBack service. The observed fixture saved the original
    accessibility settings first and enabled TalkBack and touch exploration through
    Android secure settings. Inspect the service state without another UI tool:

    adb -s emulator-5554 shell settings get secure enabled_accessibility_services
    adb -s emulator-5554 shell dumpsys accessibility
    
  3. Observe TalkBack in Enabled services, empty Bound services and an active
    Ui Automation[...] entry. Close only this owned session:

    "$DEVICE" close
    

    TalkBack then appears in Bound services and connects to TTS.

  4. In a separate probe, closing the named TalkBack package through the same
    session preserved the exact app PID. Reopening the app and enabling TalkBack
    permitted binding. The next long press left TalkBack in Binding services:

    "$DEVICE" close com.google.android.marvin.talkback
    "$DEVICE" open io.renovio.mobile --no-test-ime
    # Ensure TalkBack is enabled and bound before this input.
    "$DEVICE" press 300 350 --hold-ms 800
    

The point in step 4 is the observed probe coordinate. It demonstrates service
interruption, not a successful target-focus test.

Plain-tap countercheck

With no helper active, TalkBack stayed bound across a plain coordinate press.
The visible button had two matching bounds observations, [87,1557][993,1704],
wholly inside the display. Pressing its center, 540 1630, activated Login
instead of producing the button's TalkBack focus and completed speech.

The PID-filtered log contained completed startup utterances, but no accepted and
completed target-focus utterance for Continue as Project Owner. Normal press
may intentionally activate a control; I am not claiming it promises touch
exploration. This countercheck shows that closing the helper and using plain
press did not provide a working reader-testing alternative.

Suspected cause and requested support

Android documents that UiAutomation suppresses accessibility services unless
the caller requests
FLAG_DONT_SUPPRESS_ACCESSIBILITY_SERVICES.
The v0.21.36 helper connection
still calls getUiAutomation() without flags. This supports the suppression
explanation; v0.21.36 was inspected, not executed. The public helper-session
setting controls persistence and does not request non-suppression.

Please provide or document a supported mode that preserves TalkBack and permits
reader exploration and activation. The Android flag is a candidate repair for
service suppression, not a demonstrated fix for the input behavior.

Acceptance check

  • TalkBack stays bound with touch exploration enabled across snapshots and input.
  • A reader exploration gesture focuses a labelled button without activating it.
  • For that gesture, the same TalkBack PID emits TYPE_VIEW_ACCESSIBILITY_FOCUSED
    with the expected label, accepts the TTS request and completes the utterance
    within the action's observation window. Startup speech or snapshot labels do
    not count.
  • A deliberate reader double tap activates the focused button once.
  • Closing the owned session leaves the reader usable, and the test restores its
    original accessibility and developer preferences.

Limits and related work

I have not tested a physical device, a standalone daemon, or v0.21.36 at runtime.
A public minimal APK or upstream test-app reproduction is not attached. The
retained app probes restored all four original accessibility secure keys and
TalkBack developer preferences. No full device logs containing app data are
included here.

Issue #851 concerns helper
ownership of UiAutomation. This report concerns coexistence with the actual
TalkBack service. Searches of issues and pull requests for TalkBack and
DONT_SUPPRESS_ACCESSIBILITY_SERVICES found no matching report on 2026-11-02 UTC.

Langage dominant
TypeScript
Étoiles
5.3k
Forks
377
Merge moyen
13 h 18 min
PR mergées (30 j)
653

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de callstack/agent-device

Toutes les issues de callstack/agent-device

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.