Capture d'écran automatique Android avec uiautomator2 MCP

Introduction

Si vous gérez plusieurs applications Android en tant que développeur solo, vous rencontrez régulièrement des tâches comme celles-ci :

• Recapturer des captures d'écran pour le Play Store
• Vérifications de régression UI
• Vérification du mode sombre
• Vérifications de mise en page cassée en multi-langue

Fait manuellement, cela nécessite des dizaines de captures d'écran par application.

Avec uiautomator2 MCP, vous pouvez automatiser l'ensemble du processus — contrôler un appareil Android depuis Claude Code ou Cursor pour parcourir et capturer chaque écran automatiquement.

Stratégie principale : Arbre UI + DeepLink

Il y a deux approches principales pour le parcours automatisé des écrans :

Pourquoi la reconnaissance d'image seule n'est pas fiable :

• La position de défilement de LazyColumn dérive
• Les clics manquent pendant les animations
• Les coordonnées changent sur les foldables et tablettes
• Les internes de WebView ne sont pas accessibles

Les agents d'automatisation Android modernes suivent le même pattern : "lire l'arbre UI d'abord, revenir à l'analyse d'image uniquement quand nécessaire."

Ce qui distingue uiautomator2 MCP

Contrairement à un simple wrapper ADB, uiautomator2 MCP peut lire l'arbre UI — et c'est son plus grand avantage.

<TextView text="Paramètres" resource-id="btn_settings" clickable="true"/>
<Button text="Enregistrer" resource-id="btn_save"/>

Cela permet à l'IA de recevoir des instructions en langage naturel comme :

• "Appuyer sur Paramètres"
• "Trouver Enregistrer"
• "Lister les enfants de RecyclerView"

Pourquoi tanbro/uiautomator2-mcp-server est un bon choix

C'est l'une des options MCP d'automatisation Android les plus complètes disponibles aujourd'hui.

Le filtrage d'outils est discrètement important — trop d'outils MCP confondent les LLM, donc pouvoir n'exposer que ce qui est nécessaire est une fonctionnalité de conception pratique.

Pattern d'implémentation de capture

Architecture idéale

Côté application : Screen Registry + DeepLink
  ↓
uiautomator2 MCP : démarrer / capturer / retour
  ↓
Sortie : screens/SettingsScreen.png, etc.

En code :

for screen in registry:
    open_deeplink(screen.url)   # adb shell am start...
    wait_idle()                  # attendre que l'UI se stabilise
    screenshot(screen.name)      # capturer et enregistrer

Convention de nommage pour les fichiers capturés

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

Inclure le nom de l'écran, le thème et la locale dans le nom de fichier facilite la comparaison.

La chose la plus importante : Construire un Screen Registry dans votre application

Se fier uniquement à MCP se casse sur les positions de défilement, les animations et la virtualisation LazyColumn.

L'investissement critique est de construire un "chemin de capture dédié" à l'intérieur de l'application elle-même.

Exemple de 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)

Utilisez ce Registry pour trois objectifs :

• Afficher le menu Debug
• Définir les DeepLinks
• Piloter l'automatisation des captures d'écran

Le partager entre les trois garde la maintenance simple.

Pourquoi la navigation DeepLink est stable

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

Naviguer directement via DeepLink signifie :

• Pas de dépendance à la position de défilement
• Pas de dérive de coordonnées due aux clics manqués
• Fonctionne de la même façon sur les foldables et tablettes
• Temps d'attente d'animation minimal

Cela permet à MCP de se concentrer purement sur la capture / l'attente / la vérification d'état.

Tirer parti de Compose testTag

Pour les écrans où DeepLink est difficile, vous pouvez taguer les éléments avec testTag et laisser uiautomator2 les trouver :

// Taguer la cible de capture
LazyColumn(
    modifier = Modifier.testTag("debug_screen_list")
) {
    items(DebugScreens.all) { screen ->
        Text(
            text = screen.name,
            modifier = Modifier.testTag("debug_item_${screen.name}")
        )
    }
}

La plupart des MCP uiautomator2 peuvent lire resource-id, accessibilité et testTag. Standardiser les valeurs testTag améliore dramatiquement la stabilité des opérations.

Mises en garde

Où uiautomator2 a des difficultés

La récupération de l'arbre UI peut être peu fiable dans ces situations :

Mitigation : confirmer que l'écran s'est stabilisé avant d'agir (wait_idle() ou activity_wait_appear).

Ce qui devient possible

Avec Screen Registry + DeepLink + uiautomator2 MCP en place :

Résumé

"Essayer fort d'explorer les écrans via MCP" est bien moins efficace que "construire un Screen Registry + DeepLink dans votre application." MCP fonctionne mieux comme couche d'opération sur ce fondement.