Comparatif des meilleures plateformes CI/CD pour les apps Android en 2026

La meilleure plateforme CI/CD pour les apps Android est souvent celle que vous utilisez déjà, car les builds Android ne nécessitent que Linux, Java, le SDK Android et Gradle. Les différences entre plateformes apparaissent autour du build : la gestion de votre keystore, l'upload vers les tracks Google Play, la rapidité du cache Gradle sur les builds récurrents, et la capacité de la plateforme à gérer aussi iOS. Ce comparatif couvre GitHub Actions, GitLab CI, Bitrise, Codemagic, Appcircle, CircleCI, Azure DevOps et Capgo Build.

Le cycle de release Android en 2026

Chaque pipeline Android fait sensiblement la même chose :

1. Installer un JDK et l'SDK Android (ou utiliser une image qui les contient).
2. Exécuter ./gradlew bundleRelease.
3. Signer l'AAB avec votre clé d'upload.
4. L'envoyer vers un canal de la Play Console (interne, fermé, ouvert ou production) via l'API Google Play Developer.
5. Déployez optionnellement auprès d'un pourcentage d'utilisateurs.

Les règles que chaque plateforme doit respecter :

• L'AAB est obligatoire pour les nouvelles apps sur Google Play, et Google signe à nouveau les APK livrés avec la clé de signature d'application qu'il détient (Play App Signing).
• Le niveau cible API augmente chaque année. Google augmente le minimum targetSdkVersion pour les mises à jour chaque août. Capacitor 8 cible déjà API 36.
• Tailles de page de 16 Ko. Newer devices use 16 KB memory pages, and Play requires native libraries in updated apps to support them. See Taille de page Android de 16 Ko pour les plugins Capacitor.
• JDK 21 est la base pour les projets Capacitor 7 et 8 ainsi que pour les versions récentes d'Android Gradle Plugin.

Matrice de fonctionnalités

Xcode Cloud n'est pas dans le tableau car il ne compile que les plateformes Apple. Le build Capgo ne compile que les applications Capacitor ; toutes les autres plateformes ici compilent aussi des projets natifs Kotlin et Java.

Plateforme par plateforme

Actions GitHub

Des runners Linux avec Java et l'SDK Android préinstallé sur ubuntu-latest, donc ./gradlew bundleRelease fonctionne après actions/setup-java. gradle/actions/setup-gradle gère bien le cache Gradle. Les tests sur émulateur s'exécutent sur des runners Linux avec KVM via des actions communautaires comme reactivecircus/android-emulator-runner.

La signature consiste à décoder le keystore depuis un secret et à transmettre les mots de passe via les propriétés Gradle. L'upload utilise fastlane supply, le plugin Gradle Play Publisher, ou une action communautaire. Rien n'est géré, mais rien n'est caché non plus, et les minutes Linux sont les moins chères du marché. Guide : Build Android Capacitor automatique avec GitHub Actions.

GitLab CI

Même histoire sur GitLab : n'importe quelle image Docker avec l'SDK Android fonctionne sur des runners Linux partagés. Les fonctionnalités Mobile DevOps de GitLab incluent des fichiers sécurisés pour les keystores et une intégration Google Play qui expose le compte de service aux jobs, ce qui réduit le code répétitif dans les configurations fastlane. Guide : Build Android Capacitor automatique sur GitLab.

Bitrise

Le support Android de Bitrise repose sur des étapes : Android Build, Android Sign, Google Play Deploy, ainsi que des étapes de test et d'émulateur. Les keystores sont uploadés une seule fois dans les paramètres de signature code de l'app. L'étape Google Play Deploy prend en charge les canaux et les fractions de déploiement progressif. Vous payez en crédits, donc les builds Android sont moins chers que sur iOS, mais restent plus coûteux qu'un runner Linux brut. Idéal pour les équipes mobiles qui souhaitent un éditeur de workflow piloté par l'UI.

Codemagic

Codemagic stocke les keystores sous forme de références nommées qui codemagic.yaml pointe vers, de sorte que le fichier n'apparaît jamais dans votre dépôt ou vos logs. Le google_play bloc de publication définit la piste, la fraction de déploiement progressif et s'il faut soumettre en brouillon. Il compile Android natif, Flutter, React Native, Ionic et Capacitor. La facturation se fait à la minute de build ou via un plan annuel fixe.

Appcircle

Appcircle stocke les keystores dans son module d'identités de signature et publie sur Google Play via son flux de publication, avec la distribution aux testeurs et un store d'entreprise. L'option Appcircle Server auto-hébergée est la principale raison pour laquelle les équipes réglementées le choisissent : code et les clés ne quittent jamais leur réseau.

CircleCI

CircleCI publie cimg/android des images Docker avec SDK installé, plus un orb Android avec des helpers pour les tests sur émulateur et la mise en cache. La signature et l'upload passent par des scripts ou fastlane. La facturation utilise des crédits, et les exécuteurs Docker Linux sont les classes de ressources les moins chères. Un choix raisonnable si CircleCI fait déjà tourner le reste de votre stack.

Azure DevOps

Azure Pipelines propose des tâches officielles pour chaque étape : Gradle@3 pour le build, AndroidSigning@3 pour signer et zipalign, sécuriser les fichiers du keystore, et utiliser la tâche de release de l'extension Google Play pour les uploads de canaux et les déploiements progressifs. Le tarif est par job parallèle. C'est la solution idéale pour les équipes qui utilisaient les builds Android d'App Center.

Capgo Build

Capgo Build est un service de build pour les apps Capacitor appelé par votre CI. Le job s'exécute bun run build et bunx cap sync android, puis :

bunx @capgo/cli@latest build request com.example.app \
  --platform android \
  --build-mode release \
  --android-track internal

Capgo exécute Gradle sur ses machines de build, signe avec votre keystore, lit la version la plus élevée versionCode depuis le Play Store et l'incrémente, puis envoie l'AAB vers le canal choisi. --android-release-status, --android-flavor, et --submit-to-store-review contrôler le reste. Pour les builds APK hors Google Play (bornes, MDM), --no-playstore-upload --output-upload renvoie un lien de téléchargement à la place.

La configuration est guidée : bunx @capgo/cli@latest build init --platform android crée ou importe le keystore, et peut provisionner le compte de service Google Cloud et l'invitation Play Console via Google sign-in, l'étape que la plupart des équipes ratent lorsqu'elles le font manuellement.

Pour être honnête : Android est la plateforme où Capgo Build apporte le moins d'économies, car les runners Linux sont peu coûteux partout. Sa valeur sur Android réside dans la cohérence avec le pipeline iOS, l'automatisation des version codes, l'absence de gestion du SDK Android ou du JDK dans la CI, et le même processus de CLI pour la livraison live updates pour les changements web uniquement. Un build unique est limité à 10 minutes.

Points de friction sur Android et gestion par chaque plateforme

Perte du keystore

Perdre le keystore signifiait autrefois qu'il était impossible de mettre à jour l'app. Avec Play App Signing, le keystore que vous détenez n'est que la clé d'upload, et le support Play Console peut enregistrer une nouvelle clé. Gardez tout de même une sauvegarde hors ligne. Toutes les plateformes citées ci-dessus stockent le keystore chiffré ; le risque vient généralement de la copie sur l'ordinateur d'un développeur. Si vous en avez besoin d'un nouveau, générateur de keystore Android le crée directement dans le navigateur.

Collisions de version code

Play rejette un upload dont le versionCode a déjà été utilisé. Options : dériver le code du numéro de run de la CI (GitHub, GitLab, CircleCI), utiliser la variable de numéro de build de la plateforme (Bitrise, Codemagic, Appcircle), ou laisser Capgo Build lire la dernière valeur de Play pour l'incrémenter.

Builds Gradle lents

Un build Android Capacitor à froid télécharge des centaines de mégaoctets de dépendances. Le cache ~/.gradle/caches et ~/.gradle/wrapper rend les builds répétitifs bien plus rapides. Donnez suffisamment de mémoire à Gradle dans gradle.properties (org.gradle.jvmargs=-Xmx4g) sur des runners hébergés, et compilez iOS et Android via des jobs parallèles plutôt que l'un après l'autre.

Mises à jour des plugins et de l'AGP

New Android Gradle Plugin versions break older plugins. Pin AGP in your project and upgrade on a branch. Specific fixes are in Corriger les erreurs de build du plugin Capacitor avec AGP 9 et Comment résoudre les erreurs de build Android dans Capacitor.

Permissions du compte de service Play

« The caller does not have permission » est l'erreur d'upload la plus courante. Le compte de service doit être invité dans la Play Console sous Utilisateurs et permissions avec des droits de release pour l'app, et l’API Google Play Android Developer doit être activé dans son projet Google Cloud. Les nouveaux comptes de service peuvent mettre un certain temps avant que l’API ne les accepte.

Comment choisir

Pour le côté iOS de cette même décision, lisez Comparaison des plateformes CI/CD pour les apps iOS. Pour les apps Capacitor spécifiquement, incluant les live updates, consultez Comparaison des plateformes CI/CD pour les apps Capacitor.

Une checklist rapide avant votre migration

• Confirmez que vous avez le fichier keystore pour l'upload, les deux mots de passe, et que l'alias correspond.
• Vérifiez dans la Play Console quel certificat est enregistré comme clé d'upload, et comparez son SHA-1 avec keytool -list -v -keystore release.jks.
• Créez un compte de service dédié pour la nouvelle CI au lieu de réutiliser un compte personnel.
• Assurez-vous que la nouvelle plateforme build avec JDK 21 pour les projets Capacitor 8.
• Effectuez un upload sur un canal interne avant de basculer les releases en production.