storePassword "..." se trouve dans build.gradle, le type de build release est encore signé avec signingConfigs.debug, et targetSdk = 35 n'est plus accepté par Google Play pour les applications de téléphone depuis le 31 août 2026. Cette skill détecte ces erreurs et onze autres erreurs de build de production dans vos fichiers Gradle avant la mise en ligne, et vous explique comment corriger chacune.

Votre agent lance un scanner sur les fichiers build.gradle et build.gradle.kts (modules d'application et de bibliothèque, fichier de build racine, fichiers settings et fichiers partagés comme le variables.gradle de Capacitor), gradle.properties, local.properties, keystore.properties, key.properties et signing.properties, gradle/libs.versions.toml, les fichiers de règles R8 (proguard-rules.pro, consumer-rules.pro, keepRules/*.keep) et les noms des fichiers keystore. Il ignore les commentaires, suit les blocs Gradle comme Gradle les lit (buildTypes { release { } }, getByName("release"), named("release"), android.buildTypes.release...), lit les appels Kotlin DSL dont les arguments sont sur des lignes séparées, suit les valeurs simples définies dans le même fichier (enableProguardInReleaseBuilds de React Native, ext { targetSdkVersion = 33 }), distingue les modules Wear OS, TV, Automotive et XR des applications de téléphone grâce à leurs dépendances, et écarte les fichiers de signature et keystores couverts par un .gitignore. Il fonctionne avec les projets Android Studio, Flutter, React Native, Expo, Capacitor et Kotlin Multiplatform. Il n'exécute jamais Gradle ni votre code. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la publication)

• A01 : storePassword ou keyPassword écrits dans un fichier de build (y compris comme valeur de repli après System.getenv, getOrElse ou orElse), mots de passe de signature dans le gradle.properties du projet, et fichiers keystore.properties, key.properties, signing.properties ou local.properties contenant des mots de passe qu'aucun .gitignore n'exclut
• A02 : debuggable true ou isDebuggable = true dans le type de build release
• A03 : le type de build release signé avec la configuration de signature de débogage, ou une configuration de signature release qui pointe vers debug.keystore (sauf s'il s'agit d'un espace réservé de modèle ou si le projet injecte sa clé de release : voir A18)
• A04 : un targetSdk que Google Play n'accepte plus : inférieur à 34 partout, inférieur à 35 dans les modules Wear OS et Android Automotive OS, inférieur à 36 dans les modules d'application dont les dépendances indiquent une application pour téléphone ou tablette
• A05 : secrets, jetons, mots de passe et clés d'API écrits en clair dans buildConfigField, resValue ou manifestPlaceholders (les clés conçues pour être livrées dans les applications, comme Google Maps, les clés publiables et les clés de SDK d'analyse, ne sont pas signalées)
• A06 : fichiers .jks ou .keystore (ou leurs copies en base64) dans le projet qu'aucun .gitignore n'exclut

REVIEW (à vérifier avant la sortie)

• A11 : R8 désactivé pour le build release d'un module d'application : minifyEnabled false, optimization { enable = false }, ou un bloc release qui ne l'active jamais
• A12 : targetSdk 34 ou 35 là où le format d'appareil ne peut pas être déterminé (bloc ext partagé, variables.gradle, gradle.properties, catalogue de versions)
• A13 : jniDebuggable true dans le type de build release
• A14 : un plugin Android Gradle antérieur à 8.5.1 (sauf si le contournement documenté par packaging hérité est configuré) ou un NDK antérieur à r27, non prêts pour l'exigence de taille de page de 16 Ko de Google Play
• A15 : -dontobfuscate, -dontoptimize, -dontshrink ou règles qui conservent tout dans les fichiers de règles R8, getDefaultProguardFile("proguard-android.txt"), ou android.enableR8.fullMode=false
• A16 : lint checkReleaseBuilds false
• A17 : APK Signature Scheme v2 désactivé sans v3 dans une configuration de signature release
• A18 : la configuration de signature de débogage sur le type de build release servant d'espace réservé : le commentaire TODO ou Caution du modèle se trouve juste au-dessus (Flutter, React Native, Expo), ou le projet injecte sa clé de release via EAS Build ou android.injected.signing

Contenu inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec, pour chaque règle, la raison, l'approche plus sûre et le lien vers la documentation officielle Android
• Un projet d'exemple risqué et un projet sûr, et le rapport réel que le scanner produit sur le projet risqué

Limites

Il lit chaque fichier tel qu'il est écrit : les valeurs définies au moment du build, les accesseurs de catalogue comme libs.versions.targetSdk, les plugins de convention dans buildSrc ou build-logic et flutter.targetSdkVersion ne sont pas suivis, et les product flavors, les types de build personnalisés et la variant API ne sont pas considérés comme le build release. Le format d'appareil est déterminé uniquement à partir des dépendances propres à un module. AndroidManifest.xml et le code source de l'application ne sont pas lus. Un fichier déjà suivi par git reste dans le dépôt même après avoir été ajouté au .gitignore. Les règles sur le SDK cible et les 16 Ko suivent les exigences de Google Play en vigueur en novembre 2026. Les modèles Flutter et React Native signent la release avec la clé de débogage ; c'est signalé en A18 (REVIEW), car un build qui ne reçoit pas de clé de release depuis EAS Build, l'assistant Generate Signed Bundle d'Android Studio ou votre CI est rejeté par Google Play. NOT FLAGGED n'est pas une garantie.

Contenu de l'archive

Un fichier ZIP de 27 fichiers : SKILL.md, le scanner dans scripts/ (7 fichiers Python), references/rules.md (chaque règle avec sa raison et l'approche plus sûre) et examples/ (17 fichiers d'exemple plus report.md, la sortie réelle du scanner sur l'exemple risqué).

Mode d'emploi : Il s'agit d'une skill pour agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-la dans le dossier des skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi seuls avec Python 3.9 ou plus récent, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.