Ce que vous pouvez faire
Avec la prise en charge de l’émulateur Android activée, Devin peut gérer l’ensemble du cycle de développement mobile :Build et smoke tests des PR
Devin build et exécute votre application sur l’émulateur, puis parcourt les flux critiques après chaque PR. Vous obtenez un enregistrement vidéo qui prouve que la fonctionnalité fonctionne — il ne vous reste plus qu’à le regarder et à fusionner.
Tests mobiles de bout en bout
Testez des parcours utilisateur complets — connexion, navigation, envoi de formulaire, paiement — sur une véritable stack Android, pas un mock. Devin suit le flux étape par étape et signale tout ce qui casse.
Vérification de l'UI
Vérifiez les mises en page, les thèmes et le comportement responsive sur différentes tailles d’écran et différents niveaux d’API. Devin prend des captures d’écran à des moments clés et signale les problèmes visuels, comme des éléments qui se chevauchent ou du texte tronqué.
Déboguer les crashes et les ANR
Reproduisez les problèmes sur l’émulateur, capturez la sortie
logcat, inspectez le comportement, identifiez la cause racine et poussez un correctif — le tout dans une seule session.Validation multiplateforme
Vous développez avec React Native, Flutter ou Kotlin Multiplatform ? Devin peut tester la partie Android en parallèle de vos builds web ou desktop dans la même session.
Exécution de tests instrumentés
Exécutez des suites de tests Espresso ou UI Automator sur l’émulateur et récupérez les résultats, sans avoir besoin d’une ferme d’appareils CI dédiée ni d’appareils physiques.
Tests multi-configurations
Vérifiez votre application sur différents niveaux d’API ou profils d’appareil en configurant plusieurs AVD. Utile pour détecter les problèmes de compatibilité avant qu’ils n’affectent les utilisateurs.
Comment ça fonctionne
La prise en charge de l’émulateur Android repose sur le même système de configuration déclarative que le reste de l’environnement de Devin. Vous ajoutez le SDK Android et l’émulateur à votre blueprint, et le build du snapshot de Devin crée une VM avec tout préinstallé. Chaque session démarre à partir de ce snapshot, avec l’émulateur prêt à l’emploi. Pendant une session, Devin interagit avec l’émulateur de deux façons :
La fenêtre de l’émulateur s’exécute sur le bureau de Devin, ce qui vous permet de voir Devin interagir avec votre application en temps réel via l’onglet Desktop de l’application web.
Configuration de l’émulateur
- Laissez Devin s'en charger (recommandé)
- Configuration manuelle du blueprint
La façon la plus simple de commencer. Devin analyse votre projet Android, installe les bons composants du SDK et configure l’émulateur pour vous.
1
Démarrer une session Devin
Ouvrez une nouvelle session et demandez à Devin de configurer l’émulation Android. Par exemple : “Configure un émulateur Android pour ce dépôt.”
2
Vérifier et approuver
Devin propose un blueprint avec le SDK Android, les outils de build et la configuration de l’émulateur. Consultez les cartes de suggestion dans votre timeline, puis cliquez sur Approve.
3
Vérifier
Une fois le build terminé, démarrez une nouvelle session. Demandez à Devin de build et d’exécuter votre application sur l’émulateur pour confirmer que tout fonctionne.
Ce qui est installé
Un blueprint type pour la prise en charge de l’émulateur Android installe :Utiliser l’émulateur
Tests à la demande
Demandez à Devin de build et d’exécuter votre application à tout moment au cours d’une session — aucune syntaxe particulière n’est nécessaire, utilisez simplement le langage naturel :- “Build et exécute l’application sur l’émulateur Android”
- “Teste le parcours de connexion sur l’émulateur et envoie-moi un enregistrement”
- “Ouvre l’écran des paramètres sur l’émulateur et vérifie que le nouveau bouton bascule apparaît”
- “Exécute les tests Espresso sur l’émulateur et montre-moi les résultats”
adb pour les actions automatisées et Computer Use pour les interactions visuelles.
Intégration avec les tests et les enregistrements
La prise en charge de l’émulateur Android s’intègre directement au workflow Tests et enregistrements de Devin. Après avoir créé une PR :- Devin propose de tester l’application — cliquez sur le bouton ou demandez-le directement à Devin
- Devin build et exécute l’application sur l’émulateur, puis exécute un plan de test ciblé
- L’écran de l’émulateur fait l’objet d’un enregistrement vidéo annoté
- L’enregistrement vous est envoyé pour que vous puissiez visionner le test et fusionner la PR en toute confiance
Suggestions de skills
Après avoir testé votre application Android, Devin consigne ce qu’il a appris — comment démarrer l’émulateur, quelles tâches Gradle exécuter, comment accéder à la fonctionnalité testée — et propose de créer ou de mettre à jour une Skill via une PR. Vous pouvez fusionner la PR telle quelle ou la modifier pour affiner les instructions. Au fil du temps, cela signifie que Devin devient plus efficace pour tester votre projet Android. Les apprentissages de chaque session s’appuient sur les précédents — ainsi, la deuxième fois que Devin teste votre application, il sait déjà comment lancer le build, quelle activité ouvrir et quels parcours sont les plus importants. Vous pouvez également demander à Devin de le faire à tout moment (p. ex., “create a skill for how to build and test this Android app”). Consultez le guide des Skills pour plus de détails.Interagir via le bureau
L’émulateur Android s’exécute dans une fenêtre sur le bureau Linux de Devin. Cela signifie :- Devin peut interagir avec lui via Computer Use — appuyer sur des boutons, balayer l’écran, saisir du texte, naviguer entre les écrans
- Vous pouvez le suivre en direct via l’onglet Desktop de l’application web Devin
- Les enregistrements incluent l’écran de l’émulateur ainsi que tout le reste visible sur le bureau de Devin
Utilisation de adb
Devin peut aussi interagir avec l’émulateur de manière programmatique via adb, ce qui est utile pour :
- Installer des APK —
adb install app-debug.apk - Exécuter des tests instrumentés —
adb shell am instrument -w com.example.test/androidx.test.runner.AndroidJUnitRunner - Capturer des logs —
adb logcatpour déboguer des plantages ou des comportements inattendus - Prendre des captures d’écran —
adb exec-out screencap -p > screenshot.png - Simuler des actions utilisateur —
adb shell input tap 500 800pour des interactions scriptées
adb et Computer Use selon la tâche : adb pour la rapidité et l’automatisation, Computer Use pour la vérification visuelle et les flux d’interface utilisateur complexes.
Exemples de blueprints
Blueprints prêts à copier-coller pour les configurations Android courantes. Chaque blueprint est autonome — collez-le dans votre éditeur de blueprint et enregistrez.Android natif (Kotlin/Java + Gradle)
Android natif (Kotlin/Java + Gradle)
React Native
React Native
Flutter
Flutter
Kotlin Multiplatform
Kotlin Multiplatform
Dépannage
L’émulateur ne démarre pas
Causes courantes : KVM n’est pas disponible dans la VM, la mémoire est insuffisante ou il manque une image système. Correctif : Devin peut tenter de configurer KVM automatiquement lorsqu’il détecte que l’émulateur a besoin d’une accélération matérielle. Dans la plupart des cas, cela résout le problème sans intervention manuelle. Si KVM n’est toujours pas disponible après la tentative de Devin, l’émulateur peut basculer en mode de rendu logiciel ; ajoutez-no-accel à la commande de lancement de l’émulateur, même si les performances seront réduites. Vérifiez également que votre blueprint installe l’émulateur ainsi qu’une image système x86_64 compatible.
Le build échoue avec des erreurs liées au SDK
Causes courantes : composants du SDK manquants, cheminANDROID_HOME incorrect, ou Gradle ne parvient pas à trouver la bonne version des outils de build.
Correctif : vérifiez que ANDROID_HOME est correctement défini dans votre blueprint et que sdkmanager installe la version de plateforme et la version des outils de build requises par votre projet. Vérifiez les valeurs compileSdk, targetSdk et buildToolsVersion dans le build.gradle de votre projet, puis faites-les correspondre dans le blueprint.
L’émulateur est lent
L’émulateur Android s’exécute dans la VM de Devin ; les performances dépendent donc de l’image système et du mode de rendu. Conseils :- Utilisez des images système
x86_64(et non ARM) pour une émulation accélérée par le matériel - Utilisez
-gpu swiftshader_indirectpour un rendu logiciel ne nécessitant pas de passthrough GPU - Utilisez
-no-window -no-audiolorsque Devin n’a pas besoin d’un affichage visuel (p. ex., pour exécuter des tests instrumentés viaadb) - Envisagez un profil d’appareil à plus faible résolution si la fidélité visuelle n’est pas essentielle
Devin ne peut pas interagir avec l’écran de l’émulateur
Causes fréquentes : Desktop mode n’est pas activé, la fenêtre de l’émulateur n’est pas visible ou l’émulateur s’exécute sans interface graphique. Correctif : Assurez-vous que Desktop mode est activé dans les paramètres de votre organisation. Si vous avez besoin que Devin interagisse visuellement avec l’émulateur, lancez-le sans l’indicateur-no-window afin que l’interface graphique de l’émulateur apparaisse sur le bureau de Devin. Vérifiez que l’émulateur a fini de démarrer (adb shell getprop sys.boot_completed doit renvoyer 1) avant de demander à Devin d’interagir avec lui.
