What is the best CI/CD platform for Android apps?

For most teams the CI they already use is enough, because Android builds run on Linux. GitHub Actions, GitLab CI, CircleCI, and Azure DevOps handle Gradle well. Bitrise, Codemagic, and Appcircle add managed keystores and Play publishing. Capacitor teams can call Capgo Build to sign and upload without maintaining an Android toolchain.

Do I need a Mac for Android CI?

No. Android builds run on Linux runners, which are the cheapest runners on every platform. A Mac is only needed for the iOS half of a cross-platform app.

Should CI upload an APK or an AAB to Google Play?

An AAB. Google Play requires Android App Bundles for new apps and signs the final APKs itself with Play App Signing. Build APKs only for direct installs, MDM distribution, or other stores.

Where should I keep the Android keystore for CI?

Base64-encode it into a secret or a secure file on your CI, or use a platform that stores keystores for you. With Play App Signing your keystore is the upload key, so Google can reset it if it leaks, but keep an offline backup anyway.

How do I upload to Google Play from CI?

Create a Google Cloud service account, grant it access in Play Console, and use its JSON key with fastlane supply, the Gradle Play Publisher plugin, a CI integration such as Bitrise or Codemagic publishing, or Capgo Build's Play upload.

Die besten CI/CD-Plattformen für Android-Apps 2026 im Vergleich

Die beste CI/CD-Plattform für Android-Apps ist oft die, die ihr bereits nutzt, denn Android-Builds brauchen nur Linux, Java, das Android SDK und Gradle. Die Unterschiede zwischen den Plattformen zeigen sich beim Build: Wie sie euer Keystore speichern, wie sie zu Google Play-Tracks hochladen, wie schnell Gradle-Caching wiederholte Builds macht und ob dieselbe Plattform auch iOS abdeckt. Dieser Vergleich behandelt GitHub Actions, GitLab CI, Bitrise, Codemagic, Appcircle, CircleCI, Azure DevOps und Capgo Build.

Der Android-Release-Flow in 2026

Jede Android-Pipeline macht im Grunde dasselbe:

Ein JDK und das Android SDK installieren (oder ein Image nutzen, das beides enthält).
Ausführen ./gradlew bundleRelease.
Die AAB mit deinem Key signieren, Upload-Key.
und sie über die Google Play Developer API in einen Play-Console-Track (intern, geschlossen, offen oder Produktion) hochladen.
Optional an einen Prozentsatz der Nutzer ausrollen.

Regeln, die jede Plattform einhalten muss:

AAB ist für neue Apps Pflicht, auf Google Play, und Google signiert die ausgelieferten APKs mit dem hinterlegten App-Signing-Key neu (Play App Signing).
Das Target-API-Level steigt jährlich. Google erhöht die Mindestanforderung targetSdkVersion für Updates jeden August. Capacitor 8 zielt bereits auf API 36 ab.
16-KB-Seitengrößen. Neuere Geräte verwenden 16-KB-Speicherseiten, und Play verlangt, dass native Libraries in aktualisierten Apps sie unterstützen. Siehe Android 16-KB-Seitengröße für Capacitor Plugins.
JDK 21 ist die Basis für Capacitor 7- und 8-Projekte sowie aktuelle Android Gradle Plugin-Versionen.

Feature-Matrix

Plattform	Runners	Keystore-Speicherung	Play-Upload	Gradle-Cache	Auch iOS	Preismodell
GitHub Aktionen	Gehostet Linux, Self-Hosted	Verschlüsselte Secrets	fastlane, Gradle Play Publisher oder Community-Actions	`gradle/actions/setup-gradle`	Ja, macOS-Runner	Pro Minute, Linux am günstigsten; kostenlos für öffentliche Repos
GitLab CI	Hosted Linux, selbst verwaltet	CI/CD-Variablen, sichere Dateien	fastlane, Google Play-Integration	`cache:` Schlüssel	Ja, macOS-Beta	Compute-Minuten pro Plan
Bitrise	Gehostete Linux-Stacks	Verwaltete code Signing-Dateien	Google Play Deploy-Schritt	Integrierte Cache-Schritte	Ja	Credits pro Build-Minute
Codemagic	Gehostetes Linux und Mac	Benannte Keystore-Referenzen	Integriert, Tracking und Rollout-Anteil	Integriert	Ja	Minuten- oder Jahrespläne
Appcircle	Hosted- oder Self-hosted-Server	Signing-Identity-Store	Publish-Modul	Integriert	Ja	Plan-Stufen, Enterprise self-hosted
CircleCI	Hosted Linux (`cimg/android`), self-hosted	Contexts und Env Vars	fastlane oder Scripts	`save_cache`/`restore_cache`	Ja	Credits pro Minute
Azure DevOps	Microsoft-gehostet, selbst gehostet	Sichere Dateien	Google Play-Erweiterungsaufgabe	`Cache@2`	Ja	Parallele Jobs
Capgo Build	Von Capgo verwaltet, aufrufbar aus jeder CI	Pro Build aus Ihren CI-Secrets gesendet	Integriert, Tracking und Status-Flags	Build-Cache pro App	Ja	Build-Minuten, siehe Preise

Xcode Cloud steht nicht in der Tabelle, weil es nur Apple-Plattformen baut. Capgo Build baut ausschließlich Capacitor-Apps; alle anderen Plattformen hier bauen auch native Kotlin- und Java-Projekte.

Plattform für Plattform

GitHub Aktionen

Linux-Runner mit Java und dem Android SDK vorinstalliert auf ubuntu-latest, also ./gradlew bundleRelease funktioniert nach actions/setup-java. gradle/actions/setup-gradle Gradle-Caching funktioniert gut. Emulator-Tests laufen auf Linux-Runnern mit KVM über Community-Actions wie reactivecircus/android-emulator-runner.

Signieren heißt: den Keystore aus einem Secret dekodieren und Passwörter über Gradle-Properties übergeben. Der Upload läuft über fastlane supply, das Gradle-Play-Publisher-Plugin oder eine Community-Action. Nichts wird verwaltet, aber auch nichts versteckt, und Linux-Minuten sind die günstigsten, die es gibt. Guide: Automatisierter Capacitor Android Build mit GitHub Actions.

GitLab CI

Dasselbe bei GitLab: Jedes Docker-Image mit dem Android SDK funktioniert auf geteilten Linux-Runnern. Die Mobile-DevOps-Features von GitLab umfassen Secure Files für Keystores und eine Google-Play-Integration, die den Service Account für Jobs bereitstellt, was etwas Boilerplate aus fastlane-Setups spart. Guide: Automatischer Capacitor Android-Build auf GitLab.

Bitrise

Die Android-Unterstützung von Bitrise basiert auf Steps: Android Build, Android Sign, Google Play Deploy sowie Test- und Emulator-Steps. Keystores werden einmalig in den code-Signing-Einstellungen der App hochgeladen. Der Google Play Deploy Step unterstützt Tracks und gestaffelte Rollout-Anteile. Die Abrechnung erfolgt über Credits, daher sind Android-Builds günstiger als iOS, aber dennoch teurer als ein roher Linux-Runner. Gut für Mobile-Teams, die einen UI-gesteuerten Workflow-Editor wünschen.

Codemagic

Codemagic speichert Keystores als benannte Referenzen, codemagic.yaml auf die verwiesen wird, sodass die Datei nie in deinem Repository oder Logs auftaucht. Der google_play Publishing-Block legt den Track, den Rollout-Anteil und fest, ob als Entwurf eingereicht wird. Es baut native Android-, Flutter-, React-Native-, Ionic- und Capacitor-Apps. Die Abrechnung erfolgt pro Build-Minute oder über einen festen Jahresplan.

Appcircle

Appcircle speichert Keystores in seinem Signing-Identities-Modul und veröffentlicht über seinen Publish-Flow bei Google Play, ergänzt durch Tester-Distribution und einen Enterprise-App-Store. Die selbst gehostete Appcircle-Server-Option ist der Hauptgrund, warum regulierte Teams es wählen: code und Keys verlassen nie ihr Netzwerk.

CircleCI

CircleCI veröffentlicht cimg/android Docker-Images mit installiertem SDK, plus ein Android-Orb mit Helfern für Emulator-Tests und Caching. Signing und Upload laufen über Skripte oder fastlane. Die Abrechnung erfolgt über Credits, und Linux-Docker-Executors sind die günstigsten Resource-Klassen. Eine sinnvolle Wahl, wenn CircleCI bereits den Rest deines Stacks betreibt.

Azure DevOps

Azure Pipelines bietet First-Party-Tasks für jeden Schritt: Gradle@3 zum Build, AndroidSigning@3 zum Signieren und Zipalignen, zum Sichern der Keystore-Dateien sowie für die Release-Aufgabe der Google-Play-Erweiterung für Track-Uploads und gestaffelte Rollouts. Die Abrechnung erfolgt pro parallelem Job. Es ist der natürliche Anlaufpunkt für Teams, die zuvor die Android-Builds von App Center genutzt haben.

Capgo Build

Capgo Build ist ein Build-Service für Capacitor-Apps, den Ihre CI aufruft. Der Job führt aus bun run build und bunx cap sync android, dann:

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

Capgo führt Gradle auf seinen Build-Maschinen aus, signiert mit Ihrem Keystore und liest die höchste versionCode Version von Google Play, erhöht sie und lädt die AAB auf den von Ihnen gewählten Track hoch. --android-release-status, --android-flavor, und --submit-to-store-review den Rest zu steuern. Für APK-Builds außerhalb von Google Play (Kiosk-Geräte, MDM) --no-playstore-upload --output-upload gibt stattdessen einen Download-Link zurück.

Das Setup ist geführte: bunx @capgo/cli@latest build init --platform android erstellt oder importiert den Keystore und kann den Google-Cloud-Service-Account sowie die Play-Console-Einladung per Google Sign-in bereitstellen – der Schritt, den die meisten Teams von Hand falsch machen.

Fairerweise: Android ist die Plattform, auf der Capgo Build am wenigsten spart, weil Linux-Runner überall günstig sind. Der Wert auf Android liegt in der Konsistenz mit der iOS-Pipeline, automatischen Versionscodes, keinem Wartungsaufwand für Android SDK oder das JDK in der CI und demselben CLI-Shipping Live-Updates für reine Web-Änderungen. Ein einzelner Build ist auf 10 Minuten begrenzt.

Android-Pain-Points und wie die einzelnen Plattformen damit umgehen

Keystore-Verlust

Der Verlust des Keystores bedeutete früher, dass man die App nie wieder updaten konnte. Mit Play App Signing ist der Keystore, den du hältst, nur noch der Upload-Key, und der Play-Console-Support kann einen neuen registrieren. Trotzdem: Leg ein Offline-Backup an. Alle oben genannten Plattformen speichern den Keystore verschlüsselt; das Risiko ist meist die Kopie auf dem Laptop eines Entwicklers. Wenn du einen neuen brauchst, Android Keystore Generator erstellt ihn im Browser.

Kollisionen bei Version code

Play lehnt einen Upload ab, dessen versionCode bereits verwendet wurde. Optionen: aus der CI-Run-Nummer ableiten (GitHub, GitLab, CircleCI), die Build-Number-Variable der Plattform nutzen (Bitrise, Codemagic, Appcircle) oder Capgo Build den aktuellen Wert aus Play lesen und hochzählen lassen.

Langsame Gradle-Builds

Ein kalter Capacitor Android-Build lädt Hunderte Megabytes an Abhängigkeiten herunter. Caching ~/.gradle/caches und ~/.gradle/wrapper beschleunigt wiederholte Builds erheblich. Stellen Sie sicher, dass Gradle gradle.properties (org.gradle.jvmargs=-Xmx4g) auf gehosteten Runnern und iOS sowie Android in parallelen Jobs statt nacheinander zu bauen.

Plugin- und AGP-Updates

Neue Android Gradle Plugin-Versionen brechen ältere Plugins. Pinne AGP in deinem Projekt und aktualisiere auf einem Branch. Konkrete Fixes findest du in Capacitor Plugin-Build-Fehler mit AGP 9 beheben und Android Build-Fehler in Capacitor beheben.

Berechtigungen für Play-Servicekonten

„The caller does not have permission“ ist der häufigste Upload-Fehler. Das Servicekonto muss in der Play Console unter „Benutzer und Berechtigungen“ mit Release-Rechten für die App eingeladen werden, und der Google Play Android Developer API muss in seinem Google-Cloud-Projekt aktiviert sein. Neue Servicekonten können eine Weile brauchen, bis der API sie akzeptiert.

Die richtige Wahl treffen

Deine Situation	Ideal geeignet
Nur Android, bereits auf GitHub oder GitLab	GitHub Actions oder GitLab CI
Native Android-Team, das einen visuellen Workflow-Editor will	Bitrise
Cross-Platform-Team, das Managed Keystores und Play-Publishing in YAML möchte	Codemagic
Alles muss selbst gehostet werden	Appcircle Server oder self-hosted Runner
Umstieg von App Center, Microsoft-Stack	Azure DevOps
Capacitor-App: Sie wollen Android und iOS über eine einzige CLI von jeder CI aus	Capgo Build

Für die iOS-Seite derselben Entscheidung lesen Sie CI/CD-Plattformen für iOS-Apps im Vergleich. Speziell für Capacitor-Apps, einschließlich Live Updates, siehe Vergleich von CI/CD-Plattformen für Capacitor-Apps.

Eine kurze Checkliste vor der Migration

Stellen Sie sicher, dass Sie die Upload-Keystore-Datei und beide Passwörter haben und dass der Alias übereinstimmt.
Prüfe in der Play Console, welches Zertifikat als Upload-Schlüssel registriert ist, und vergleiche dessen SHA-1 mit keytool -list -v -keystore release.jks.
Erstelle ein dediziertes Service-Konto für die neue CI, anstatt ein persönliches zu verwenden.
Stelle sicher, dass die neue Plattform mit JDK 21 für Capacitor 8-Projekte baut.
Mach einen Upload im internen Track, bevor du Production-Releases umstellst.