Android Gradle Plugin 9.4 : fiabiliser vos builds avant le blocage

Android Gradle Plugin 9.4 n’est pas une refonte spectaculaire : c’est surtout un signal utile pour les équipes qui livrent une application Android avec plusieurs variantes. En clarifiant les prérequis de build et en détectant certaines incohérences avant qu’elles ne cassent une livraison, cette version aide à transformer une dette de configuration en plan de travail maîtrisé.

Pourquoi une variante de build est un enjeu produit

Une variante combine généralement un environnement, une marque, un pays ou une offre. Elle permet par exemple de tester une version interne, de publier une version de production et de proposer des fonctionnalités optionnelles. Cette souplesse devient risquée lorsque l’application principale et un module dynamique ne déclarent plus les mêmes dimensions : un écran peut être disponible dans un build et absent dans un autre, ou une intégration ne se révéler qu’au moment de la publication.

Le coût n’est pas seulement technique. Une erreur découverte à la veille d’une mise en ligne mobilise l’équipe, déplace la recette et rend le calendrier commercial moins fiable. Le bon objectif n’est donc pas d’avoir le plus grand nombre de variantes, mais de pouvoir expliquer précisément lesquelles sont livrées, testées et supportées.

Android Gradle Plugin 9.4 rend l’écart visible

La note officielle d’Android indique qu’AGP 9.4 vérifie la parité stricte des dimensions de flavors entre l’application Android et ses modules de fonctionnalités dynamiques. Les dimensions manquantes, supplémentaires ou différentes sont signalées comme avertissements. L’équipe peut choisir de les traiter immédiatement comme des erreurs avec l’option dédiée, plutôt que d’attendre une rupture dans sa chaîne de livraison.

Cette période est précieuse : à partir d’AGP 10, cette parité sera imposée et les écarts deviendront bloquants par défaut. Ce n’est pas une raison de mettre à jour dans l’urgence ; c’est une occasion de rendre la configuration observable, de décider des exceptions réellement utiles et de planifier la migration dans un cycle normal.

Des prérequis à vérifier avant la mise à jour

AGP 9.4 prend en charge l’API Android 37 et documente Gradle 9.6 ainsi que JDK 17 comme versions par défaut. Ces chiffres ne remplacent pas une vérification dans votre dépôt : plugins, bibliothèques de build, CI et postes de développement doivent rester alignés. Une mise à niveau réussie est reproductible sur la machine du développeur comme dans le pipeline qui produit l’artefact distribué.

Une méthode courte pour réduire le risque

1. Cartographier les variantes réellement livrées : application principale, modules dynamiques, flavors et environnements.
2. Mettre AGP 9.4 à l’essai dans une branche dédiée, avec la même version de Gradle et de JDK que la CI.
3. Lire les avertissements de parité et corriger les écarts qui ne correspondent à aucune décision produit explicite.
4. Promouvoir progressivement le contrôle en erreur lorsque les modules sont alignés, puis exécuter les tests de parcours critiques sur les variantes concernées.
5. Conserver une matrice de livraison concise : variantes, audience, tests effectués et responsable de la décision.

Ne pas confondre mise à jour et sécurité de publication

La compatibilité du build n’atteste pas, à elle seule, qu’une application est prête pour les utilisateurs. Il faut aussi vérifier la signature, les services externes, les droits, la régression fonctionnelle et la distribution. Cette distinction est particulièrement importante alors qu’Android fait évoluer la vérification des développeurs : la préparation de la distribution Android et la qualité de la chaîne de build sont deux chantiers complémentaires.

La documentation officielle d’Android Studio pour AGP 9.4, mise à jour le 1er septembre 2026, détaille les compatibilités, l’opt-out temporaire de la nouvelle Variant API et les contrôles de parité.