KI-Bildschirmverständnis unter Android: UI-Zustand, Screenshot und sichere Aktion

UI-Zustand, Screenshot oder beides wählen

Die kurze Antwort zu KI-Bildschirmverständnis unter Android lautet: Verwenden Sie den semantischen UI-Zustand, wenn die Aufgabe über aktuelle Texte, Beschriftungen, Rollen, Zustände und mögliche Aktionen verständlich ist. Verwenden Sie einen Screenshot, wenn die entscheidende Information visuell ist. Kombinieren Sie beides, wenn der UI-Zustand zwar ein Ziel beschreibt, aber Layout, Bildinhalt oder sichtbare Zuordnung noch offen bleibt.

Ein Android AI Agent sollte also nicht automatisch möglichst viel Bildschirmmaterial sammeln. Für „Tippe auf die sichtbare Schaltfläche Speichern“ sind aktuelle Knoten, Zustand und Aktionsfähigkeit oft wichtiger als ein Bild. Für „Welche Kurve im Diagramm steigt?“ oder „Ist auf dem Foto das richtige Dokument sichtbar?“ reicht der UI-Zustand dagegen nicht aus.

Wir trennen bei FoneClaw Bildschirmbeleg und Android-Aktion bewusst. Sichtbare Bildschirminformationen helfen beim Verstehen. Eine unterstützte Handlung braucht zusätzlich einen erlaubten Ausführungsweg, passende Berechtigungen, eine frische Zustandsprüfung und bei folgenreichen Schritten eine Bestätigung. Die vollständige Schleife von Absicht zu bestätigter Aktion erklärt Android-Handy mit KI-Agent steuern: von Absicht zu bestätigter Aktion.

Frischen UI-Zustand für sichtbare Steuerelemente nutzen

Der semantische UI-Zustand ist die strukturierte Sicht auf eine Android-Oberfläche. Die Android-Dokumentation zu AccessibilityService beschreibt, dass Bedienungshilfen Fensterinhalte empfangen und über unterstützte Schnittstellen handeln können. Für einen Agenten ist das wertvoll, weil Text, Inhaltsbeschreibung, Rolle, Auswahlzustand, Fokus und verfügbare Aktion näher an der Bedeutung eines Steuerelements liegen als reine Pixel.

Diese Daten müssen aber aktuell sein. Eine Liste kann scrollen, ein Dialog kann sich über den Bildschirm legen, eine Schaltfläche kann deaktiviert werden oder eine App kann den Inhalt nachladen. Ein alter UI-Knoten darf nicht als sichere Grundlage für eine spätere Aktion verwendet werden. Vor dem Tippen, Senden, Ändern oder Bestätigen sollte der Agent den aktuellen Zustand erneut lesen.

Ein guter Prüfschritt lautet: Ist das Ziel gerade sichtbar, eindeutig benannt, in der richtigen Hierarchie und mit der passenden Aktion verbunden? Wenn zwei Schaltflächen gleich heißen, eine Beschriftung fehlt oder ein Overlay den Hintergrund verdeckt, reicht der UI-Zustand allein nicht. Dann muss der Agent entweder weitere aktuelle Informationen anfordern, einen Screenshot mit Zustimmung nutzen oder sicher stoppen.

Der UI-Zustand eignet sich besonders für Formulare, Listen, Schaltflächen, Schalter, Textfelder und Dialoge, sofern die App saubere Semantik bereitstellt. Er eignet sich weniger für Fotos, Karten, Diagramme, Canvas-Flächen, Spiele oder stark grafische Oberflächen ohne brauchbare Beschriftung.

Screenshots nur mit Zustimmung für visuelle Fakten verwenden

Ein Screenshot beantwortet eine andere Frage: Was war in diesem Moment sichtbar? Er kann Farben, Layout, Bildinhalt, Diagramme, Karten, überlagerte Dialoge, abgeschnittenen Text und räumliche Beziehungen zeigen. Diese Informationen können entscheidend sein, wenn die App semantisch wenig preisgibt oder wenn das sichtbare Ergebnis selbst beurteilt werden soll.

Ein Screenshot ist zugleich ein sensibler Lesezugriff. Er kann private Nachrichten, Namen, Kontodaten, Fotos, Standort, Gesundheitsinformationen oder andere Inhalte erfassen, die für die Aufgabe gar nicht nötig sind. Deshalb sollte Bildschirmaufnahme nicht als Standardersatz für fehlende Semantik dienen. Sie braucht eine klare Nutzerzustimmung und einen klaren Zweck: Welcher visuelle Fakt soll beantwortet werden?

Beispiele: Bei einer Karte kann ein Screenshot zeigen, welche Route hervorgehoben ist. Bei einem Diagramm kann er zeigen, welche Linie steigt. Bei einer unbeschrifteten Symbolleiste kann er helfen, das sichtbare Icon zu beschreiben. Für eine Aktion bleibt das aber nur Beleg, nicht Berechtigung. Ein Bild sagt nicht sicher, welche App-Aktion erlaubt ist oder ob ein empfindlicher Schritt bestätigt werden darf.

Wenn derselbe Bildbeleg später erneut analysiert werden soll, ist ein stabiler Kontext wichtig. Der Leitfaden Android KI-Bildkontext: Dasselbe Bild zuverlässig erneut analysieren behandelt diesen Fall gezielt, ohne daraus eine allgemeine Automatisierungsfreigabe abzuleiten.

Nur unterstützte Wege ausführen und frisch verifizieren

Verstehen ist nicht Ausführen. FoneClaw ist ein Android-Phone-Agent für unterstützte Aktionen mit geregelten Werkzeugen und sichtbaren Ergebnissen. Wenn eine Aufgabe ausgeführt werden soll, muss der Agent nicht nur wissen, was auf dem Bildschirm steht, sondern auch, ob es einen unterstützten Ausführungsweg gibt.

Der sichere Ablauf ist klein und überprüfbar: aktuellen UI-Zustand lesen, nur bei Bedarf einen genehmigten Screenshot einbeziehen, Ziel und Unsicherheit erklären, passende Berechtigung prüfen, bei sensiblen Schritten Zustimmung einholen, Aktion ausführen und anschließend frischen Zustand lesen. Ein erfolgreicher Tap ist nicht dasselbe wie ein erfolgreich erreichtes Nutzerziel.

Ein Beispiel: Der Nutzer möchte eine Einstellung ändern. Der Agent erkennt den aktuellen Schalter über den UI-Zustand. Vor der Änderung wird geprüft, ob der Schalter noch sichtbar und aktiv ist. Nach der Änderung wird der Zustand erneut gelesen. Wenn die App stattdessen einen Bestätigungsdialog öffnet, darf der Agent nicht anhand des alten Zustands weiterarbeiten, sondern muss den neuen Dialog behandeln.

Für Aufgaben mit aktuellem Bildschirmkontext ist der schwebende Einstieg hilfreich, weil der Nutzer aus der gerade sichtbaren App heraus fragen kann. Wie dieser Kontext sicher genutzt wird, erklärt Schwebender Android KI-Assistent: aktuellen Bildschirm sicher als Kontext nutzen. Die aktuellen unterstützten FoneClaw-Fähigkeiten stehen auf der FoneClaw-Funktionsseite; der Installationsweg steht auf der FoneClaw-Downloadseite.

Sicher stoppen, wenn Beschriftung oder Berechtigung fehlen

Ein sicherer Agent muss wissen, wann er nicht handeln sollte. Drei Fälle sind besonders wichtig: Das Ziel ist nicht eindeutig beschriftet, der Zustand ist nicht frisch genug oder die erforderliche Berechtigung fehlt. In diesen Situationen ist Stoppen besser als Raten.

Ein beobachtbarer Fehler kann so aussehen: Der UI-Zustand enthält zwei gleich benannte Schaltflächen „Weiter“, der Screenshot zeigt zusätzlich einen Dialog, und der Nutzer möchte eine Bestellung abschließen. Der richtige Umgang ist nicht, die visuell wahrscheinlichere Schaltfläche zu drücken. Der Agent sollte erklären, dass Ziel und Wirkung nicht eindeutig sind, den Dialog benennen und den Nutzer um Auswahl oder manuelle Bestätigung bitten.

Auch bei fehlenden Berechtigungen darf kein stiller Erfolg entstehen. Wenn Bildschirmlesen möglich ist, aber die unterstützte Aktion nicht erlaubt ist, muss der Agent das trennen: Er kann den sichtbaren Zustand beschreiben, aber nicht handeln. Wenn eine App keine verwertbare Semantik liefert und ein Screenshot nicht freigegeben ist, bleibt nur die manuelle Übergabe oder eine erneute Prüfung nach Nutzeraktion.

Die Wiederherstellung sollte den letzten sicheren Zustand nutzen. Prüfen Sie, ob bereits etwas geändert, gesendet oder gespeichert wurde. Wiederholen Sie nur den fehlenden Schritt. Wenn ein Ergebnis unklar ist, öffnen Sie die Ziel-App und prüfen Sie den frischen Zustand, bevor Sie dieselbe Aktion erneut ausführen.

Bildverstehen und Android-Aktionsrecht trennen

Neue Modelle zeigen, wie stark Echtzeit- und Bildkontext für Assistenzsysteme werden. Google beschreibt etwa in der Ankündigung zu Gemini Live-Modellen Echtzeitkontext und Tool-Aufrufe als Branchensignal. Das ist relevante Entwicklung, aber keine FoneClaw-Integration und kein Beleg dafür, dass jedes Android-Gerät jede App automatisch steuern kann.

Die Produktgrenze bleibt einfach: Visuelles Verstehen kann helfen, den Bildschirm zu erklären. Android-Aktionsrecht entscheidet, ob eine Handlung unterstützt, erlaubt und bestätigbar ist. Ein Screenshot kann zeigen, dass ein Button sichtbar ist; er gewährt nicht die Berechtigung, ihn zu drücken. Ein UI-Knoten kann eine Aktion anbieten; er garantiert nicht, dass die Aufgabe nach dem Tippen vollständig erledigt ist.

Für Nutzer heißt das: Wählen Sie den kleinsten passenden Beleg, prüfen Sie den aktuellen Zustand vor der Aktion und verlangen Sie bei Folgen eine sichtbare Bestätigung. Wenn Beleg, Zustand oder Berechtigung nicht ausreichen, ist ein sauberer Stopp mit manueller Übergabe die sichere Antwort.