Android Studio BYOA: Claude Agent, Codex & Antigravity – drei Agenten, drei Fail-Modi

Der Emulator hängt. Nicht abgestürzt, nicht tot – hängend. Irgendwo zwischen «App installiert» und «Warte auf Debugger», und die UI zeigt eine Login-Maske, die Sie so nie gebaut haben. Drei Agent-Tabs blinken. Claude Agent will noch «kurz den State resetten». Codex hat bereits adb shell am force-stop in der Pipeline. Antigravity wartet auf Permission für Emulator-Control. Und Sie sitzen da und fragen sich, wer eigentlich den Emulator steuert – und was «Agent wechseln» bedeutet, wenn der State schon kaputt ist. Spoiler: Undo ist das nicht.

Willkommen bei Bring Your Own Agent in Android Studio. Google nennt das Flexibilität. Wir bei digital-magazin.de nennen das erstmal ein Incident-Setup mit Marketing-Lack. Am 24.9. hat Matthew Warner, Product Manager Android Developer Experience, den Move im Android Developers Blog vorgestellt: Anthropic Claude Agent, OpenAI Codex und Googles Antigravity laufen über das Agent Client Protocol (ACP) in Studio. Mehr Agents kommen über eine Registry. Klingt nach Auswahl. Fühlt sich an wie drei Remote-Controls für denselben Fernseher – und keiner sagt, wer gerade die Taste drückt.

Die kurze Version: Letztes Jahr hat Studio beliebige AI-Modelle zugelassen. Jetzt kommt BYOA für Coding-Agents. Preview ab Canary Android Studio Rabbit 2. Native Tools inklusive Diagnostics, Compose Preview, SDK und Emulator-Control. Project Graph und Build-Kontext fließen über ACP rein – Vendor-Claim: weniger Tokens, niedrigere Latenz, schärfere Antworten. Ob das bei drei parallelen Plänen und Permission-Prompts so glatt bleibt, ist die eigentliche Geschichte. Die schreiben wir hier.

Was Google unter BYOA versteht – und was das für Ihren Alltag heißt

BYOA heißt: Sie bringen Ihren Agenten mit, Studio liefert die Android-Infrastruktur drumherum. Laut Blog sind Claude Agent, Codex und Antigravity die Featured-Optionen. Jeder ACP-konforme Agent darf rein. Die Registry sitzt unter Settings > Tools & AI & Agents – dort finden sich weitere Agents, sobald sie gelistet sind. Sign-in läuft über Ihren jeweiligen Plan oder einen API-Key. Enterprise und Consumer sind laut Google abgedeckt, «subject to the agent provider». Das heißt auf Deutsch: Google öffnet die Tür, der Anbieter entscheidet, ob Ihr Abo dort auch zählt.

Wir bei digital-magazin.de haben uns den Pitch genau angeschaut. Der Clou ist nicht «drei Chatfenster nebeneinander». Der Clou ist die Behauptung, dass Studio dem Agenten den vollen Project Graph, Build-Setup und Plattform-Details über ACP injiziert. Der Agent soll dann filtern – nur relevante Dateien, nur nötiger Kontext – und dadurch Tokens sparen. Weniger Roundtrips. Weniger Halluzinationen über Gradle-Varianten, die es in diesem Modul gar nicht gibt. Das ist der Vendor-Claim. Ob Ihr Claude-Plan denselben Graph so effizient nutzt wie Antigravity mit Flash 3.8, steht auf einem anderen Blatt.

Nerd-Alarm: ACP ist kein Studio-internes Plugin-Hack. Es ist ein Client-Protokoll, über das IDE und Agent strukturiert reden. Studio steckt den Android-Kontext rein; der Agent antwortet mit Aktionen – Dateien lesen/schreiben, Shell, Tests, Websuche, Subagents. Die IDE bleibt Host. Der Agent bleibt Gast mit Permissions. Klingt einfach, ist es aber nicht – weil «Gast mit Permissions» in einer Umgebung mit Emulator und SDK schnell «Gast mit Root-Feeling» wird, sobald Sie zu großzügig freigeben.

Im Ernst: Wer schon mit agentischen Code-Editoren gearbeitet hat, kennt das Muster. Ein Agent, der Dateien editiert und Tests startet, ist nützlich. Drei Agents, die dasselbe dürfen und sich den Emulator teilen, sind ein Orchestrierungsproblem. Google wirbt mit Agent-Flexibilität: Quota leer oder Performance schlecht? Anderer Agent übernimmt. Das ist der Marketing-Satz. Die Praxisfrage lautet: Was passiert mit dem Emulator-State, den Agent A gerade verbogen hat, wenn Agent B «übernimmt»?

ACP, Project Graph und warum «weniger Tokens» kein Freifahrtschein ist

Laut Android Developers Blog injiziert ACP den vollen Project Graph, das Build-Setup und Plattform-Details direkt in den Agenten. Der Agent filtert anschließend auf Relevanz. Vendor-Claim: effiziente Token-Nutzung, niedrigere Latenz, schärfere Antworten. Für Android ist das kein Luxus. Multi-Modul-Projekte, Flavor-Dimensionen, Compose-Module, NDK-Teile – ohne Graph tippt der Agent im Nebel und brennt Quota für Dateien, die er nie hätte öffnen müssen.

Was bedeutet das konkret für Sie? Wenn der Agent weiß, welches Modul die Login-UI trägt und welche Dependency den Auth-Stack liefert, spart er sich das blinde Traversieren von app/, feature-auth/ und drei Legacy-Packages. Das ist der Nutzen. Der Fail-Modus: Der Graph ist aktuell, Ihr lokaler Build aber nicht. Sync hängt. Generated Sources fehlen. Der Agent sieht einen Graph, der gestern noch stimmte, und patcht gegen eine Realität, die Gradle noch nicht neu geschrieben hat. Weniger Tokens heißen dann: schneller falsch.

ACP transportiert nicht nur «welche Dateien es gibt». Laut Vendor-Darstellung gehören Build-Setup und Plattform-Details dazu – SDK-Level, Toolchain-Hinweise, die Art von Metadaten, an denen Agents sonst raten. Das ist der Hebel für niedrigere Latenz: weniger Nachfragen à la «welche minSdk?», weniger blinde grep-Orgien. Gleichzeitig steigt die Erwartung an Frische. Wer den Graph injiziert, muss Sync ernst nehmen. Ein Agent mit scharfem, aber veraltetem Graph ist präzise auf dem Holzweg. Für Multi-Modul-Apps mit Feature-Flags und generierten Bindings ist das kein Randfall – das ist der Normaldienstag.

Spoiler: Token-Effizienz löst kein Ownership-Problem. Sie macht nur den falschen Patch billiger und schneller.

Persönliche Einschätzung Nummer eins: Project-Graph-Injection ist der sinnvollste Teil von BYOA. Nicht die Agent-Auswahl. Wer den Kontext sauber reinreicht, macht jeden Agenten besser – Claude, Codex oder Antigravity. Wer drei Agents parallel auf denselben Graph loslässt, ohne klare Ownership, macht vor allem Chaos wahrscheinlicher. Die Infrastruktur ist gut. Die Parallel-Nutzung ist das Risiko.

Studio wirbt außerdem mit Workflow-Kontinuität: hin und her zwischen konversationellen Agent-Prompts und den zweckgebundenen Studio-Tools. Sie prompten, springen in Compose Preview, zurück zum Agenten, Diagnostics prüfen, Emulator anstoßen. Das ist der Idealpfad. In der Praxis unterbricht Sie der Permission-Prompt mittendrin. «Darf der Agent den Emulator steuern?» – Ja, Nein, Nur diesmal. Drei Agents, drei Prompt-Kulturen. Claude fragt anders als Codex. Antigravity hängt am Google-Login. Die kurze Version: Der Flow-State stirbt nicht am Modell. Er stirbt am Dialog «Allow shell?».

Dokumentation zum Protokoll selbst liegt unter anderem bei den ACP-Maintainern; wer die Schnittstelle technisch nachlesen will, findet Einstiege über agentclientprotocol.com. Für den Alltag in Studio reicht: ACP ist die Leitung, Studio der Stecker, Ihr Plan der Stromzähler.

Claude Agent, Codex, Antigravity – drei Agents, drei Fail-Modi

Featured sind Anthropic Claude Agent, OpenAI Codex und Google Antigravity. Zusätzlich: Registry für weitere ACP-Agents. Sign-in mit Ihrem Plan. Klingt nach Freiheit. Bastelprojekt mit Nebenwirkungen.

Fail-Modus Claude: Stark bei längeren Reasoning-Ketten und vorsichtigem Refactoring – bis die Quota kippt oder der Permission-Dialog für Shell-Befehle Sie aus dem Rhythmus wirft. Claude Agent kann laut Blog-Umfeld Dateien lesen/schreiben, Shell fahren, Tests starten, Web suchen, an Subagents delegieren. Wenn Sie granular freigeben, bleibt Kontrolle. Wenn Sie «Allow all for session» drücken, weil der Emulator schon seit zehn Minuten spinnt, haben Sie gerade die Sicherheitsstufe gesenkt, die BYOA eigentlich mitliefert.

Fail-Modus Codex: Codex kommt mit dem OpenAI-Stack-Feeling – schnell, tool-lastig, gerne ausführend. In Studio über ACP heißt das: derselbe Emulator, dieselben Dateien, anderer Stil. Codex will vielleicht den Testlauf jetzt, während Claude noch die Diagnose liest. Agent wechseln, weil Codex «besser performt», ist kein Merge. Es ist ein Kontextbruch. Persistente Sessions, Skills, Slash-Commands und Memory bleiben agent-seitig – nicht magisch geteilt über alle drei Tabs.

Fail-Modus Antigravity: Google empfiehlt Antigravity explizit für die beste Gemini-Erfahrung – Zugriff auf neuere Modelle wie Gemini Flash 3.8 und höheres Quota. Login über Google AI Pro/Ultra oder Pay-per-Token mit Gemini-API-Key. Enterprise: Gemini Enterprise weiter nutzbar, built-in oder Antigravity, mit Google-Cloud-Security/Privacy. Der Fail: Antigravity fühlt sich «nativer» an und verführt dazu, Permissions großzügiger zu geben. «Ist ja Google in Google.» Emulator-Control plus SDK-Tools plus Diagnostics – wenn das sitzt, ist der Agent mächtig. Wenn der State kippt, ist er mächtig falsch.

Rhetorische Frage, die Sie sich stellen sollten, bevor Tab drei aufgeht: Wenn Agent A den Emulator in einen Login-Loop gefahren hat und Agent B «übernimmt» – wer rollt den Snapshot zurück? Studio? Der Agent? Sie von Hand? Google erwähnt Agent-Flexibilität bei Quota und Performance. Google erwähnt nicht den Undo-Button für fremden Emulator-State.

Wer tiefer in Claude- und Codex-Alltag eintauchen will, findet bei uns Einordnung zu Claude Code und OpenAI Codex – BYOA bindet diese Welten in Studio ein, ersetzt aber weder deren Plan-Limits noch deren Eigenheiten.

https://digital-magazin.de/gemini/

Native Tools: Diagnostics, Compose Preview, SDK, Emulator-Control

Hier wird BYOA interessant – und gefährlich. Laut Blog verdrahtet Studio Build-Diagnostics, Jetpack Compose Previews, Android-SDK-Tools und Emulator-Control so, dass der Agent testen, diagnostizieren und direkt in Studio ausführen kann. Das ist mehr als Chat mit Dateizugriff. Das ist ein Agent mit Hebeln an Build und Runtime.

Diagnostics: Der Agent sieht Build-Fehler nicht nur als kopierten Log-Schnipsel, sondern über die IDE-Pipeline. Gut für «fix this compile error». Fail, wenn Diagnostics und lokaler Sync auseinanderlaufen und der Agent Fixes vorschlägt, die der nächste Sync wieder zerlegt.

Compose Preview: UI iterieren, ohne ständig die App neu zu installieren – Agent schlägt Preview-Änderungen vor, Sie prüfen visuell. Nützlich. Fail, wenn der Agent Preview-Parameter «optimiert», die in der echten Activity anders gebunden sind. Preview ≠ Runtime. Wer das vergisst, debuggt Luft.

SDK-Tools: Platform-Tools, Build-Tools, whatever der Agent über die injizierte Umgebung erreichen darf. Granulare Permissions sind hier Pflicht, kein Nice-to-have. Shell plus SDK ist die Kurzform von «kann viel kaputtmachen».

Emulator-Control: Der Elefant. Agent startet Apps, tippt Flows, liest State, force-stoppt Prozesse. Vendor-Nutzen: autonomes Testen in der IDE. Praxis-Fail: zwei Agents, ein Emulator. Agent A installiert Build 14. Agent B meint noch Build 13 und «reproduziert» einen Bug, den es gar nicht mehr gibt. Oder schlimmer: Agent A setzt Animations-Scale auf 0, Agent B misst Timing und wundert sich. Emulator-State ist shared mutable state. Agent wechseln ist kein Checkout.

Praktisches Runbook, das im Blog fehlt: Vor riskanten Agent-Läufen Emulator-Snapshot. Nach Agent-Wechsel denselben Snapshot prüfen oder hart zurücksetzen. Ein Agent darf Emulator-Control – die anderen default-deny, bis die Session geschlossen ist. Klingt pedantisch. Ist weniger pedantisch als drei Permission-Dialoge und ein Login-Loop, den niemand mehr reproduzieren kann. Wer Subagents spawnt, multipliziert das Problem: Der Parent hat freigegeben, der Subagent erbt Tempo, nicht unbedingt Ihre Vorsicht.

Persönliche Einschätzung Nummer zwei: Emulator-Control sollte in Teams default-deny sein, bis klar ist, wer Ownership hat. Ein Agent mit Emulator-Rechten ist ein Feature. Drei Agents mit Emulator-Rechten ohne Runbook sind ein Bastelprojekt, das Sie freitags um 17 Uhr bereuen.

Agents können laut Blog außerdem: Dateien lesen/schreiben/editieren, Shell, Tests, Websuche; an Subagents delegieren; mit granularen Permissions arbeiten; Kontext, Skills, Slash-Commands und Memory persistieren. Android Skills und die Android Knowledge Base sollen Best Practices nachreichen. Android Bench wird im Blog nur am Rand erwähnt – Performance-Messung von Agents, kein Feature-Pitch für BYOA. Wir lassen es hier bewusst am Rand.

Multi-Quota, Permission-Prompts und das Wechsel-Märchen

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptClose photorealistic photo of a mechanical keyboard and three blank sticky notes suggesting multiple AI agents, warm desk lamp, no logos, no brand names, no readable text, 16:9

Agent-Flexibilität klingt freundlich: Quota alle, Performance mau – anderer Agent übernimmt. In der Buchhaltung heißt das: drei Pläne, drei Limits, drei Billing-Seiten. Claude-Quota. Codex-Quota. Antigravity über Google AI Pro/Ultra oder API-Key. Enterprise zusätzlich Gemini Enterprise. Wer «einfach wechselt», wechselt nicht nur das Modell. Sie wechseln den Vertragskontext und oft den Memory-Stand.

Permission-Prompts skalieren linear mit der Sorgfalt und exponentiell mit der Ungeduld. Ein Agent, der für jede Shell fragt, nervt. Ein Agent, dem Sie alles erlauben, weil der Emulator hängt, spart Nerven und verbrennt Sicherheitsmargen. Drei Agents multiplizieren beides. Nerd-Alarm: «Granular» hilft nur, wenn Sie die Policy vorher festlegen – nicht während des Incidents.

Billing-Realität: Claude-Plan, Codex-Plan, Google AI Pro/Ultra oder API-Key für Antigravity – plus ggf. Gemini Enterprise. «Quota leer, Agent wechseln» ist ein Satz. In der Praxis heißt er: Anderer Vendor, anderer Memory, anderer Skill-Satz, anderer Slash-Command-Kosmos. Persistenz bleibt agent-seitig. Studio hält den Project Graph bereit; es hält nicht magisch drei Langzeitgedächtnisse synchron. Wer das verwechselt, wundert sich, warum Agent B denselben Bug «nochmal von vorn» diagnostiziert.

Und dann der Wechsel nach kaputtem State. Das ist der Kern der These. Drei Agents parallel ist kein Feature-Flex. Es ist Incident-Setup. Sie haben mehrere Akteure mit Schreibrechten auf denselben Workspace und denselben Emulator. Wenn einer den State verdirbt, ist «nächster Agent» kein Rollback. Es ist ein neuer Akteur auf einer schon schiefen Bühne. Snapshot des Emulators, Git-Cleanliness, klare Ownership – das sind die echten Flex-Features. Die stehen nicht fett im Blog-Titel.

Wir bei digital-magazin.de sehen BYOA deshalb zwiespältig: Die Öffnung über ACP und der Project Graph sind der richtige technische Schritt nach «any AI model». Die Inszenierung als belangloses Umschalten zwischen Claude, Codex und Antigravity unterschätzt, was shared Runtime bedeutet. Wer agentic arbeitet, kennt das aus Editoren und CLI-Agents – Studio macht es nur android-näher und damit folgenschwerer.

Zum Thema autonome Editoren und Agent-Risiken haben wir bereits eingeordnet: agentic AI Code Editor. BYOA ist dieselbe Klasse Problem, nur mit Emulator und Compose Preview in der Werkzeugleiste.

Gemini-Pfad: Built-in bleiben oder Antigravity mit Flash 3.8

Viele nutzen Gemini bereits über den built-in Agenten in Android Studio. Google sagt klar: Der bleibt. Für die beste Gemini-Erfahrung empfiehlt Warner aber Antigravity – neuere Modelle wie Gemini Flash 3.8, erhöhtes Quota. Login mit Google AI Pro oder Ultra, oder Pay-per-Token per Gemini-API-Key. Enterprise mit Gemini Enterprise: built-in oder Antigravity, Security/Privacy über Google Cloud.

Die praktische Lesart: Built-in ist der bekannte Weg. Antigravity ist der empfohlene Turbo – mit eigenem Agenten-Stack und dem Versprechen, näher an aktuellen Gemini-Releases zu sein. Flash 3.8 im Pitch heißt: Google will, dass Gemini-nutzende Teams den BYOA-Weg über Antigravity gehen, nicht nur den klassischen Studio-Agenten. Ob Ihr Team das braucht, hängt von Quota-Schmerz und Modell-Hunger ab – nicht vom Blog-Screenshot «Selecting the Google Antigravity agent».

Im Ernst: Wenn Sie nur Gemini fahren und zufrieden sind, ist BYOA kein Muss. Wenn Sie Claude für Refactors, Codex für Testläufe und Antigravity für Gemini-lastige Tasks wollen, dann ist BYOA genau die Einladung – und genau das Incident-Setup aus dem Einstieg. Wählen Sie bewusst, nicht aus Sammeltrieb.

Wer Gemini jenseits von Studio einordnet, findet bei uns den Hub unter Gemini. Der Antigravity-Pfad ist die Studio-Variante desselben Themenfeldes, nicht ein Ersatz für Plan- und Privacy-Fragen.

Rabbit 2 Canary: so kommen Sie ran – ohne Produktionsromantik

BYOA rollt als Preview aus, startend mit der Canary von Android Studio Rabbit 2. Featured Agents: Antigravity, Claude Agent, Codex. Weitere über die Registry. Schritte laut Blog:

1. Android Studio auf den aktuellen Canary-Kanal aktualisieren.
2. Im Agent-Fenster Agent wählen (Claude Agent, Codex oder Antigravity), Sign-in oder API-Key. Weitere Agents: Settings > Tools & AI & Agents.
3. Preview-Release-Notes und Docs lesen; Issues für Feedback filen.

Canary heißt: nicht stabil, nicht teamweit als Default, nicht «wir schalten freitags alle um». Preview heißt: Permissions, Quota-Verhalten und Emulator-Hooks können sich noch ändern. Wer das in einem Release-Branch mit shared Emulator-CI mischt, bastelt sich den Incident selbst.

die kurze Version für Teams: Eine Person testet Rabbit 2 Canary lokal. Ein Agent zuerst – nicht drei. Emulator-Control erst nach einer Policy. Quota-Limits notieren, bevor «Agent wechseln» zur Reflexhandlung wird. Feedback an Google filen, wenn der State nach Agent-Wechsel inkonsistent ist – genau das ist der blinde Fleck im Marketing.

Android-Themen bündeln wir unter Android; BYOA gehört dorthin als IDE-Story, nicht als neues OS-Feature. Copilot oder VS Code tauchen hier nur am Rand auf – anderer Stack, anderes Permission-Modell, kein Ersatz für diesen Studio-Move.

Incident-Setup statt Feature-Flex: was Sie mitnehmen sollten

Matthew Warner positioniert BYOA als «build your way»: Agent wählen, Plan mitbringen, Studio-Infrastruktur nutzen. Die Fakten aus dem Blog vom 24.9. stehen: ACP mit Project Graph und Build-Kontext; native Tools inkl. Diagnostics, Compose Preview, SDK, Emulator-Control; Agents mit Datei-/Shell-/Test-/Web-Rechten, Subagents, Permissions, persistenter Kontext; Gemini weiter built-in oder empfohlen über Antigravity mit Flash 3.8 und höherem Quota; Preview ab Rabbit 2 Canary; Registry unter Settings > Tools & AI & Agents.

Unsere These bleibt: Drei Agents parallel sind kein Feature-Flex. Sie sind ein Incident-Setup. Multi-Quota bedeutet drei Zähler. Permission-Prompts bedeuten drei Freigabe-Kulturen. Emulator-Control bedeutet shared mutable state. Agent wechseln nach kaputtem Emulator-State ist kein Undo.

Was wir bei digital-magazin.de deshalb raten: BYOA nutzen, aber serialisieren. Ein Agent pro Aufgabe. Ownership für den Emulator festnageln. Snapshots vor riskanten Agent-Läufen. Canary nicht mit Production-Signing vermischen. Vendor-Claims zu Tokens und Latenz als Versprechen lesen, nicht als Garantie für Ihren Multi-Modul-Monsterbau.

Fail/Nerd zum Schluss: Die Technologie – ACP, Graph-Injection, native Tool-Verdrahtung – ist der Teil, den Sie ernst nehmen sollten. Die Slideshow mit drei Logos ist der Teil, den Sie mit Misstrauen betrachten sollten. Studio wird offener für Agents. Ob Ihr Emulator das überlebt, hängt nicht vom Blog-Post ab. Sondern davon, ob Sie den zweiten und dritten Tab wirklich brauchen – oder ob Sie gerade nur sammeln.