Si votre Capacitor plugin a commencé à échouer après avoir mis à niveau vers Android Gradle Plugin 9 (AGP 9), vous êtes probablement confronté à une petite mais critique erreur de configuration Gradle.
Ce billet cible spécifiquement les intentions de recherche courantes comme :
- Capacitor erreur de construction du plugin AGP 9
- Le plugin de construction d'Android Gradle 9 a échoué
proguard-android.txtnon trouvé- AGP 9
getDefaultProguardFileerreur - Capacitor La construction Android a échoué après la mise à jour d'AGP
La version courte :
proguard-android.txtn'est plus la référence de base sécurisée par défaut à utiliser dans les builds de plugins AGP 9.- Passer à
proguard-android-optimize.txt. - Reconstruire et vérifier.
The longer version matters too, especially if you maintain many plugins or large Capacitor workspaces. In this article we cover:
- Quels sont Android et AGP dans la chaîne de construction
- What Capacitor is and how plugin builds work
- What Capgo est et pourquoi cela compte pour la fiabilité des mises à jour
- Le changement exact d'AGP 9 qui brise les anciens modèles de plugins
- Une stratégie de migration sûre pour un seul dépôt ou plusieurs dépôts
Qu'est-ce que Android dans ce contexte
Android C'est à la fois un système d'exploitation et un écosystème de build. Lorsque vous envoyez un Capacitor app ou plugin sur Android, votre projet passe par :
- Gradle comme système de construction
- Plugin Gradle Android pour Android (AGP) comme intégration Gradle spécifique à Android.
- L’outilchain Android SDK pour la mise en boîte, la compression, la vérification de l'intégrité et la production
.aar,.apk, ou.aaboutputs.
Lorsque les versions d'AGP changent, certaines valeurs par défaut et des fichiers internes peuvent changer également. Une configuration de plugin qui fonctionnait pour AGP 8 peut ne pas fonctionner avec AGP 9 si elle pointe vers une ligne de base supprimée ou obsolète.
Qu'est-ce que Capacitor?
Capacitor Un runtime multiplateforme qui vous permet de créer des applications iOS/Android à partir de web code (TypeScript, JavaScript, HTML, CSS) tout en appelant des APIs natives.
Les applications Capacitor comprennent généralement :
- A web layer (your UI and business logic)
- Les applications __CAPGO_KEEP_0__ comprennent généralement :
ios/,android/) - Les plugins qui exposent des fonctionnalités natives au JavaScript
Chaque plugin a sa propre configuration de construction native. Sur Android, cela signifie que chaque plugin inclut un android/build.gradle fichier que AGP doit analyser et compiler correctement.
Si les paramètres Gradle des plugins sont obsolètes, la construction de l'application entière peut échouer, même si votre web code est correct.
Qu'est-ce que Capgo?
Capgo fournit des outils autour de la livraison et de l'exploitation de Capacitor.
- Mises à jour en direct pour les modifications du paquet web
- Écosystème de plugins et packages de fonctionnalités natives
- Flux de mise à jour CI/CD amicaux pour les équipes de Capacitor
Even with live updates, native build stability is non-negotiable. You still need clean Android builds for:
- Sorties sur l'App Store / Play Store
- Actualisations de plugins natifs
- Migrations de plateforme SDK
- Intégration de l'équipe et fiabilité de CI
C'est pourquoi les correctifs de compatibilité AGP 9 sont importants : ils maintiennent votre couche de plugin fiable, afin que les pipelines de livraison restent prévisibles.
Why AGP 9 breaks older plugin configs
De nombreux modèles de plugin ont historiquement utilisé :
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
Dans les configurations AGP 9, cette référence de base légendaire peut échouer car le fichier ancien n'est plus garanti à l'emplacement attendu par les anciens modèles/configurations.
Les symptômes typiques incluent des erreurs Gradle pendant les assemble, lintou build phases, souvent pointant vers des ressources de ProGuard manquantes ou des références de fichier par défaut invalides.
Contexte rapide : ProGuard, R8 et fichiers de base
- R8 is the modern code shrinker/optimizer in Android builds.
proguard-rules.proest votre projet/plugin personnalisé garder les règles.getDefaultProguardFile(...)injecte une ligne de base fournie par Android.
Lorsque vous référez :
proguard-android.txt-> base de ligne de conduite légacière, minimaleproguard-android-optimize.txt-> optimisation moderne de base (recommandé par défaut dans les configurations actuelles)
Pour la compatibilité avec AGP 9, passer à proguard-android-optimize.txt est la solution pratique.
La solution en une ligne
Update plugin and app module Gradle files:
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
Au minimum, vérifiez :
android/build.gradleen chaque pluginexample-app/android/app/build.gradleen les dépôts de plugins- Tous les fichiers de générateur/template qui créent de nouvelles configurations Gradle de plugin
Guide de migration pour un plugin
1. Trouvez la référence ancienne
rg -n "proguard-android\\.txt" android example-app
2. Remplacez-la
perl -pi -e "s/proguard-android\\.txt/proguard-android-optimize.txt/g" \
android/build.gradle example-app/android/app/build.gradle
3. Vérifiez avec Bun
bun run verify:android
Si votre plugin dispose de scripts de vérification complets, exécutez :
bun run verify
Mise à jour de tous les dépôts de plugins
Si vous gérez de nombreux dépôts de plugins dans un même espace de travail, automatisez-le.
rg -l "proguard-android\\.txt" capacitor-* \
--glob '!**/node_modules/**' \
--glob '!**/.gradle/**' \
--glob '!**/build/**' \
| xargs perl -pi -e "s/proguard-android\\.txt/proguard-android-optimize.txt/g"
Vérifiez ensuite que aucune source de plugin suivie n'utilise toujours le fichier ancien :
for d in capacitor-*; do
[ -d "$d/.git" ] || continue
git -C "$d" grep -n "proguard-android\\.txt" -- || true
done
Aucune correspondance signifie que la référence de base ancienne est disparue des fichiers de plugins suivis.
Capgo statut de déploiement
Nous avons terminé cette migration dans tous les dépôts officiels de plugins et les modèles Capgo Capacitor.
- Les modules Android des plugins référencent désormais
proguard-android-optimize.txt - Les exemples d'applications Android du plugin ont été mis à jour
- Les modèles de création de plugins ont été mis à jour pour que les nouveaux plugins soient par défaut AGP 9-sûrs
Cela empêche une classe courante d'erreurs d'amélioration de AGP 9 avant qu'elles ne frappent la CI.
Pourquoi cela est important même si votre build passe aujourd'hui
Vous ne voyez peut-être pas les erreurs immédiatement si :
- Votre cache CI masque toujours l'issue
- Vous avez des versions AGP mixtes dans les projets
- Seuls certains modules sont reconstruits en développement local
Mais finalement, les builds propres, les environnements nouveaux ou les exécuteurs mis à jour exposent cela. Effectuer la migration maintenant supprime l'instabilité cachée.
Résoudre les problèmes si les builds échouent encore après la remplacement
Vérifiez ces points :
-
Tout module est patché. Examinez les modules de plugin, les modules d'application, les exemples et les actifs de modèle.
-
Il n'y a pas de deuxième référence dans les scripts partagés. Recherchez les dépôtoirs entiers (y compris les scripts Gradle personnalisés).
-
Les caches sont propres. Exécutez et reconstruirez.
./gradlew cleanreconstruire -
Les versions d'AGP / Gradle / JDK sont alignées. Utilisez les combinaisons supportées par la documentation Android pour votre version d'AGP.
-
Vous ne patchez que . Fixez la source du plugin suivi, pas les répertoires de dépendances transitoires.
-
Vous n'êtes pas uniquement en train de patcher.
node_modulesFixez la source du plugin suivi, pas les répertoires de dépendance transitoire.
SEO FAQ: AGP 9 Capacitor plugin build errors
Comment puis-je résoudre proguard-android.txt pas trouvé dans AGP 9 ?
Remplacez :
getDefaultProguardFile('proguard-android.txt')
Par :
getDefaultProguardFile('proguard-android-optimize.txt')
Effectuez ensuite une reconstruction propre.
Pourquoi ma Capacitor plugin de construction échoue-t-elle après avoir mis à niveau vers Android Gradle Plugin 9 ?
Most failures come from legacy Gradle config in plugin android/build.gradle qui référencent toujours proguard-android.txt. Les projets AGP 9 doivent utiliser proguard-android-optimize.txt.
Quel est le chemin de migration AGP 9 le plus rapide pour de nombreux Capacitor plugins ?
Use a workspace-wide search-and-replace command, then validate with git grep et exécutez bun run verify:android sur des plugins représentatifs.
Est-ce que c'est uniquement un problème de Capacitor ?
Non. Toute module Android (application ou bibliothèque) utilisant des références de ProGuard dépréciées dans les fichiers de base peut rencontrer des erreurs de build AGP 9 similaires. C'est particulièrement visible dans les écosystèmes de plugins car de nombreux dépôts partagent des modèles anciens.
Quels mots-clés sont pertinents pour cette migration ?
Si vous documentez cela dans des runbooks internes ou des pages de support, incluez des termes comme :
- Erreur de build AGP 9
- Fichier de ProGuard Android Gradle Plugin 9 manquant
- Capacitor plugin Android build échoué
proguard-android.txtremplacementproguard-android-optimize.txtmigration
Lien connexe
- Developpeurs Android : Résumé de la construction de votre application
- Plugin Gradle Android : Notes de version
- Android code réduction : R8 et règles
- Documentation Gradle : Fondamentaux d'outils de construction
- Capacitor documentation : Documentation officielle
- Capgo docs: Documentation de mise à jour automatique
Conclusion finale
Ce problème AGP 9 est simple, mais il est facile de le manquer dans les environnements de travail multi-plugin. proguard-android.txt avec proguard-android-optimize.txt Les erreurs de build du plugin Capacitor sont résolues partout.
Si vous utilisez des plugins Capgo, cette migration est déjà appliquée dans les dépôts officiels, vous pouvez donc mettre à jour avec moins de surprises.
Continuez de Capacitor Plugin AGP 9 Build Error Fix
Si vous utilisez Capacitor Plugin AGP 9 Build Error Fix pour planifier l'automatisation CI/CD, connectez-l’avec Capgo CI/CD pour le flux de travail du produit dans Capgo CI/CD, Capgo Builds natifs pour le flux de travail du produit dans Capgo Builds natifs, Capgo Intégrations pour le flux de travail du produit dans Capgo Intégrations, Intégration CI/CD pour les détails d'implémentation dans l'intégration CI/CD, et GitHub Intégration d'actions pour les détails d'implémentation dans GitHub Actions d'intégration.