Philipp Schmid zeigt in einem Referenzprojekt, wie Gemini 3.5 Flash einen Android-Emulator über Screenshots und strukturierte Aktionen steuert. Das Python-Skript nimmt ein Bildschirmbild auf, sendet es mit einem Ziel an das Modell und erhält beispielsweise einen Funktionsaufruf wie click(y=300, x=500). Die Aktion führt nicht Gemini selbst aus: Eine ADB-Brücke im lokalen Code rechnet die normierten Koordinaten in Pixel um, tippt auf den virtuellen Bildschirm und liefert anschließend einen neuen Screenshot zurück. So entsteht ein Agenten-Loop aus Wahrnehmen, Entscheiden und Ausführen.
Was Computer Use in Gemini macht
Computer Use ist kein externes Plugin, sondern ein Werkzeug in Gemini 3.5 Flash. Man übergibt dem Modell zwei Dinge: einen Screenshot und ein Ziel in natürlicher Sprache, etwa „öffne die Einstellungen und schalte den Dark Mode ein“. Das Modell antwortet nicht mit einer Beschreibung des Bildschirms, sondern mit Aktionen: Tipp, Texteingabe, Wisch oder App-Start.
Das Muster ähnelt klassischem Function Calling, nur mit einem Bild als Eingabe und einem Gerät als Ausgabe. Das Modell schlägt vor, der eigene Code führt aus, das Ergebnis geht als neuer Screenshot zurück. So bleibt das Modell im Kreislauf und kann korrigieren, wenn ein Tipp danebenging. Es sieht die Welt ausschließlich durch diese Bilder – kein Dateisystem, keine Interna des Betriebssystems, keine versteckten Kanäle.
Man kann sich das wie einen Kontrollraum vorstellen, in dem jemand vor einem Monitor sitzt und nur über eine schmale Kamera auf einen Raum blickt. Diese Person darf Knöpfe drücken, sieht aber erst beim nächsten Kamerabild, ob es der richtige war. Der Unterschied zu einem Skript mit festen Koordinaten: Jede Runde beginnt mit einer neuen Lage.
Drei Umgebungen: Browser, Desktop und Mobile
Gemini kennt drei Computer-Use-Umgebungen. browser deckt Web-Automatisierung auf dem Desktop ab, desktop die Steuerung auf Betriebssystem-Ebene, und mobile ist für Smartphones und Emulatoren gedacht. Das Beispielprojekt von Google, das unter github.com/google-gemini/gemini-android-computer-use-quickstart liegt, nutzt mobile und führt damit durch den gesamten Aufbau.
Die mobile Umgebung arbeitet plattformunabhängig. Das Modell gibt Koordinaten auf einem normierten Raster von 0 bis 999 aus: (0, 0) oben links, (999, 999) unten rechts. Erst die Brücke im eigenen Code rechnet diese Werte in echte Pixel um, abhängig von der Auflösung des Geräts. Dadurch ist das Modell nicht an eine Bildschirmgröße oder an Android gebunden.
Die Intelligenz liegt in der Beschreibung der Aktion; die Ausführung bleibt Aufgabe des eigenen Codes. Dieselbe Trennung lässt sich später auf andere Plattformen übertragen, ohne das Modell neu zu trainieren.
Die zehn Aktionen, die das Modell anfordern kann
Im mobile-Modus gibt es einen festen Satz an Aktionen; der eigene Code muss jede davon abfangen können. open_app startet eine App über ihren Namen, optional mit einem Intent. click setzt einen Tipp auf eine Koordinate, long_press hält eine Stelle für eine bestimmte Zahl von Sekunden gedrückt. type schreibt Text und kann auf Wunsch die Eingabetaste anschlagen.
Dazu kommen drag_and_drop für Bewegungen zwischen zwei Punkten, press_key für Tasten wie Home, Zurück oder Enter und go_back als eigener Schritt. wait pausiert die Ausführung, was bei trägen Oberflächen häufig nötig ist. list_apps liefert die installierten Anwendungen, take_screenshot fordert ein neues Bild an.
In der Umsetzung werden daraus kleine Übersetzungen: Ein Klick auf dem Raster wird zu einem adb shell input tap, ein Text wird zu einer Eingabe mit Escaping, ein Wisch zu einer Bewegungssequenz. Ist diese Übersetzung sauber gebaut, bleibt nur Schleifenlogik.
Einrichtung: Emulator und Python-SDK ohne Android Studio
Für den Einstieg braucht es keine grafische Entwicklungsumgebung. Das mitgelieferte Setup-Skript richtet auf einem Mac mit Homebrew die Android-Kommandozeilenwerkzeuge, den Emulator und das virtuelle Gerät AI_Agent_Phone ein. Für Linux oder eine CI-Umgebung müsste dieser Installationsschritt angepasst werden; das veröffentlichte Skript ist ausdrücklich auf macOS ausgelegt.
Danach genügt pip install google-genai, um das Python SDK zu installieren. Das Agent-Skript agent.py kümmert sich selbst um die Umgebungsvariablen mit den SDK-Pfaden und startet den Emulator im Hintergrund, falls er nicht schon läuft. Es wartet auf den Bootvorgang und geht dann in den Computer-Use-Loop. Manuelles Exportieren von Pfaden oder händisches Hochfahren des Emulators entfällt.
Wer diesem Weg folgt, sollte das Skript Zeile für Zeile lesen. Dort steht, welche Daten an das Modell gehen und wie die Antwort zurück auf das Gerät kommt. Wer die Schnittstelle versteht, kann Konfigurationen gezielter ändern.
Der Agent-Loop: Screenshot, Entscheidung, ADB-Befehl
Der Agent-Loop hat vier Schritte: Bild aufnehmen, Bild zusammen mit dem Ziel ans Modell schicken, die zurückgegebene Aktion über ADB ausführen, kurz warten und von vorn. Der Loop endet, wenn das Modell keine Aktion mehr vorschlägt oder das Ziel als erreicht meldet. In der Demo-Version ist dieser Ablauf bewusst synchron gehalten, damit man ihn beim Lesen nachvollziehen kann.
Die ADB-Brücke ist unauffällig, aber entscheidend. Sie muss Koordinaten umrechnen, Text sicher übergeben, auf abgeschlossene Befehle warten und Fehler melden. Davon hängt ab, ob die Automatisierung stabil läuft oder immer wieder hängt.
Das Modell ist fertig; die Arbeit liegt in der Brücke dazwischen. Ein Screenshot muss zuverlässig ankommen, der Emulator schnell genug reagieren, und das Skript muss merken, wenn eine App nicht antwortet. Das ist normale Ingenieursarbeit.
Echte Geräte, drahtloses ADB und Grenzen im Produktivbetrieb
Der Emulator reicht für den Einstieg. Auf einem physischen Smartphone aktiviert man die Entwickleroptionen und schaltet USB- oder WLAN-Debugging ein. Anschließend verbindet man sich per adb connect <geräte-ip>:5555 über TCP/IP und übergibt die Geräte-ID als device_id an den Agent-Loop. Damit lässt sich ein echtes Gerät genauso ansprechen wie ein virtueller Bildschirm, sofern es im selben Netz erreichbar ist.
Auch ein Wechsel der Plattform ist möglich. Die mobile Umgebung liefert dieselben normierten Aktionen, egal ob dahinter Android oder iOS steckt. Für ein iPhone oder den iOS-Simulator tauscht man lediglich die ADB-Brücke gegen ein passendes Werkzeug – etwa Apples simctl, Appium oder go-ios für echte Geräte. Der Rest des Loops bleibt gleich.
Für den Produktivbetrieb reicht der Demo-Code nicht. Nötig sind Wiederholungsversuche bei Netzwerkabbrüchen, ein sauberer Umgang mit getrennten ADB-Verbindungen und asynchrone Ausführung, damit das Skript nicht blockiert. Wichtig ist außerdem, die zurückgegebenen Argumente auf Sicherheitsflags zu prüfen: Bei Aktionen, die Zustand verändern oder Zahlungen auslösen, kann das Modell eine Bestätigung verlangen. Diese Entscheidung gehört vor der Ausführung an den Menschen.
Computer Use für Android ist damit kein fertiges Produkt, sondern ein Baustein. Das Modell übernimmt Sehen und Entscheiden; die Zuverlässigkeit bleibt Aufgabe des Codes. Ein Emulator, ein klar umrissenes Ziel und ein protokollierter Loop sind ein guter Anfang. Die Grenzen zeigen sich im Betrieb.
Quellen: Philipp Schmids Anleitung · Google Gemini API: Computer Use
