Googles ARTEMIS veröffentlicht Android-Automatisierung als Open Source: Was die 99%-AndroidWorld-Behauptung tatsächlich abdeckt

Der neueste Commit auf google/artemis ist kein Feature. Er ist eine Credit-Zeile – „fix: README und relevante Datei-Header gemäß den Apache-2.0-Anforderungen vervollständigen“, gepusht am 12. September 2026, drei Tage nachdem Minitap einen Beitrag mit dem Titel Ich hatte mehr von Google erwartet. Googles ARTEMIS ist der neu quelloffene Android-Automatisierungsagent des Unternehmens: Er verwandelt eine in einfachem Englisch verfasste Anweisung in echte Taps, Wischgesten, Texteingaben und Verifikation auf einem physischen Android-Gerät oder einem Emulator, zeichnet dabei die Logs und Screenshots auf und meldet eine Aufgabenabschlussrate von über 99 % im AndroidWorld-Benchmark von Google Research. Er wurde diesen August vom Pixel Test Engineering Fusion Team von Google unter Apache 2.0 veröffentlicht und ist es wirklich wert, einen Nachmittag damit zu verbringen. Er ist außerdem seit Mitte September das Zentrum eines Open-Source-Attributionsstreits, der mehr darüber aussagt, wie mobile Agenten gebaut werden, als die Benchmark-Zahl. Beide Geschichten sind wahr. Nur eine von ihnen ist der Grund, warum der letzte Commit des Repositorys eine Lizenzkorrektur war.

Was tatsächlich ausgeliefert wurde

ARTEMIS ist kein Modell und kein Chatbot-Wrapper. Es ist ein Steuerungsharness – ein Python-3.12+-System, das zwischen einem Vision-Language-Modell und einem echten Handset sitzt. Man gibt ihm eine Aufgabe auf Englisch; es beobachtet den Bildschirm, entscheidet über eine Aktion, führt sie über ADB aus, prüft, was passiert ist, und macht weiter. Fünf Dinge waren im Lieferumfang enthalten:

• Eine CLI und ein Python-SDK. code>./start.sh/code> richtet ADB, scrcpy, FFmpeg und die uv-Umgebung ein; code>uv run artemis run "…" --profile flash/code> führt eine Aufgabe headless aus; das code>artemis-client/code>-SDK kapselt denselben Aufruf für pytest und CI und gibt code>succeeded/code>, code>status/code>, code>device_serial/code> und eine code>trace_id/code> zurück, die du später nachverfolgen kannst.

• Eine Web-Konsole. code>uv run artemis ui/code> stellt eine visuelle Testkonsole unter code>localhost:8000/code> bereit, in der du den Ablauf Schritt für Schritt beobachten kannst.

• Ein nativer MCP-Server. Das ist der Teil, der dafür gesorgt hat, dass es sich verbreitet hat. code>uv run artemis mcp --install all/code> stellt code>mobile_run_task/code>, code>mobile_manage_task/code>, code>mobile_get_device_state/code>, code>mobile_inspect_trace/code> und code>mobile_diagnose/code> jedem MCP-fähigen Assistenten zur Verfügung, mit erstklassigen Installationspfaden für Antigravity, Claude Code und Codex sowie Konfigurationsgenerierung für Cursor, Windsurf, VS Code und Cline/Roo. Bei einem Assistenten, der mit dem Server verbunden ist, ist „die APK bauen, sie installieren, Einstellungen öffnen, den Flugmodus umschalten, einen Screenshot vom Ergebnis machen“ kein Skript mehr, sondern ein Satz.

• Ein Helfer für Barrierefreiheit. Die erste Aufgabe installiert den Artemis Accessibility Helper, der das Bildschirmlayout liest, ohne die UiAutomation-Verbindung zu halten – bewusst, damit andere UiAutomator-basierte Tools auf demselben Gerät nicht unterdrückt werden. Er läuft auf dem Telefon und sendet nichts von dort nach außen und greift auf UIAutomator2 zurück, wenn er sich nicht verbinden kann, wobei der Rückgriff in der Aufgaben-Zeitleiste sichtbar gemacht wird.

• Protokoll- und Trace-Erfassung.Crash-Stacks, Keyframe-Screenshots und ein Diagnosebericht werden automatisch erfasst, statt vom Aufrufer nachträglich angeflanscht zu werden – der Grund, warum es als Regressionssuite und nicht nur als Demo nutzbar ist.

Flash und Pro sind zwei verschiedene Produkte, die sich einen Namen teilen.

Das Allerwichtigste, was Sie verstehen müssen, bevor Sie ARTEMIS gegen irgendetwas benchmarken, ist, dass code>--profile flash/code> und code>--profile pro/code> sind keine Geschwindigkeitseinstellung bei einem Agenten. Sie sind zwei Agenten.

• Flash — eine reaktive Schleife aus Beobachten und Handeln mit etwa 3–5 Sekunden pro Schritt, kein Plan, keine Notizen, keine Sicherheitsprüfung vor der Ausführung, keine Checkpoint-Verifizierung, kein Abschlussbericht und keine ADB-Shell. Die Schleife ist standardmäßig unbegrenzt, weil der Verlauf komprimiert statt angesammelt wird.

• Pro – ein Multi-Agenten-Graph mit etwa 15–40 Sekunden pro Schritt, aufgebaut aus einem Planner, der einen lebenden Markdown-Plan mit expliziten code>verify/code>- und code>assert/code>-Elementen pflegt, einem Operator mit dem vollständigen Toolset und einem schreibgeschützten Checker, der Checkpoints validiert und eine Exit-Überprüfung durchführt. code>--verification-level/code> akzeptiert code>off/code>, code>final/code> (Standard), code>checkpoints/code> oder code>strict/code>.

Das ist ein fünf- bis zehnfacher Latenzunterschied bei derselben Aufgabenbeschreibung, und es ist der Unterschied zwischen einem Smoke-Test und einem explorativen Lauf mit 100+ Schritten. Googles eigene Einordnung ist, dass Pro für Arbeit mit langem Zeithorizont und kontinuierliche code>[Loop:continuous]/code> Überwachung gedacht ist; Flash ist für routinehafte, deterministische UI-Aufgaben gedacht. Wenn du eine Rezension liest, die Schrittzeiten zitiert, ohne dir zu sagen, welches Profil sie erzeugt hat, sagt sie dir nichts.

Die Lokalisierungsstrategie ist die eigentliche Ingenieurskunst

Die meisten Mobile-Automation-Frameworks scheitern an Selektoren. ARTEMIS ist nach dem Dynamic-First-Prinzip gebaut: Wenn ein Index für Barrierefreiheitselemente existiert, verwendet es ihn; wenn nicht – ein Canvas, eine Compose-Oberfläche, eine Flutter-Ansicht, ein Spiel – fällt es auf Koordinaten und Vision zurück. Es gibt keine XPath-Schicht zu pflegen und keine ID, die veralten kann, was wichtig ist, weil die Anwendungen, die Sie am meisten testen möchten, genau die sind, die wöchentlich neue Builds ausliefern.

Das Pro-Profil fügt ein Safety Net hinzu: Jede Aktion durchläuft eine Prüfung vor der Ausführung – XML zuerst, mit einem Pixel-Fallback –, die das System-Popup abfängt, das gerade deinen Tap verschlingen will. Fehlschläge eröffnen einen „Execution Incident“, der im Kontext bleibt, bis ihn ein späterer Erfolg auflöst, statt einen separaten Repair-Agenten zu erzeugen. Lange Sitzungen werden komprimiert – alte Screenshots werden zu visuellen Zusammenfassungen, abgeschlossene Schritte werden zu abrufbaren Epochen gebündelt, die code>search_history/code> und code>replay_steps/code> zurückholen können –, und genau das verhindert, dass ein Kontext mit 100 Schritten unbezahlbar wird.

99,1 % auf der Bestenliste, und der Vorbehalt, den die Launch-Posts auslassen

ARTEMIS' zentrale Behauptung ist eine Abschlussrate von über 99 % auf AndroidWorld, dem Benchmark von Google Research mit 116 realistischen Aufgaben über rund 20 Apps hinweg, bewertet mit Pass@1. Mit Stand vom 11. September 2026 listete das AndroidWorld-Leaderboard ARTEMIS mit 99,1 % gegenüber Minitaps mobile-use mit 91,4 %, bei einer menschlichen Leistung von 80 %. In der Tabelle ist das der Stand der Technik unter den öffentlich berichteten Ergebnissen.

Zwei Dinge gehören neben diese Zahl. Erstens: Die AndroidWorld-Rangliste überprüft eingereichte Ergebnisse ausdrücklich nicht unabhängig – jede Zahl darauf, auch die von ARTEMIS, wird von dem Team, das sie erzeugt hat, selbst gemeldet, und eine Robustheitsanalyse hat gezeigt, dass allein Aufgabenvariationen die Punktzahl eines Agenten erheblich verschieben können. Behandle die 99,1 % als starke Herstellerangabe zu einem öffentlichen, überprüfbaren Benchmark – was eine reale und nützliche Sache ist – und nicht als geprüfte Messung, die es nicht ist. Zweitens kommt es auf die Form des Vergleichs an: Der Benchmark ist eine feste Aufgabenmenge, und das veröffentlichte Vergleichsdiagramm von ARTEMIS soll mobile-use ausgelassen haben, während andere Einträge enthalten waren. Ein Benchmark, bei dem das stärkste frühere Ergebnis im Diagramm fehlt, ist eine schwächere Aussage, als der reine Prozentsatz nahelegt.

Der Streit, der die eigentliche Nachricht dieses Monats ist

In seinem Blog und in einem öffentlichen Issue im Repository behauptete Minitap – ein Mobile-Testing-Startup, dessen Open-Source-mobile-useProjekt dieselbe Aufgabe für Android und iOS erledigt –, dass 228 von ARTEMIS' 229 Dateien mit seinen eigenen identisch seien. Die veröffentlichten Details sind ungewöhnlich konkret: Android-Geräteverbindungscode, der mit seiner Implementierung übereinstimmt, die wortwörtliche Wiederverwendung von Anweisungen, die zu einem Agenten namens „Hopper" gehören, und ein WhatsApp-Beispiel, das Neujahrsnachrichten an Alice, Bob und Charlie sendet, reproduziert mit denselben Kommentaren, denselben Aufräumschritten und demselben Bug. Darüber hinaus wird behauptet, eine Datei mit den Namen dreier Minitap-Autoren – Pierre-Louis Favreau, Jean-Pierre Lo und Nicolas Dehandschoewercker – sei im August per Force-Push ersetzt worden, wobei die Namen entfernt und ein anderer Autor eingesetzt wurde.

Die Lizenzfrage ist nicht undurchsichtig. mobile-use steht unter Apache 2.0, und Apache 2.0 erlaubt genau diese Art der Weiterverwendung – kommerziell, abgeleitet, geschlossen – sofern man die Urheberrechtshinweise beibehält und angibt, was man geändert hat. Was sie nicht erlaubt, ist, den Code mit entfernten Hinweisen auszuliefern. Seit die Vorwürfe aufkamen, trägt das Repository die Zeile „This project includes source code developed by Minitap, Inc.“ und verlinkt auf minitap-ai/mobile-use, und der Commit vom 12. September, der diese Namensnennung vervollständigt, ist zum Zeitpunkt des Schreibens die jüngste Änderung auf code>main/code>. Minitap hat keine Belege veröffentlicht, die die Entfernung der Namensnennung mit seinen eigenen unbeantworteten Leaderboard-Einreichungen in Verbindung bringen, und Google hat keine ausführliche öffentliche Stellungnahme abgegeben. Die ehrliche Lesart: Der weitergegebene Code ist legitim und war stets erlaubt; die Formalitäten waren es eine Zeit lang nicht, und das ist nun korrigiert.

Der Teil, den niemand einkalkuliert: die Modellrechnung

ARTEMIS wird mit einem Badge ausgeliefert, auf dem „Multi-Model — Gemini | Claude | GPT-4o | Qwen-VL“ steht, und die Konfigurationsdatei unter code>config/artemis.jsonc/code> ist die Stelle, an der du es auf das Vision-Modell ausrichtest, für das du Zugangsdaten besitzt. Nichts in dieser Datei ist für Nutzer sichtbar, bis du Pro in einem echten Workflow ausführst und beobachtest, was ein langer Agent tatsächlich kostet.

Rechnen Sie die Profile durch. Ein Pro-Lauf mit 100 Schritten bei 15–40 Sekunden pro Schritt dauert irgendwo zwischen 25 Minuten und etwas mehr als einer Stunde Wanduhrzeit, und jeder einzelne dieser Schritte ist mindestens ein Aufruf eines Vision-Modells, der einen Screenshot mitführt. Flash ist pro Schritt günstiger, neigt aber stärker zum Loopen, und weil sein Kontext komprimiert statt abgeschnitten wird, läuft es munter über das Turn-Limit hinaus, das Sie als Obergrenze angenommen haben. Ganz gleich, welches Profil Sie wählen: Das Modell ist der Einzelposten, der mit Ihrer Testsuite skaliert, nicht die Lizenz oder die Hardware.

Hier hört eine Routing-Schicht auf, eine Abstraktion zu sein. Ein Vision-Modell, das eine lange Android-Sitzung steuert, ist eine Arbeitslast mit zwei unangenehmen Eigenschaften: Sie ist langlebig, und sie toleriert keinen Aussetzer eines Anbieters mitten in Schritt 74, denn der Kontext des Laufs liegt am Endpunkt dieses Anbieters. ARTEMIS auf eine einzelne OpenAI-kompatible Basis-URL zu richten und unser Failover den Lauf zu einem anderen Anbieter desselben Modells verschieben zu lassen, ist der Unterschied zwischen einem unzuverlässigen Test und einem verlorenen Nachmittag. Qwen3.8-Flash ist der interessante Kandidat, den man zuerst ausprobieren sollte — ein multimodales MoE mit 6B aktiven Parametern und einem Kontext von 1 Mio. Tokens, in unserem Katalog gelistet mit 0,15 $ pro Million Eingabe-Tokens und 0,47 $ pro Million Ausgabe-Tokens, bei Cache-Lesevorgängen 0,018 $ und Cache-Schreibvorgängen 0,230 $. Dieser Cache-Lesepreis ist hier der relevante, denn ein Pro-Lauf liest bei jedem Schritt einen wachsenden Kontext erneut.

Sei aber präzise, was das bedeutet: Qwen3.8-Flash steht nicht auf ARTEMIS' Liste getesteter Backends, die Gemini, Claude, GPT-4o und Qwen-VL aufführt. Es ist ein Modell, das plausibel in das Harness passt, und das Harness ist ausdrücklich dafür gebaut, eines aufzunehmen. Niemand hat einen Benchmark für diese Kombination veröffentlicht, und jeden, der behauptet, einen zu haben, solltest du so behandeln, als hätte er ihn erfunden.

Die Roadmap – und wie viel davon tragend ist

Vier Punkte stehen auf der veröffentlichten Roadmap: eine Android-Studio-Integration mit Debugging im Editor, Testaufzeichnung und Gerätesteuerung; iOS-Unterstützung; leichtgewichtige Vision-Language-Modelle auf dem Gerät für latenzarme Arbeit mit Datenschutz an erster Stelle; und Echtzeit-Duplex-Sprachinteraktion.

Der erste ist derjenige, an den man glauben sollte, denn er ist das natürliche nächste Artefakt eines Pixel-Test-Engineering-Teams und birgt kein Forschungsrisiko – der Agent steuert bereits ein Gerät, er braucht nur ein Panel in der IDE. iOS ist eine viel größere Behauptung, als es von außen aussieht: Die gesamte Lokalisierungsstrategie stützt sich auf den Bedienungshilfen-Dienst von Android, und iOS bietet keine äquivalente Schnittstelle mit demselben Berechtigungsmodell, also rechnen Sie eher mit einer Neuschreibung der Wahrnehmungsschicht als mit einem Port. Der On-Device-VLM-Punkt ist derjenige, den man genau im Auge behalten sollte, denn er ist der einzige Punkt auf der Liste, der die API-Kosten pro Schritt beseitigen würde, die derzeit eine große Testsuite dominieren – und er impliziert ein kleines, schnelles, visionsfähiges Modell, das eine UI-Aufgabe zusammenhalten kann, was ein viel engeres Ziel ist als „ein kleines Modell, das gut bei der Tool-Nutzung ist“.

Was diese Woche damit tun

Klonen Sie es, führen Sie code>./start.sh/code> gegen einen Emulator aus, und geben Sie Flash eine Aufgabe, die Ihre bestehende Espresso-Suite abdeckt. Das sagt Ihnen innerhalb einer Stunde, ob der Dynamic-First-Locator die Compose-Oberflächen Ihrer App übersteht, und das ist die Frage, die entscheidet, ob der ganze Rest überhaupt eine Rolle spielt. Führen Sie dann dieselbe Aufgabe auf Pro aus und vergleichen Sie die beiden Traces — die Lücke zwischen 3–5 und 15–40 Sekunden pro Schritt ist der Punkt, an dem Ihr Budget liegt, und ohne sie lässt sich der Aufwand für ARTEMIS nicht beurteilen.

Während du den Code liest, lies die Header. Der Commit vom 12. September, der die Minitap-Attribution hinzugefügt hat, ist der neueste im Repository, was bedeutet, dass die Datei-Header, die du liest, vier Tage alt sind und das Projekt öffentlich aktiv repariert wird. Das ist kein Grund, es zu vermeiden. Es ist ein Grund zu prüfen, welche Version der Geschichte du in der Hand hältst, bevor du eine Erfolgsquote in einer Folie nennst.

ARTEMIS auf eine einzige OpenAI-kompatible Basis-URL auszurichten und unser Failover den Lauf zu einem anderen Anbieter desselben Modells verschieben zu lassen, ist der Unterschied zwischen einem instabilen Test und einem verlorenen Nachmittag.