Android Bench 2.0 vergleicht KI Modelle bei komplexen Android Entwicklungsaufgaben

Google verschärft den Praxistest für KI beim Android-Programmieren

Die Leistungsfähigkeit generativer KI wird häufig anhand von Sprach-, Mathematik- oder klassischen Programmierbenchmarks verglichen. Für Unternehmen stellt sich jedoch eine andere Frage: Wie zuverlässig kann ein Modell eine umfangreiche Entwicklungsaufgabe unter realistischen Bedingungen bearbeiten? Genau an diesem Punkt setzt Android Bench 2.0 an.

Google hat die zweite Generation seines Benchmarks für Android-Entwicklung im September 2026 vorgestellt. Die Messumgebung soll nicht nur prüfen, ob ein Modell einzelne Codezeilen oder kleinere Funktionen erzeugen kann. Stattdessen werden Modelle und agentische Systeme mit Aufgaben konfrontiert, die mehrere Arbeitsschritte verbinden und in der Praxis mehrere Tage Entwicklungszeit beanspruchen können.

Zu den beispielhaft genannten Szenarien gehören die Aktualisierung von Abhängigkeiten, die Integration größerer Funktionen, die Bearbeitung bestehender Android-Projekte und die Entwicklung neuer Anwendungen. Damit verschiebt sich der Schwerpunkt von kurzen Codeaufgaben hin zu einer Form der Softwarearbeit, bei der Planung, Implementierung, Fehlersuche, Tests und Nachbesserungen zusammenspielen müssen.

Die bislang veröffentlichten Ergebnisse zeigen dabei ein auffälliges Bild: In der ausgewerteten Vergleichsrunde schneiden Modelle von OpenAI und Anthropic besser ab als Googles eigene Gemini-Modelle. Das Ergebnis ist insbesondere deshalb relevant, weil Google den Benchmark selbst entwickelt und seine Modelle darin antreten lässt.

Was Android Bench 2.0 messen soll

Android Bench wurde nach Angaben von Google ursprünglich entwickelt, um die Eignung großer Sprachmodelle für konkrete Android-Entwicklungsaufgaben zu untersuchen. Die erste Version konzentrierte sich stärker auf begrenzte Änderungen und einzelne Aufgabenpakete. Android Bench 2.0 soll diese Perspektive erweitern und die Bedingungen realer Entwicklungsprojekte besser abbilden.

Vom kurzen Code-Change zur langfristigen Aufgabe

Die zentrale Neuerung sind sogenannte Long-Horizon-Tasks. Damit sind Aufgaben gemeint, die nicht in einem einzelnen Prompt oder mit einer isolierten Codeänderung erledigt werden können. Ein Modell muss über längere Zeit hinweg konsistent arbeiten, den Projektkontext berücksichtigen und auf Zwischenergebnisse reagieren.

Ein Beispiel ist die Modernisierung eines bestehenden Android-Projekts. Dafür kann es notwendig sein, veraltete Bibliotheken zu ersetzen, inkompatible Schnittstellen anzupassen, Build-Probleme zu beheben und anschließend sicherzustellen, dass bestehende Funktionen weiterhin funktionieren. Eine andere Aufgabe könnte darin bestehen, eine neue Funktion über mehrere Schichten einer Anwendung hinweg zu integrieren – von der Benutzeroberfläche über die Geschäftslogik bis zur Datenverarbeitung.

Auch die Entwicklung einer App von Grund auf stellt höhere Anforderungen als die Erzeugung eines einzelnen Codebeispiels. Das System muss Entscheidungen zur Projektstruktur treffen, Abhängigkeiten korrekt konfigurieren, die Benutzeroberfläche umsetzen und die Anwendung in einer ausführbaren Umgebung testen. Hinzu kommen mögliche Fehler, die erst während des Build- oder Testprozesses sichtbar werden.

Modelle und Agenten im gleichen Prüfrahmen

Android Bench 2.0 richtet sich nicht ausschließlich an reine Sprachmodelle. Der Benchmark soll auch agentische Systeme bewerten können. Ein KI-Agent erhält dabei ein Entwicklungsziel und kann – abhängig von der konkreten Testumgebung – verschiedene Werkzeuge nutzen. Dazu können etwa eine Entwicklungsumgebung, ein Terminal, ein Dateisystem oder automatisierte Testmechanismen gehören.

Diese Unterscheidung ist für die Interpretation der Ergebnisse wichtig. Ein Modell, das lediglich Quellcode als Antwort ausgibt, arbeitet unter anderen Bedingungen als ein Agent, der Dateien verändern, Builds ausführen und Testergebnisse auswerten kann. Die praktische Leistungsfähigkeit hängt deshalb nicht allein vom zugrunde liegenden Modell ab, sondern auch von Werkzeugzugriffen, Kontextfenster, Agentenlogik und der Qualität der Rückkopplung.

Die veröffentlichten Ergebnisse im Überblick

In der von mehreren Medien aufgegriffenen Vergleichsrunde wurden elf Modelle betrachtet. An der Spitze lag GPT-6 Astra von OpenAI mit einer Erfolgsquote von 28 Prozent. Claude Fable 5.1 von Anthropic erreichte 22,7 Prozent und belegte damit den zweiten Platz.

Das beste der in dieser Runde getesteten Google-Modelle war Gemini 3.8 Flash. Es kam auf acht Prozent. Damit lag es deutlich hinter den beiden führenden Modellen. Auch weitere Modelle wurden genannt: Qwen 3.8 Max erreichte 14 Prozent, Kimi K3 kam auf zwölf Prozent und lag damit im Mittelfeld.

Die veröffentlichten Werte lassen sich vereinfacht wie folgt einordnen:

• GPT-6 Astra: 28 Prozent
• Claude Fable 5.1: 22,7 Prozent
• Qwen 3.8 Max: 14 Prozent
• Kimi K3: 12 Prozent
• Gemini 3.8 Flash: 8 Prozent

Die Zahlen beschreiben nach den vorliegenden Informationen die Erfolgsquote innerhalb des jeweiligen Testaufbaus. Sie sind daher nicht mit einem allgemeinen „Intelligenzquotienten“ oder einer universellen Qualitätsbewertung gleichzusetzen. Ein Modell kann bei Android-Aufgaben schwächer abschneiden und in anderen Bereichen, etwa bei multimodalen Aufgaben, Recherche oder der Verarbeitung langer Dokumente, andere Ergebnisse erzielen.

Ein deutlicher Abstand bei komplexen Aufgaben

Der Abstand zwischen dem erstplatzierten GPT-6 Astra und Gemini 3.8 Flash beträgt in der veröffentlichten Runde 20 Prozentpunkte. Relativ betrachtet liegt der Wert von Gemini damit deutlich unter dem des Spitzenreiters. Der Vergleich macht sichtbar, dass hohe allgemeine Modellfähigkeiten nicht automatisch zu einer gleichwertigen Leistung in einer spezialisierten Entwicklungsumgebung führen.

Für die Android-Entwicklung spielen plattformspezifische Kenntnisse eine wichtige Rolle. Dazu gehören unter anderem die Struktur moderner Android-Projekte, der Umgang mit Gradle, Jetpack-Bibliotheken, UI-Frameworks wie Jetpack Compose, Lebenszyklen, Berechtigungen, Hintergrundprozesse und die große Vielfalt verfügbarer Geräte. Ein Modell muss nicht nur syntaktisch korrekten Code schreiben, sondern die Wechselwirkungen dieser Komponenten berücksichtigen.

Gerade bei längeren Aufgaben können kleine Fehler erhebliche Folgewirkungen haben. Eine unpassende Abhängigkeit kann den Build-Prozess blockieren. Eine fehlerhafte Zustandsverwaltung kann zu Problemen führen, die erst bei bestimmten Nutzungsszenarien auftreten. Eine Änderung an einer zentralen Schnittstelle kann bestehende Funktionen beeinträchtigen. Solche Fehler werden in einem anspruchsvollen Benchmark stärker sichtbar als bei kurzen, isolierten Programmieraufgaben.

Warum Google die Bewertungsmethode verändert hat

Eine weitere wichtige Änderung betrifft die Auswertung. Frühere Programmierbenchmarks arbeiteten häufig mit einem binären Ergebnis: Eine Aufgabe gilt entweder als vollständig gelöst oder als nicht bestanden. Dieses Verfahren ist leicht verständlich und ermöglicht eine klare Rangliste. Es bildet jedoch nicht immer ab, wie nah ein System an einer funktionierenden Lösung liegt.

Android Bench 2.0 verwendet nach den vorliegenden Angaben eine kontinuierliche Bewertung. Dabei können auch Teilerfolge berücksichtigt werden. Ein Modell, das eine Funktion vollständig implementiert, aber bei einem Randfall scheitert, wird dadurch anders eingeordnet als ein Modell, das bereits an der Projektkonfiguration scheitert.

In die Bewertung können mehrere Qualitätsdimensionen einfließen:

• funktionale Vollständigkeit der Umsetzung
• korrektes Verhalten unter den vorgesehenen Tests
• visuelle und technische Qualität der Anwendung
• Vermeidung von Regressionen in bereits vorhandenen Funktionen
• Stabilität des Projekts über mehrere Bearbeitungsschritte hinweg

Diese differenzierte Auswertung ist für Unternehmen besonders relevant. In realen Entwicklungsprozessen ist eine teilweise brauchbare Lösung häufig wertvoller als ein System, das nur zwischen vollständigem Erfolg und vollständigem Scheitern unterscheidet. Gleichzeitig bleibt entscheidend, ob die Teilleistung zuverlässig reproduzierbar ist und wie viel manuelle Nacharbeit erforderlich ist.

Was die Ergebnisse für Unternehmen bedeuten

Für Unternehmen, die KI in der Softwareentwicklung einsetzen, liefert Android Bench 2.0 vor allem einen Hinweis auf die Bedeutung des Anwendungskontexts. Die Wahl eines Modells sollte nicht ausschließlich auf allgemeinen Ranglisten oder Marketingangaben beruhen. Entscheidend ist, wie gut das Modell mit den Aufgaben, Werkzeugen und Qualitätsanforderungen der eigenen Organisation zurechtkommt.

Benchmarkwerte ersetzen keinen eigenen Praxistest

Ein öffentliches Testergebnis kann eine Vorauswahl erleichtern. Es zeigt, welche Modelle unter einem bestimmten Prüfverfahren gute Ergebnisse erzielen und wo erkennbare Schwächen liegen. Für eine belastbare Beschaffungs- oder Architekturentscheidung reicht es jedoch nicht aus.

Ein Unternehmen sollte zusätzlich eigene Tests mit anonymisierten oder speziell erstellten Aufgaben durchführen. Dabei können unter anderem folgende Fragen untersucht werden:

• Wie gut versteht das Modell die bestehende Codebasis?
• Wie zuverlässig aktualisiert es Abhängigkeiten?
• Wie viele Iterationen sind bis zu einem erfolgreichen Build erforderlich?
• Wie häufig führt eine Änderung zu Regressionen?
• Wie gut dokumentiert das System seine Entscheidungen und Änderungen?
• Wie sicher geht es mit Zugangsdaten, personenbezogenen Daten und proprietärem Quellcode um?
• Wie hoch sind Laufzeit, Tokenverbrauch und Gesamtkosten pro Aufgabe?

Besonders aussagekräftig sind Tests mit realistischen Arbeitsabläufen. Dazu gehören Fehlerbehebung in einem bestehenden Projekt, Anpassungen an eine neue Android-Version, die Umsetzung einer Funktion aus einer unvollständigen Spezifikation und die Pflege von Tests. Der Vergleich sollte nicht nur die Erfolgsquote, sondern auch den Zeitaufwand für menschliche Kontrolle und Korrektur erfassen.

Die Rolle menschlicher Entwickler bleibt zentral

Die Ergebnisse von Android Bench 2.0 zeigen nicht, dass KI-Systeme komplexe Entwicklungsaufgaben generell autonom bewältigen. Selbst das führende Modell löste in der veröffentlichten Vergleichsrunde weniger als ein Drittel der Aufgaben vollständig. Daraus lässt sich vielmehr ableiten, dass anspruchsvolle Softwareentwicklung weiterhin eine Kombination aus Automatisierung, Prüfung und fachlicher Verantwortung erfordert.

KI kann Entwicklerinnen und Entwickler bei der Recherche, der Erstellung von Testfällen, der Analyse von Fehlermeldungen oder der Vorbereitung wiederkehrender Änderungen unterstützen. Die Verantwortung für Architekturentscheidungen, Sicherheitsanforderungen, Datenschutz und die Freigabe produktiver Software bleibt jedoch beim Unternehmen und seinen Fachkräften.

Für B2B-Teams bedeutet dies, dass der wirtschaftliche Nutzen nicht allein durch die Zahl automatisch erzeugter Codezeilen bestimmt wird. Relevant sind vielmehr verkürzte Durchlaufzeiten, weniger manuelle Routinearbeit, eine bessere Dokumentation und eine gleichbleibende Qualität. Wenn ein Agent zwar viel Code produziert, aber regelmäßig schwer erkennbare Fehler einführt, kann der Nettoeffekt negativ ausfallen.

Wie aussagekräftig ist ein Google-eigener Benchmark?

Dass Google seine eigenen Modelle in einem selbst entwickelten Benchmark testet, macht die Ergebnisse zunächst auffällig. Ein Anbieter könnte theoretisch Kriterien wählen, die den eigenen Systemen entgegenkommen. Im Fall von Android Bench 2.0 fällt jedoch auf, dass Gemini in den veröffentlichten Resultaten nicht an der Spitze steht. Das spricht dafür, dass der Test zumindest in dieser Runde nicht ausschließlich auf eine positive Außendarstellung der Google-Modelle ausgerichtet war.

Der Umstand allein reicht allerdings nicht aus, um die wissenschaftliche Aussagekraft des Benchmarks abschließend zu bewerten. Für eine unabhängige Einordnung wären unter anderem detaillierte Informationen zu den Testaufgaben, den verwendeten Versionen, den Agentenkonfigurationen, der Zahl der Durchläufe und den Bewertungskriterien erforderlich.

Auch die Auswahl der Aufgaben kann das Ergebnis beeinflussen. Ein Benchmark, der stark auf Android-spezifische Muster, Google-Bibliotheken oder bestimmte Entwicklungspraktiken ausgerichtet ist, misst vor allem die Eignung für genau diese Umgebung. Das ist für Android-Teams sinnvoll, schränkt aber die Übertragbarkeit auf Webentwicklung, Backend-Systeme, Datenanalyse oder andere Plattformen ein.

Die allgemeine Benchmark-Problematik

Die Aussagekraft von KI-Benchmarks wird seit Jahren kontrovers diskutiert. Eine Untersuchung des Oxford Internet Institute, auf die in der Berichterstattung verwiesen wird, analysierte 445 führende KI-Benchmarks und kam zu dem Ergebnis, dass zahlreiche Verfahren wissenschaftliche Schwächen aufweisen oder die Modellleistung überbewerten können.

Zu den typischen Problemen gehören eine zu geringe Zahl an Testaufgaben, Datenüberschneidungen mit dem Training, fehlende Aktualisierungen, unklare Bewertungsmaßstäbe und eine starke Optimierung der Modelle auf bekannte Tests. Außerdem können einzelne Spitzenwerte den Eindruck erwecken, ein Modell sei allgemein überlegen, obwohl es lediglich in einem begrenzten Aufgabenbereich besonders gut abschneidet.

Android Bench 2.0 versucht, einige dieser Grenzen zu adressieren, indem der Benchmark längere Aufgaben, praktische Projektarbeit und kontinuierliche Bewertungen einbezieht. Ob dies langfristig gelingt, hängt davon ab, wie regelmäßig die Aufgaben erneuert werden und wie transparent die Methodik dokumentiert ist.

Welche Faktoren hinter dem Gemini-Ergebnis stehen könnten

Aus den veröffentlichten Zahlen allein lässt sich nicht ableiten, warum Gemini 3.8 Flash in dieser Testrunde nur acht Prozent erreicht hat. Mehrere Erklärungen sind möglich, ohne dass eine davon durch die vorliegenden Informationen abschließend belegt wäre.

Eine Rolle kann die Modellgröße beziehungsweise die Ausrichtung des jeweiligen Modells spielen. Ein auf niedrige Latenz und hohe Skalierbarkeit optimiertes Flash-Modell verfolgt möglicherweise andere Ziele als ein besonders leistungsorientiertes System. Bei langen Entwicklungsaufgaben können außerdem Kontextverwaltung, Planung über mehrere Schritte und der Umgang mit Werkzeugen stärker ins Gewicht fallen als die Geschwindigkeit einzelner Antworten.

Auch die Agentenumgebung kann einen Unterschied machen. Wenn ein Modell nicht zuverlässig mit Build-Systemen, Testresultaten oder Dateistrukturen interagiert, kann eine grundsätzlich korrekte Codegenerierung in der Praxis trotzdem scheitern. Ebenso können Sicherheitsbeschränkungen oder unterschiedliche Standardeinstellungen den Vergleich beeinflussen.

Schließlich ist zu berücksichtigen, dass die veröffentlichten Ergebnisse eine Momentaufnahme darstellen. KI-Modelle werden häufig aktualisiert, und schon Änderungen an Prompts, Werkzeugen, Laufzeitumgebung oder Testdaten können die Resultate verändern. Ein Benchmark-Ranking sollte daher als zeitgebundene Messung und nicht als dauerhafte Hierarchie verstanden werden.

Einordnung für KI-gestützte Entwicklungsprozesse

Die Entwicklung von Android Bench 2.0 steht für einen grundsätzlichen Wandel bei der Bewertung von KI-Programmierwerkzeugen. Lange Zeit lag der Schwerpunkt auf der Frage, ob ein Modell eine Funktion korrekt vervollständigen oder eine bekannte Programmieraufgabe lösen kann. Für Unternehmen wird jedoch zunehmend wichtiger, ob ein System über längere Zeit zuverlässig an einem Projekt arbeiten kann.

Damit rücken Prozessfragen in den Mittelpunkt. Ein leistungsfähiges System muss Anforderungen interpretieren, Änderungen planen, Zwischenergebnisse prüfen, Fehler erkennen und seine Vorgehensweise anpassen. Es muss außerdem mit vorhandenen Standards und technischen Einschränkungen umgehen können. Diese Fähigkeiten sind näher an einem Entwicklungsprozess als an einer klassischen Frage-Antwort-Situation.

Für den Einsatz in Unternehmen empfiehlt sich deshalb eine gestufte Einführung:

• Zunächst sollten Modelle in abgeschotteten Entwicklungsumgebungen mit nichtkritischen Aufgaben getestet werden.
• Anschließend können klar abgegrenzte Tätigkeiten wie Testgenerierung, Dokumentation oder Codeanalyse folgen.
• Erst nach einer systematischen Qualitäts- und Sicherheitsprüfung sollten agentische Systeme Änderungen an produktionsnahen Projekten durchführen.
• Für jede Stufe sollten Freigaberegeln, Protokollierung und Zuständigkeiten festgelegt werden.

Plattformen wie Mindverse können in diesem Zusammenhang als übergreifende Arbeitsumgebung für KI-gestützte Text-, Recherche- und Content-Prozesse betrachtet werden. Für technische Entwicklungsaufgaben bleibt jedoch eine getrennte Prüfung der jeweiligen Modelle, Schnittstellen und Sicherheitsanforderungen erforderlich. Ein gutes Ergebnis bei Recherche oder Textgenerierung sagt nicht automatisch etwas über die Qualität bei Android-Code aus.

Fazit: Ein anspruchsvollerer Test mit begrenzter Reichweite

Android Bench 2.0 erweitert die Bewertung von KI-Modellen um eine für die Praxis wichtige Dimension: die Bearbeitung längerer und komplexerer Entwicklungsaufgaben. Die veröffentlichten Resultate zeigen einen deutlichen Vorsprung von GPT-6 Astra und Claude Fable 5.1 gegenüber Gemini 3.8 Flash. Für Google ist besonders bemerkenswert, dass die eigenen Modelle im selbst entwickelten Test nicht führend abschneiden.

Die Ergebnisse sollten jedoch weder als endgültiges Urteil über die beteiligten Anbieter noch als allgemeine Rangliste für sämtliche KI-Anwendungen verstanden werden. Gemessen wurde ein spezifischer Ausschnitt der Softwareentwicklung unter einem bestimmten Testaufbau. Aussagekräftig ist der Benchmark vor allem für die Frage, wie Modelle mit anspruchsvollen Android-Aufgaben, langen Bearbeitungsketten und agentischen Werkzeugen umgehen.

Für Unternehmen ergibt sich daraus eine klare Handlungsgrundlage: Modellvergleiche sollten an konkreten Arbeitsabläufen ausgerichtet werden. Neben der Erfolgsquote zählen Sicherheit, Wartbarkeit, Transparenz, Integrationsaufwand, Kosten und der Umfang notwendiger menschlicher Kontrolle. Android Bench 2.0 liefert dafür einen relevanten Referenzpunkt – ersetzt aber nicht die eigene Validierung im jeweiligen Unternehmenskontext.

Bibliografie Google Android Developers Blog: Android Bench 2.0: Pushing the frontier with challenging long-horizon tasks. https://android-developers.googleblog.com/ Android Developers: Android Bench. https://developer.android.com/ Google Android Developers Blog: KI-gestützte Android-Entwicklung verbessern und LLMs mit Android Bench optimieren. https://developer.android.google.cn/blog/posts/elevating-ai-assisted-android-development-and-improving-ll-ms-with-android-bench?hl=de t3n, Noëlle Bölling: Laut Android Bench 2.0 bleibt Gemini hinter der Konkurrenz zurück. https://t3n.de/news/android-bench-2-0-so-schlecht-schlagen-sich-googles-eigene-modelle-im-vergleich-zu-claude-und-gpt-1764023/ Android Central, Sanuj Bhatia: Google just put the latest AI models through a brutal coding test — here's how they did. https://www.androidcentral.com/apps-software/android-os/android-bench-2-0 IT-Boltwise: Android Bench 2.0: KI-Modelle im Langhorizont-Task-Test mit Agenten. https://www.it-boltwise.de/android-bench-2-0-ki-modelle-im-langhorizont-task-test-mit-agenten.html Oxford Internet Institute: Measuring What Matters. https://oxrml.com/measuring-what-matters/ SmartDroid: Bester KI-Coder für Android? Google hat neu gemessen. https://www.smartdroid.de/bester-ki-coder-fuer-android-google-hat-neu-gemessen/