Android-Apps mit einem Coding-Agent

Ein Coding-Agent kann die Registrierung deiner Android-App so testen wie ein Mensch: Er baut sie, führt sie im Android Emulator aus, füllt das Formular mit einer Proxy Mail QA-Testadresse aus und gibt dann den Code ein oder öffnet den Link aus der E-Mail. Proxy Mail QA gibt dem Agent die Adresse und den Code oder Link aus der E-Mail; den Emulator steuert der Agent mit seinen eigenen Tools, meist adb.

Jedes Setup unten beginnt damit, dass Proxy Mail QA mit dem Agent verbunden ist: Füge das Setup mit einem Prompt ein oder verbinde den MCP server von Hand.

Claude Code, Codex oder Cursor mit adb

Jeder Agent, der Shell-Befehle ausführen kann, kann den Emulator über adb aus den Platform Tools des Android SDK steuern. Starte einen Emulator über den Device Manager von Android Studio (oder emulator -avd mit seinem Namen), öffne dein Projekt im Agent mit verbundenem Proxy Mail QA und frage:

Baue die Debug-App, installiere sie auf dem laufenden Emulator und öffne sie. Registriere dich mit einer neuen Proxy Mail QA-Testadresse und dem Passwort, das sie dir gibt, gib dann den Bestätigungscode aus der E-Mail ein und prüfe, ob die App das Konto als bestätigt anzeigt. Mach bei jedem Schritt einen Screenshot.

Der Agent macht dann typischerweise Folgendes:

1. Er baut und installiert mit ./gradlew installDebug und öffnet die App mit adb shell am start.
2. Er ruft create_address mit password: true auf.
3. Er findet die Felder über adb shell uiautomator dump (oder einen Screenshot von adb exec-out screencap -p), tippt sie mit adb shell input tap an und schreibt mit adb shell input text.
4. Er sendet ab und ruft dann wait_for_code oder wait_for_link auf.
5. Er gibt den Code ein oder öffnet den Link in der App mit adb shell am start -a android.intent.action.VIEW -d und dem Link, damit dein App Link oder dein eigenes Schema ihn verarbeitet.
6. Er macht einen Screenshot und prüft, ob der Bildschirm das Konto als bestätigt anzeigt.

adb shell input text braucht Leerzeichen als %s und manche Zeichen maskiert. Bitte den Agent also, jedes Feld nach der Eingabe zu prüfen, besonders Passwörter.

Der Gemini-Agent von Android Studio

Der Agent-Modus von Android Studio kann entfernte MCP-Server nutzen (Anleitung von Google). Wähle in Settings → Tools → AI → MCP Servers Enable MCP Servers und füge hinzu:

mcp.json

{
  "mcpServers": {
    "proxymail-qa": {
      "httpUrl": "https://api.proxymail.qa/mcp"
    }
  }
}

Wähle Start Login, um dich im Browser anzumelden. Android Studio unterstützt keine MCP-Prompt-Vorlagen, frag also in einfachen Worten, statt einen Prompt wie test_signup_flow zu wählen. Wir haben den Agent von Android Studio selbst noch nicht getestet; wenn die Anmeldung nicht abschließt, nutze stattdessen Claude Code oder Codex neben Android Studio.

Was du noch erfragen kannst

• Ein Dev-Server auf deinem Computer. Der Emulator erreicht deinen Computer unter 10.0.2.2, daher sind Links eines Dev-Builds auf 10.0.2.2:3000 zu erwarten. Bitte den Agent, es als Dev-Umgebung zu markieren (mark_dev_host), dann lässt check_email diese Links gelten, statt sie als Fehler zu werten.
• App Links. Nachdem der Link angekommen ist, prüft check_email mit expect_host auf deine App-Link-Domain, ob der Link dorthin führt, und count_emails erkennt eine versehentlich gesendete zweite E-Mail. Wenn der Link Chrome statt der App öffnet, liegt es meist an assetlinks.json der Domain oder am Intent-Filter der App.
• Ein Code, aufgeteilt in Kästchen. Der Agent tippt auf das erste Kästchen, gibt den ganzen Code ein und prüft dann, ob jede Ziffer angekommen ist, bevor er weitermacht.
• Ein längeres Registrierungsformular. Für einen Benutzernamen mit Regeln, ein Geburtsdatum oder ein Land liefert form_values für jedes Feld einen Wert aus einer neuen Adresse, die dafür erstellt wird.
• Dasselbe Konto beim nächsten Mal. Bitte den Agent, beim Erstellen festzuhalten, wo das Konto verwendet wird (environment, etwa staging, und Tags wie android), damit list_addresses es wiederfindet. Mit einem API-Schlüssel, der gespeicherte Passwörter lesen darf, liefert get_sign_in das Konto und sein Passwort in einem Aufruf.
• Ein Bericht. Der Agent ruft zuerst start_run und am Ende finish_run auf, das den Bericht in Markdown zurückgibt.

Angebote und Marketing-E-Mails

• Der Gutschein. Nach der Anmeldung für ein Angebot in der App liefert wait_for_code mit kind: coupon den Gutschein mit Rabatt, Enddatum und wie lange es gedauert hat. Der Agent gibt ihn in das Aktionscode-Feld der App ein.
• Checkout, nur mit Testzahlungen. Nutze die Lizenztester und Testkarten von Google Play oder den eigenen Testmodus der App, nie eine echte Karte oder einen echten Kauf. Der Agent hält mit record_coupon_result fest, was die App gemacht hat.
• Ein Gutschein als Link, der die App öffnet, etwa myapp://redeem?code=…: wait_for_link mit app: true liefert ihn, und der Agent öffnet ihn mit adb shell am start -a android.intent.action.VIEW -d und dem Link.
• Ein Angebot pro Person. Eine erneute Anmeldung mit einer Variante derselben Adresse (get_address_variants) und danach check_offers zeigt, ob die App das Angebot zweimal gewährt hat.
• Schwierige Namen und Passwörter. get_name_variants und get_password_variants liefern Werte für die anderen Felder des Formulars (Apostrophe, Akzente, andere Schriften, jede Symbolklasse, die Grenzen des Felds); der Agent gibt jeden ein und berichtet, was die App gemacht hat.
• Einwilligung und Abmeldung. Der Agent hält mit record_consent fest, was er bei der Registrierung gewählt hat, meldet sich in den Einstellungen der App oder über den Link der E-Mail ab, ruft mark_unsubscribed auf, und später listet check_unsubscribe alle Marketing-E-Mails, die danach kamen.

Stattdessen als Test schreiben

Um die Prüfung als UI-Test zu behalten, der in CI läuft, siehe Android (Espresso) oder Maestro für einen Ablauf, der auch iOS abdeckt.