Android Studio Quail 4 et Gemma 4 : un test d'acceptation de route de codage locale pour les equipes Android de production

La completion de code hors ligne est un mauvais substitut a la preparation a la production. C'est le piege d'adoption que les equipes Android doivent eviter alors qu'Android Studio Quail 4 arrive avec les Android skills integres et l'assistance locale Gemma 4. Un modele peut fonctionner sur la machine d'un developpeur, sembler utile dans l'IDE, et tout de meme produire un correctif qui echoue avec Gradle, oublie un detail de migration, casse lint ou ne laisse aucun chemin de retour propre.

Google indique qu'Android Studio Quail 4 est une version stable. Son article de lancement Android Developers presente aussi les Android skills et l'assistance locale Gemma 4 comme des ajouts significatifs pour le travail Android assiste par l'IA. Tres bien. Quail 4 merite un pilote serieux. Il ne merite pas un laissez-passer vers les branches de production.

La question utile est plus etroite : cette route de codage locale peut-elle produire des changements Android relisables pour une classe de taches nommee, sous vos limites materielles, regles de politique, configuration Gradle, couverture de tests et processus de rollback ? Cette meme logique au niveau de la route s'applique a d'autres decisions d'adoption d'outils, notamment l'adoption de workflows de simulation GPU, les pipelines de simulation d'IA incarnee et la qualification des charges de travail d'IA locales. Les equipes qui comparent des schemas de gouvernance plus larges peuvent aussi lire la logique de route a cote de l'acceptation du controle d'appareils physiques.

Cet article utilise le Local Coding Route Acceptance Test d'Optijara, ou LCRAT, comme cadre d'acceptation pratique pour Android Studio Quail 4, les Android skills et l'assistance locale Gemma 4.

Ce que Quail 4 change, et ce que cela ne prouve pas

Android Studio Quail 4 est la derniere version stable de la ligne Quail, selon la mise a jour de publication de Google. L'article Android Developers indique que Quail 4 integre les Android skills dans Android Studio, prend en charge Gemma 4 comme option de modele local et ajoute une assistance agentique pour les taches de developpement propres a Android. Traitez ces elements comme des affirmations fournisseur jusqu'a ce que votre propre route produise des preuves.

Les Android skills ne sont pas des prompts generaux. La vue d'ensemble des Android skills de Google les decrit comme des instructions optimisees pour l'IA concernant les schemas de developpement Android. La documentation des skills Android Studio indique que les skills fournissent une expertise a la demande, suivent un standard ouvert et peuvent etre invoquees quand le modele decide qu'elles correspondent a une requete. Cela fait d'une skill un artefact inspectable. Un relecteur peut la lire, la versionner et demander si elle correspond aux pratiques Android actuelles.

L'article de lancement indique qu'Android Studio inclut 23 skills selectionnees, avec des exemples comme la mise a niveau du Android Gradle Plugin, Android Profiler, Navigation3 et Adaptive. Le depot GitHub public android/skills compte parce qu'il expose les orientations susceptibles de faconner la reponse d'un agent. La skill de mise a niveau AGP 9 est un exemple concret du type d'instruction que les equipes doivent inspecter avant de faire confiance a un diff de migration. Les skills personnalisees etendent ce schema a l'architecture interne, a la politique de dependances, aux attentes de test et aux regles de migration.

L'assistance locale Gemma 4 est une decision distincte. La documentation de Google sur les modeles locaux indique qu'Android Studio peut utiliser un modele execute sur la machine du developpeur, tout en avertissant que les capacites varient et que certaines fonctions peuvent ne pas se comporter comme prevu avec des modeles externes. L'article de lancement indique que les plus petits modeles peuvent fonctionner avec 12 Go de RAM et que les machines avec 32 Go de RAM ou plus fonctionnent le mieux. Il indique aussi qu'Android Studio peut telecharger, verifier et mettre a jour les poids du modele. Ces details de configuration sont utiles. Ils ne constituent pas une preuve d'acceptation. Un pilote a encore besoin de la classe de machine, de la marge de RAM, de la taille du projet, du mode de modele choisi, des limites fonctionnelles et de la charge de ressources observee.

Voici la vision pratique : l'assistance locale au codage est un probleme de gouvernance avant d'etre une histoire de productivite. La stabilite de l'IDE repond a la question de savoir si l'outil est pret a etre installe. La justesse de la route d'IA demande si le chemin allant du brief de tache au correctif peut etre fiable pour un type de travail precis.

Les sept portes LCRAT

LCRAT evalue la route complete, pas le modele de maniere isolee. La route commence avec le brief de tache et se termine par une decision, appuyee par des journaux, des diffs, des notes de relecteur, des limites canari, des etapes de rollback et des regles d'arret d'utilisation.

Porte 1 : Installation, profilage et preparation au rollback

Consignez la version exacte de Quail 4, le profil du projet, la liste des plugins, les versions Gradle et AGP, la version Kotlin, les dependances d'emulateur et les hypotheses de CI. Sauvegardez les parametres quand c'est la pratique normale. Confirmez si la version precedente d'Android Studio peut etre reinstallee ou utilisee cote a cote. Executez le pilote dans une branche ou un worktree jetable. Si le rollback est vague, arretez-vous la.

Porte 2 : Verification du materiel, du modele et du chemin de confidentialite

Verifiez si le modele local convient aux machines qui l'utiliseront. Capturez la RAM, la classe CPU ou GPU quand c'est pertinent, la taille du projet, la selection de modele et la pression visible sur les ressources. L'execution locale peut traiter certaines preoccupations de chemin de donnees, mais les equipes doivent encore verifier quelles fonctions utilisent quel fournisseur, quelles conditions s'appliquent hors mode local et quelles fonctions Android Studio se comportent differemment avec des modeles locaux.

Porte 3 : Precision de selection des skills et resistance aux API obsoletes

Une liste de skills selectionnees ne prouve pas que la bonne skill a ete utilisee. Pour chaque tache, enregistrez le brief de tache, les references de skill et toute preuve d'invocation visible. Verifiez si la sortie suit les API Android actuelles, les schemas Gradle et l'architecture de l'equipe. Incluez des taches qui tendent a exposer les conseils obsoletes, comme les migrations de dependances, les changements Navigation, le comportement de mise en page Compose ou les repetitions de mise a niveau AGP.

Porte 4 : Parite des taches entre route locale et route de controle

Comparez la route locale a une route de controle quand la politique l'autorise. Le controle peut etre uniquement humain, un assistant cloud approuve ou les deux. Utilisez le meme brief de tache. Comparez les diffs, la sortie de build, les tests affectes, la sortie lint, les notes de migration, les demandes de changement du relecteur et l'adequation a la politique. Le but n'est pas de couronner un gagnant. Il est d'apprendre quelles classes de taches sont acceptables.

Porte 5 : Preuves de correctif et de verification

Pas d'artefacts, pas de validation. Un correctif genere doit etre assez petit pour etre relu, lie a une branche et appuye par des journaux. Au minimum, capturez la sortie du build Gradle, la sortie des tests unitaires, la sortie Android lint et les controles propres a la migration quand ils sont pertinents. Pour le travail AGP ou de dependances, incluez la configuration avant et apres ainsi que les references aux notes de version.

Porte 6 : Confinement des commandes destructrices et approbation humaine

Les agents locaux peuvent tout de meme effectuer du travail risque. Les reecritures larges, mises a niveau de dependances, suppressions de fichiers, migrations generees, manipulations d'identifiants, changements de deploiement et commandes shell necessitent une approbation explicite. Utilisez des executions a blanc lorsque c'est possible. Gardez les diffs visibles. Si la route tente des commandes non sures ou cache des changements importants dans un grand correctif, mettez-la en pause.

Porte 7 : Criteres de canari, rollback et arret d'utilisation

L'approbation doit etre etroite. Acceptez la route pour une classe de taches comme le nettoyage lint, un petit refactor d'UI avec tests ou une repetition de mise a niveau AGP. Ne l'acceptez pas pour toute l'ingenierie Android. Definissez le perimetre canari, les commandes de rollback, les exclusions de taches et les declencheurs d'arret d'utilisation avant que les developpeurs ne s'y fient.

Une matrice de decision pour les equipes Android

Utilisez cette matrice pour choisir la premiere route pilote. Les libelles sont volontairement qualitatifs. Remplacez-les par vos propres preuves apres le pilote.

L'assistance locale gagne souvent son premier pilote sur un travail etroit avec de bons tests et un vrai besoin d'execution locale. Une route cloud ou de controle reste utile pour la comparaison quand le probleme est large et que la politique le permet. Aucune route ne doit posseder le travail sur les secrets, les changements de deploiement destructeurs, les decisions d'architecture ambigues ou les taches sans chemin de rollback.

Preuves a conserver avec la pull request

LCRAT echoue si l'acceptation ne vit que dans le chat. Conservez le dossier de preuves avec le ticket, la branche ou la pull request afin que le relecteur puisse l'inspecter plus tard.

{
  "framework": "LCRAT",
  "route": "android-studio-quail-4-gemma-4-local",
  "gates": ["installRollback", "hardwarePrivacy", "skillAccuracy", "routeParity", "buildTestLint", "approvalContainment", "canaryRollbackStopUse"],
  "recommendedDecisionValues": ["accept_limited", "accept_with_controls", "defer", "reject"],
  "requiredArtifacts": ["versionInventory", "skillRefs", "patchDiff", "buildLog", "testLog", "lintLog", "reviewDecision", "rollbackPlan"],
  "excludedTaskClasses": ["secrets", "deployment", "destructiveOps", "untestedBroadRefactor"],
  "stopUseTriggers": ["repeatedBuildFailure", "staleApiRecurrence", "unsafeCommandAttempt", "unreviewableDiff", "policyMismatch"]
}

Ce JSON n'est qu'un index. La preuve est le diff reel, les journaux, la decision du relecteur, la limite canari et la note de rollback.

Executer un pilote LCRAT Quail 4 reproductible

Commencez avec un depot, une branche ou un worktree non critique. Consignez la version Quail 4 et la version precedente fonctionnelle de l'IDE. Lisez l'article de lancement officiel, la mise a jour de publication, les notes de version, les problemes connus, les documents Android skills, les documents sur les modeles locaux et les fichiers pertinents du depot public de skills. Confirmez le package de rollback, la sauvegarde des parametres, la compatibilite des plugins, l'isolation de branche, la reference CI, la marge de RAM et le comportement observe du modele local.

Choisissez trois a cinq taches proches de la production mais contenues. De bons candidats incluent une repetition de mise a niveau AGP, un petit refactor d'UI couvert par des tests, un nettoyage lint, une investigation d'avertissement de dependance et une petite migration d'API. Redigez un brief de tache par tache avant que l'assistant ne commence. Chaque brief doit nommer les controles attendus et les exclusions.

Executez la route locale et la route de controle depuis le meme brief quand la politique l'autorise. Capturez les briefs de tache, les skills selectionnees, les diffs generes, la sortie Gradle, la sortie des tests unitaires, la sortie Android lint, les notes de migration, les commentaires du relecteur et le nettoyage manuel. Terminez chaque pilote avec une decision : accepter pour une classe de taches limitee, accepter avec controles, differer ou rejeter. Nommez la classe de taches, le type de depot, les controles requis, les taches exclues, les points d'approbation, le perimetre canari, le plan de rollback et les declencheurs d'arret d'utilisation.

Erreurs courantes

Erreur 1 : traiter la disponibilite du modele comme une approbation de route

Un modele peut etre disponible, hors ligne et agreable a utiliser tout en produisant des correctifs qui echouent aux controles ou exigent un nettoyage important. La disponibilite lance l'evaluation. Elle ne la termine pas.

Erreur 2 : faire confiance aux noms de skills sans preuve

Une skill appelee mise a niveau AGP n'aide que si elle est selectionnee pour la bonne tache et si son orientation correspond a la cible de migration. Inspectez la skill, conservez sa source et relisez le diff obtenu.

Erreur 3 : ignorer les API obsoletes et les cas limites de migration

Les API Android, le comportement Gradle, la configuration Kotlin et les schemas de bibliotheques continuent d'evoluer. Votre pilote doit inclure des taches concues pour exposer les suggestions depassees avant que la route ne touche les branches de production.

Erreur 4 : sauter les regles de rollback et d'arret d'utilisation

Le rollback fait partie de l'hygiene de livraison. Si la route ne peut pas etre mise en pause apres des commandes non sures, des echecs de build repetes ou des diffs impossibles a relire, elle n'est pas gouvernee.

Erreur 5 : mesurer la commodite au lieu de la qualite de merge

La satisfaction des developpeurs est un retour utile, mais elle ne suffit pas. Mesurez les correctifs acceptes, les controles repetables, la confiance des relecteurs, les changements annules et le fait que la route reste dans les limites de taches approuvees.

Reserves et plan de mesure

L'adoption d'un modele local implique des compromis. La configuration prend du temps. Le materiel varie. Le comportement du modele change selon la machine, la taille du projet, le prompt et la tache. L'interpretation de la confidentialite depend du chemin fournisseur exact et de la fonction utilisee. Les skills peuvent deriver. Les tests peuvent manquer des comportements. Les relecteurs peuvent se fatiguer lorsque les diffs semblent plausibles mais necessitent des corrections repetees.

Utilisez des metriques qui n'exigent pas d'inventer des affirmations de ROI.

Arretez ou restreignez la route lorsque les echecs de build se repetent, les suggestions d'API obsoletes reviennent, des tentatives de commandes non sures apparaissent, les diffs deviennent difficiles a relire, les erreurs de migration persistent, l'adequation a la politique n'est pas claire ou des problemes connus affectent le projet cible.

Android Studio Quail 4 merite l'attention des equipes Android qui evaluent l'assistance locale et les workflows agentiques guides par skills. La bonne posture consiste a commencer par les preuves : installer prudemment, comparer les routes honnetement, conserver les artefacts et approuver seulement les classes de taches qui survivent a la relecture.