11 workflows Gemini pour Android Studio : tests, prévisualisations, mode Agent et gestion des plantages.

Les développeurs Android ont rarement besoin d’une autre liste de prompts intelligents pour l’IA. Ce qui est utile, c’est moins de changements de contexte, des boucles de rétroaction plus rapides et moins de temps consacré à des tâches mécaniques. C’est là que Gemini dans Android Studio trouve sa place.

Ne le considérez pas comme un collègue qui peut gérer une fonctionnalité pendant que vous vous éloignez. Pensez-y plutôt comme un pair programmeur rapide intégré à l’IDE. Il est doué pour explorer du code inconnu, rédiger des tâches répétitives, interpréter des erreurs complexes et regrouper plusieurs petites étapes en un seul diff que vous pouvez examiner.

C’est la précision qui distingue les deux. Une demande comme « développe cette fonctionnalité » est trop vague pour être mise en œuvre, tandis que demander à Gemini de suivre un flux d’états, de suggérer la correction la plus petite, d’exécuter les tests pertinents et de vous montrer le diff correspond à un véritable travail d’ingénierie.

Début septembre 2026, Gemini dans Android Studio permet de travailler sur plusieurs fichiers en mode Agent, d’exécuter des conversations parallèles, de générer des tests unitaires et des prévisualisations Compose, d’aider à résoudre les problèmes de compilation et ceux affichés dans Logcat, d’analyser les plantages signalés par App Quality Insights, de mettre à jour les dépendances, et même de déployer sur un appareil connecté pour interagir avec lui. Il s’agit de fonctionnalités réelles du produit, pas de démonstrations spéculatives, et leur liste se trouve dans la présentation générale des fonctionnalités de Gemini. La question pratique est de savoir comment les utiliser sans créer plus de travail de révision qu’elles n’en économisent.

Les workflows présentés ci-dessous se révèlent particulièrement utiles dans le travail quotidien avec Android.

1. Fournir à Gemini une carte du projet une seule fois

Le meilleur résultat n’est souvent pas obtenu grâce à une instruction textuelle, mais via un bref fichier AGENTS.md commité en même temps que le code.

Gemini récupère les fichiers AGENTS.md dans le répertoire de travail ainsi que dans chacun de ses répertoires parents. Cela vous permet de placer des règles générales à la racine du dépôt et d’ajouter des directives plus spécifiques à l’intérieur de chaque module. Comme le fichier est stocké à côté du code, toute votre équipe reçoit les mêmes instructions via le contrôle de version. La documentation des fichiers d’agent contient les détails correspondants.

# Android project guidance
- Kotlin only.
- Follow the existing Clean Architecture boundaries.
- Keep business logic out of Composables and Activities.
- Expose immutable UI state from ViewModels.
- Collect Flow with lifecycle awareness.
- Prefer the libraries already used in the target module.
- Make the smallest safe diff; do not reformat unrelated files.
- Add or update tests for changed behavior.
- Before finishing, run the narrowest relevant Gradle test task.

Dans une application à plusieurs modules, ajoutez des fichiers locaux là où les règles diffèrent :

AGENTS.md
player/AGENTS.md
androidtv/AGENTS.md
billing/AGENTS.md

La concision est essentielle ici. Il convient d’inclure : les décisions architecturales, le point de départ de chaque module, les bibliothèques de test préférées, ainsi que les zones qu’il ne faut absolument pas toucher. Un manifeste de 200 lignes devient simplement un contexte obsolète.

Vérifiez un détail concernant la version. Les documents Google AGENTS.md sont pris en charge à partir d’Android Studio Narwhal 4 Feature Drop Canary 4, tandis que la version Narwhal 3 Feature Drop exigeait un seul fichier AGENT.md. Vérifiez la version de votre IDE avant de supposer que ce fichier a un effet quelconque.

2. Utilisez un résumé de tâche en quatre lignes

Des instructions plus longues ne sont pas automatiquement meilleures. Un format court fiable se compose de quatre parties :

Goal: Add retry support to PlaybackRepository.
Context: Inspect PlaybackRepository, its interface, and existing tests.
Constraints: Preserve public APIs; use the existing coroutine/test stack; minimal diff.
Verification: Add failure-then-success tests and run the relevant module test task.

Cela fonctionne car il élimine quatre ambiguïtés courantes : ce qui doit changer, où chercher, ce qui doit rester stable, et ce que signifie « terminé ».

Pour des tâches à risque, ajoutez une ligne supplémentaire :

Before editing, explain the likely root cause and propose a plan.

Pour les tâches routinières, évitez les formalités et demandez directement la différence. La taille de la requête doit correspondre au niveau de risque.

3. Restez dans un contexte restreint et séparez les threads

Un excès de contexte peut nuire à la qualité de la réponse si la majeure partie n’a aucun rapport avec la question. Lorsque le contexte suffit pour analyser les modifications, joignez le ViewModel, le modèle d’état, le contrat du repository ainsi que les tests pertinents, et omettez le reste de l’application. Android Studio vous permet de joindre directement des fichiers de projet à une requête.

Utilisez des threads distincts pour des tâches différentes, telles que :

• un bug de lecture
• une migration de dépendance
• la génération de tests
• le travail sur l’interface UI Compose

Gemini se souvient de l’historique des conversations. Google indique que des threads distincts peuvent améliorer la qualité des réponses en limitant le contexte au sujet en cours, et que supprimer l’historique obsolète aide lorsque la discussion a dévié. Voir « Chat avec Gemini ». Une règle simple : si votre prochaine demande nécessite l’expression « ignorer tout ce qui précède », ouvrez un nouveau thread.

4. Laissez la fonction de prédiction des prochaines modifications effectuer les corrections fastidieuses

La complétion automatique fonctionne au niveau du curseur. La fonction de prédiction des prochaines modifications va plus loin en devinant les modifications pertinentes ailleurs dans le fichier ou le projet. Elle est particulièrement utile après des changements tels que :

• une nouvelle propriété dans un état UI
• un cas de classe scellée rebaptisé
• une signature de fonction modifiée
• une branche d’une mise en correspondance répétée que vous venez de mettre à jour
• la même vérification de sécurité nécessaire à un endroit voisin

Dès que l’éditeur affiche Tab pour déplacer, une première touche Tab vous amène à la modification suggérée et une seconde l’applique. Si la prédiction est incorrecte, appuyez sur Esc. Les prédictions peuvent être mises en pause, et le délai avant l’envoi d’une demande est ajustable dans les paramètres de l’éditeur IA, comme expliqué sur la page Prédictions de prochaine modification.

Accepter les suggestions par réflexe est une mauvaise habitude. Une modification rapide et erronée copiée dans plusieurs fichiers constitue néanmoins un recul.

5. Poser des questions à partir de l’interface d’erreur

Lorsque la synchronisation Gradle échoue ou que l’application plante, l’IDE dispose déjà d’un contexte structuré. Utilisez alors l’action Demander à Gemini directement sur place, plutôt que de coller des informations inutiles dans un chat.

Dans Logcat, Gemini peut recevoir la trace d’erreur en question et répondre par un résumé en langage simple, les causes probables ainsi que des solutions suggérées. Les documents d’intégration de Logcat en traitent. Un suivi posant des questions sur la réponse fonctionne très bien :

Trace this to the first frame owned by our app. Explain the state that makes it fail.
Propose the smallest fix, identify any behavior change, and add a regression test.
Do not hide the problem with a broad try/catch or a non-null assertion.

Cette instruction finale permet d’éviter deux résultats courants liés à la méthode « construction verte, correction inefficace ». En cas d’échec de construction, demandez à Gemini d’identifier l’erreur principale par rapport à la chaîne d’échecs qu’elle a provoquée. Corriger la première erreur significative est généralement plus rapide que de s’occuper de 40 messages supplémentaires.

6. Générer des tests à partir du comportement, et non de l’implémentation

La création de classes de tests unitaires en Kotlin ou en Java, comprenant du code de configuration, des mocks et des cas individuels, relève des capacités de Gemini, qui les adapte en fonction de la configuration actuelle du projet. Google continue d’appeler l’ensemble de ce processus une version préliminaire et le documente pour Android Studio Panda 4 Canary 3 ou ultérieures. La page de génération des tests unitaires fournit plus de détails.

Une demande insuffisamment précise ressemble à ceci :

Write tests for PlaybackViewModel.

Un exemple utile se présente comme ceci :

Generate unit tests for PlaybackViewModel.
Cover observable behavior:
- initial state;
- successful playback start;
- repository failure;
- duplicate play requests;
- cancellation when the ViewModel is cleared.
Use the test libraries and coroutine dispatcher pattern already present in this module.
Do not test private methods or reproduce the implementation in the assertions.
Use deterministic virtual time and verify emitted UI states in order.
Run the narrowest relevant test task after editing.

Examinez ce que cela écrit. Demandez si chaque test pourrait échouer pour une raison valable. Les problèmes courants sont des simulations trop laxistes, des assertions qui reflètent simplement la configuration initiale, des retards réels, un manque de couverture pour les cas de cancellation, ainsi que des tests liés de manière trop étroite aux détails d’implémentation privés.

L’IA est excellente pour éliminer les obstacles liés aux structures temporaires, mais elle ne contrôle pas votre stratégie de tests.

7. Générer des aperçus Compose avant d’ouvrir l’émulateur

Les aperçus constituent un moyen peu coûteux d’obtenir des retours dans Compose, mais la création de données d’aperçu crédibles est une tâche fastidieuse. Gemini générera un aperçu pour un Composable unique ou pour chacun des Composables concernés dans un fichier, en incluant des données simulées pour les paramètres d’aperçu. Vous verrez le résultat sous forme de diff que vous pourrez accepter ou rejeter. Voir Générer des aperçus Compose.

Le seul scénario réussi ne prouve pas grand-chose, il est donc nécessaire de demander une matrice compacte des états possibles :

Generate previews for compact phone, tablet, and Android TV widths.
Include loading, populated, empty, long-title, and error states.
Use the existing theme and PreviewParameterProvider pattern.
Do not call a ViewModel, network layer, or dependency injection from previews.

Les aperçus servent alors de tests de conception peu coûteux. Les hypothèses de mise en page ont tendance à échouer avec des titres très longs, du contenu vide, la gestion de l’focus et les grands écrans.

Pour Android TV, demandez explicitement des variantes avec et sans focus. Une mise en page qui fonctionne bien à l’aide du toucher peut se dégrader dès que quelqu’un la navigue avec le D-pad d’une télécommande.

8. Dirigez le mode Agent sur une tranche verticale délimitée

Au mode Agent, Gemini peut élaborer un plan pour une tâche en plusieurs étapes, modifier plusieurs fichiers, exécuter des outils, construire le projet et réessayer en cas d’échec. Il est également possible de gérer plusieurs conversations simultanément, comme l’indique la documentation du mode Agent.

L’approche idéale consiste à travailler sur une tranche verticale délimitée, et non à « moderniser l’application ». Par exemple :

Add a Saved Episodes filter to the Downloads screen.
First inspect the existing state, reducer/ViewModel, domain model, repository, and tests.
Reuse the current filter component and architecture.
Do not change persistence or navigation contracts.
Implement the smallest complete slice, add tests, build the module, and summarize every file changed.
Pause before any public API or database schema change.

Une tâche de ce type est suffisamment importante pour bénéficier d’un travail inter-fichiers, mais suffisamment petite pour être examinée en détail.

Menacez des conversations parallèles uniquement pour des tâches indépendantes, comme la génération de tests dans un thread tandis qu’un autre examine un avertissement de compilation non lié. Deux agents travaillant sur des fichiers qui se chevauchent entraînent des hypothèses contradictoires.

9. Faire en sorte que l’agent prouve un changement d’interface utilisateur sur un appareil

Un diff de code ne prouve pas que une fonctionnalité d’interface fonctionne.

L’agent d’Android Studio peut envoyer une version compilée sur un appareil connecté, observer l’écran, prendre des captures d’écran, lire les données de Logcat et manipuler l’appareil à l’aide d’outils d’entrée. Après une correction de l’interface, une demande de vérification comme celle-ci clôt le cycle :

Build and run the app on the connected device.
Open the Downloads screen, apply the Saved filter, and verify the empty and populated states.
Capture a screenshot of the final state and check Logcat for new errors.
If verification fails, stop and report what you observed before making another broad change.

Conservez une personne dans le processus d’approbation pour tout ce qui concerne les connexions, les achats, les actions destructrices ou les données réelles des utilisateurs. L’accès à un appareil rend l’agent plus capable, mais cela ne signifie pas pour autant qu’il soit fiable.

10. Considérez les données de panne en environnement de production comme point de départ

Dans App Quality Insights, vous pouvez demander à Gemini de résumer une panne, d’indiquer le fichier où elle a commencé, de décrire la cause probable et de rédiger une proposition de modification de code. Le guide d’analyse des pannes de Google explique ce processus en détail.

De bonnes questions de suivi incluent :

What evidence in this stack trace supports that root cause?
Which assumptions are you making?
Could this be lifecycle-, concurrency-, process-death-, or device-specific?
What telemetry or test would distinguish the alternatives?

Les plantages de production révèlent souvent des problèmes de synchronisation et d’état que seul un traceur d’exception ne peut pas expliquer. Le résumé permet d’économiser du temps de lecture, mais l’hypothèse doit encore être validée.

11. Mettre à jour les dépendances un groupe limité à la fois

Le flux de travail relatif aux dépendances permet de trouver des mises à jour compatibles, de modifier le projet, de résoudre les erreurs de compilation qui en résultent, d’exécuter les tests et de finaliser par un rapport incluant des différences pour chaque fichier. Cela est décrit dans Automate dependency updates.

C’est très puissant, mais il faut réduire l’impact négatif :

Update only Kotlin coroutines and the related test artifact.
Do not update AGP, Kotlin, Compose, Gradle, or unrelated libraries.
Read the relevant migration notes first.
Build affected modules, run their unit tests, and report behavior or API changes.
Stop if the update requires a public API, minSdk, targetSdk, or build-system change.

Évitez les revues monstres qui tentent de « mettre à jour tout le monde » en regroupant AGP, Kotlin, Compose, la sérialisation, DI ainsi que vingt bibliothèques différentes. Les différences peuvent apparaître en quelques minutes, mais quelqu’un doit quand même en comprendre le sens.

Protégez le contexte avant d’optimiser les prompts

Lorsque le partage du contexte du projet est activé, un fichier .aiexclude détermine ce que Gemini peut lire. Sa syntaxe correspond à celle de .gitignore, et chaque règle s’applique au dossier contenant le fichier ainsi qu’à tout ce qui s’y trouve. Les fonctionnalités d’IA ne peuvent pas voir quoi que ce soit en dehors du projet ouvert et de ses racines de VCS associées, mais les fichiers sensibles situés dans ces limites doivent néanmoins être exclus par nom. La page de configuration de .aiexclude indique les étapes à suivre.

*.jks
*.keystore
local.properties
secrets/
**/production-config.json
**/customer-data/

Ces deux fichiers ne sont pas interchangeables, donc ne les traitez pas comme tels. Étudiez ce que votre organisation autorise avant d’envoyer du code propriétaire ou des données de production quelque part. Au niveau individuel, la notice de confidentialité de Google indique que les demandes, les résultats, les détails d’utilisation et les retours peuvent être collectés et consultés par des évaluateurs humains, et elle conseille de ne pas entrer d’informations confidentielles ou personnelles. Les accords commerciaux peuvent différer, il convient donc de lire les conditions relatives à votre compte.

Règle des 60 secondes pour examiner les modifications apportées par l’IA

Au moment d’accepter une différence générée par Gemini, posez-vous six questions :

1. La différence se limite-t-elle à ce que vous avez demandé ?
2. Les limites entre les modules et l’architecture sont-elles intactes ?
3. A-t-on créé une API, une dépendance ou une convention ?
4. Les erreurs sont-elles vraiment gérées, ou simplement ignorées ?
5. Les nouveaux tests échoueraient-ils si le comportement changeait ?

La compilation, l’exécution des tests et la vérification sur le dispositif confirment-elles la validité du changement ?

Si les réponses ne arrivent pas rapidement, le changement est trop important, il faut donc le diviser.

Le flux de travail itératif

Un cycle simple est le plus efficace :

Expliquer → planifier → modifier → tester → exécuter → examiner → résumer.

Gemini est le plus utile lorsqu’il raccourcit ce cycle au sein d’Android Studio. Il est le moins utile lorsqu’il fournit un gros bloc de code Kotlin plausible que personne n’a enregistré dans le répertoire ni exécuté.

Une frappe plus rapide n’est pas la source de la productivité. La confiance se crée plus tôt : un traceur d’erreurs qui enfin a du sens, un test qui se compile, une prévisualisation Compose avec des données réalistes, une capture d’écran du dispositif, et un diff suffisamment court pour être lu.

Qu’il revienne à Gemini de gérer l’aspect mécanique entre une intention et la preuve que celle-ci fonctionne. L’architecture, les compromis et la responsabilisation restent du ressort de l’ingénieur.