Automatische Vollbild-Screenshots auf Android mit uiautomator2 MCP

Einleitung

Wenn man als einzelner Entwickler mehrere Android-Apps verwaltet, entstehen regelmäßig folgende Aufgaben:

• Play Store-Screenshots neu aufnehmen
• UI-Regressionstests durchführen
• Dark-Mode-Kompatibilität überprüfen
• Mehrsprachige Darstellungsfehler erkennen

Dies alles manuell zu erledigen bedeutet, für jede App dutzende von Screenshots zu machen.

Mit uiautomator2 MCP können Sie aus Claude Code oder Cursor Android-Geräte steuern und alle Bildschirme automatisch durchlaufen und fotografieren.

Grundlegende Richtung: UI Tree + Deep Link

Es gibt zwei Methoden, um Bildschirme automatisch zu durchlaufen.

Warum Bildverarbeitung allein nicht ausreicht:

• LazyColumn-Scroll-Position verschiebt sich
• Taps können während Animationen fehlschlagen
• Koordinaten ändern sich auf Foldables und Tablets
• WebView-Inhalte sind nicht erkennbar

Auch moderne Android-Automations-Agenten nutzen zunehmend „UI Tree auslesen → bei Bedarf Bildanalyse hinzufügen".

Merkmale von uiautomator2 MCPs

Im Gegensatz zu einfachen ADB-Wrappern ist die Möglichkeit, den UI Tree auszulesen, die größte Stärke von uiautomator2 MCPs.

<TextView text="Settings" resource-id="btn_settings" clickable="true"/>
<Button text="Save" resource-id="btn_save"/>

Dies ermöglicht der KI:

• „Settings drücken"
• „Save suchen"
• „Elemente von RecyclerView auflisten"

und ähnliche Operationen mit natürlicher Sprache anzuweisen.

Warum tanbro/uiautomator2-mcp-server eine gute Wahl ist

Aktuell eine der ausgereiftesten Optionen bei Android-Automations-MCPs.

Tool Filtering ist subtil wichtig: Wenn MCPs zu viele Tools haben, kann das LLM verwirrt werden. Ein Design, das nur benötigte Tools veröffentlicht, ist für den praktischen Einsatz geeigneter.

Implementierungsmuster für automatische Erfassung

Ideale Struktur

App-Seite: Screen Registry + Deep Link
  ↓
uiautomator2 MCP: start/capture/back
  ↓
Ausgabe: screens/SettingsScreen.png usw.

In Code ausgedrückt sieht das so aus:

for screen in registry:
    open_deeplink(screen.url)   # adb shell am start...
    wait_idle()                  # Bis UI stabil ist
    screenshot(screen.name)      # Aufnehmen und speichern

Benennungskonvention für Screenshot-Dateien

screens/
├── SettingsScreen.png
├── SettingsScreen_dark.png
├── SettingsScreen_ja.png
├── ProfileScreen.png
└── PurchaseDialog.png

Eine Benennungskonvention, die Bildschirmname, Theme und Locale kombiniert, macht Vergleiche leichter.

Eine Screen Registry in der App zu erstellen ist das Wichtigste

Wenn man sich nur auf MCP verlässt, kann es bei Scrolling, Animationen und LazyColumn zu Fehlern kommen.

Es ist grundlegend wichtig, „dedizierte Navigationspfade zum Screenshotting" in der App zu schaffen.

Beispiel einer Screen Registry (Kotlin)

object DebugScreens {
    val all = listOf(
        ScreenEntry("settings",  "myapp://debug/settings"),
        ScreenEntry("profile",   "myapp://debug/profile"),
        ScreenEntry("billing",   "myapp://debug/billing"),
    )
}

data class ScreenEntry(val name: String, val deepLink: String)

Diese Registry kann für:

• Debug-Menü-Anzeige verwendet werden
• Deep Link-Definition verwendet werden
• Screenshot-Automatisierung verwendet werden

Durch die gemeinsame Nutzung an drei Stellen wird die Wartbarkeit verbessert.

Warum Deep Link-Verfahren stabil ist

adb shell am start \
  -a android.intent.action.VIEW \
  -d "myapp://debug/settings"

Durch direkte Transition über Deep Links:

• Unabhängig von Scroll-Position
• Keine Verschiebung der Tap-Koordinaten
• Funktioniert gleich auf Foldables und Tablets
• Minimale Animations-Wartezeit

MCP kann sich auf die Rollen beschränken: capture / wait / Statuskontrolle.

Verwendung von Compose testTag

Bei schwierigeren Bildschirmen können Sie auch testTag verwenden, um sie mit uiautomator2 zu finden.

// testTag zu Screenshot-Ziel hinzufügen
LazyColumn(
    modifier = Modifier.testTag("debug_screen_list")
) {
    items(DebugScreens.all) { screen ->
        Text(
            text = screen.name,
            modifier = Modifier.testTag("debug_item_${screen.name}")
        )
    }
}

Viele uiautomator2-MCPs können resource-id / accessibility / testTag auslesen, und wenn Sie testTag standardisieren, steigt die Operationsstabilität erheblich.

Hinweise

Schwache Punkte von uiautomator2

Die UI-Tree-Erfassung kann in folgenden Situationen instabil sein.

Abhilfe: Vor dem Betrieb sicherstellen, dass der Bildschirm stabil ist (mit wait_idle() oder activity_wait_appear).

Sicherheitshinweis

Einige uiautomator2 MCPs können adb shell und Dateizugriff nutzen.

• Nur lokal verwenden (nicht im öffentlichen Netzwerk verfügbar machen)
• Emulator verwenden
• Mit Work Profile isolieren

Weiterentwicklung: Was wird möglich

Mit einer ausgereiften Screen Registry + Deep Link + uiautomator2 MCP Struktur:

Zusammenfassung

„MCP versuchen zu nutzen um Bildschirme zu suchen" ist weniger wichtig als „Screen Registry + Deep Link in die App implementieren". MCP sollte als Operationsebene darüber verwendet werden.