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

La meilleure plateforme CI/CD pour les applications Android est souvent celle que vous utilisez déjà, car les builds Android n’ont besoin que de Linux, de Java, de l’Android SDK et de Gradle. Les différences entre les plateformes apparaissent autour du build : la façon dont elles stockent votre keystore, comment elles envoient vers les pistes Google Play, la rapidité des builds répétés grâce au cache Gradle, et si la même plateforme gère aussi iOS. Cette comparaison couvre GitHub Actions, GitLab CI, Bitrise, Codemagic, Appcircle, CircleCI, Azure DevOps et Capgo Build.

Le workflow de release Android en 2026

Chaque pipeline Android fait sensiblement la même chose :

1. Installer un JDK et le SDK Android (ou utiliser une image qui les contient).
2. Exécutez ./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 progressivement à un pourcentage d'utilisateurs si besoin.

Les règles que chaque plateforme doit respecter :

• L'AAB est obligatoire pour les nouvelles apps sur Google Play, et Google re-signe les APK livrés avec la clé de signature d'application qu'il détient (Play App Signing).
• Le niveau d'API cible augmente chaque année. Google relève le minimum targetSdkVersion pour les mises à jour chaque mois d'août. Capacitor 8 cible déjà API 36.
• Tailles de page de 16 Ko. Les appareils récents utilisent des pages mémoire de 16 Ko, et Play exige que les bibliothèques natives des apps mises à jour les prennent en charge. Voir Taille de page Android de 16 Ko pour les plugins Capacitor.
• JDK 21 est la base pour les projets Capacitor 7 et 8 et pour les versions récentes d'Android Gradle Plugin.

Matrice des fonctionnalités

Xcode Cloud n'apparaît pas dans le tableau car il ne compile que pour les plateformes Apple. Capgo Build ne compile que les applications Capacitor ; toutes les autres plateformes listées ici compilent aussi des projets Kotlin et Java natifs.

Plateforme par plateforme

GitHub Actions GitHub

des runners Linux avec Java et le SDK Android préinstallés ubuntu-latest, donc ./gradlew bundleRelease fonctionne ensuite actions/setup-java. gradle/actions/setup-gradle gère bien le cache Gradle. Les tests sur émulateur tournent 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 à passer les mots de passe via les propriétés Gradle. L’upload passe par 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 chose sur GitLab : n’importe quelle image Docker avec le SDK Android fonctionne sur les 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 élimine une partie du boilerplate des configurations fastlane. Guide : Build Android automatique Capacitor sur GitLab.

Bitrise

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

Codemagic

Codemagic stocke les keystores sous forme de références nommées qui codemagic.yaml pointent vers eux, afin que le fichier n'apparaisse jamais dans votre dépôt ou vos logs. Le google_play bloc de publication définit le canal, la fraction de déploiement progressif et s'il faut soumettre en brouillon. Il compile des builds natifs Android, 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 signing identities 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 de secteurs régulés le choisissent : code et les clés ne quittent jamais leur réseau.

CircleCI

CircleCI publie cimg/android des images Docker avec SDK installé, ainsi qu'un orb Android avec des helpers pour les tests sur émulateur et la mise en cache. La signature et l'upload se font via 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 zipaligner, sécuriser les fichiers du keystore, et exécuter la tâche de release de l’extension Google Play pour les uploads de track et les déploiements progressifs. La facturation est par job parallèle. C’est la destination naturelle des équipes qui utilisaient les builds Android d’App Center.

Build Capgo

Build Capgo est un service de build pour les apps Capacitor que votre CI appelle. 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 et lit la plus versionCode depuis Google Play et l’incrémente, puis envoie l’AAB sur la track que vous avez choisie. --android-release-status, --android-flavor, et --submit-to-store-review contrôler le reste. Pour les builds APK en dehors de Google Play (appareils kiosque, 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 à la main.

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

Points de friction sur Android et comment chaque plateforme les gère

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 ci-dessus stockent le keystore chiffré ; le risque vient généralement de la copie sur l'ordinateur portable d'un développeur. Si vous en avez besoin d'un nouveau, le générateur de keystore Android en ligne le crée dans le navigateur.

Collisions de version code

Play rejette un upload dont le versionCode a déjà été utilisé. Options : le dériver 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 depuis Play et l'incrémenter.

Builds Gradle lents

Un build Android Capacitor à froid télécharge des centaines de Mo de dépendances. Le cache ~/.gradle/caches et ~/.gradle/wrapper accélère nettement les builds répétés. Allouez assez de mémoire à Gradle dans gradle.properties (org.gradle.jvmargs=-Xmx4g) sur des runners hébergés, et lancez les builds iOS et Android dans des jobs parallèles plutôt que l'un après l'autre.

Mises à jour des plugins et de l'AGP

Les nouvelles versions d'Android Gradle Plugin cassent les anciens plugins. Verrouillez AGP dans votre projet et mettez à jour sur une branche. Les correctifs spécifiques sont dans 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 autorisations, avec des droits de publication pour l'app, et l'API Google Play Android Developer doit être activée 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 la partie iOS de la même décision, lisez Comparaison des plateformes CI/CD pour les apps iOS. Pour les apps Capacitor en particulier, y compris les live updates, voir Comparaison des plateformes CI/CD pour les apps Capacitor.

Une checklist rapide avant votre migration

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