I migliori piattaforme CI/CD per app Android del 2026, confrontate

La migliore piattaforma CI/CD per app Android è spesso quella che già esegui, perché le build Android richiedono solo Linux, Java, l'Android SDK e Gradle. Le differenze tra le piattaforme si manifestano durante la build: come archiviano il tuo keystore, come caricano i tracciati di Google Play, quanto velocemente il caching di Gradle rende le ripetute build, e se la stessa piattaforma gestisce anche iOS. Questa comparazione copre GitHub Azioni, GitLab CI, Bitrise, Codemagic, Appcircle, CircleCI, Azure DevOps e Capgo Build.

Il flusso di rilascio Android nel 2026

Tutti i pipeline Android fanno più o meno la stessa cosa:

1. Installa un JDK e l'Android SDK (o utilizza un'immagine che li contiene).
2. Avvia ./gradlew bundleRelease.
3. Firma l'AAB con il tuo carica chiave.
4. Carica il tuo pacchetto su un tracciato del Console di Gioco (interno, chiuso, aperto o di produzione) attraverso il Google Play Developer API.
5. Rilascia optionalmente a un percentuale di utenti.

Opzionalmente distribuisci a un percentuale di utenti.

• Regole che ogni piattaforma deve rispettare: su Google Play, e Google riassegna gli APK consegnati con la chiave di firma dell'applicazione che possiede (Play App Signing).
• Livello di destinazione API aumenta ogni anno. Il livello di __CAPGO_KEEP_0__ aumenta ogni anno. targetSdkVersion per aggiornamenti ogni agosto. Capacitor 8 già mira a API 36.
• 16 KB di dimensione pagina. Nuovi dispositivi utilizzano pagine di memoria da 16 KB e Play richiede librerie native aggiornate negli app per supportarle. Vedere Dimensione pagina Android 16 KB per plugin Capacitor.
• JDK 21 è il punto di riferimento per Capacitor 7 e 8 e versioni recenti del plugin Android Gradle.

Tavola dei caratteri

Xcode Cloud non è nella tabella perché costruisce solo piattaforme Apple. Capgo Build costruisce solo app Capacitor; ogni altra piattaforma qui costruisce anche progetti nativi Kotlin e Java.

Piattaforma per piattaforma

GitHub Azioni

Runner Linux con Java e l'SDK Android preinstallato su ubuntu-latestcosì ./gradlew bundleRelease funziona dopo actions/setup-java. gradle/actions/setup-gradle gestisce bene il caching di Gradle. I test dell'emulatore eseguiscono su Linux runner con KVM attraverso azioni della community come reactivecircus/android-emulator-runner.

Firma significa decodificare il keystore da un segreto e passare le password attraverso le proprietà di Gradle. L'upload utilizza fastlane supply, il plugin di pubblicazione di Gradle per Play o un'azione della community. Niente è gestito, ma niente è nascosto neanche, e i minuti di Linux sono i più economici che troverai. Guida: Costruzione automatica di Capacitor Android con GitHub Actions.

GitLab CI

La stessa storia su GitLab: qualsiasi immagine Docker con l'Android SDK funziona su runner Linux condivisi. Le caratteristiche di DevOps mobili di GitLab includono file sicuri per i keystore e un'integrazione di Google Play che esporre il servizio account ai job, che elimina alcune righe di codice da fastlane. Guida: Costruzione automatica di Capacitor Android su GitLab.

Bitrise

La supporto Android di Bitrise si concentra su passaggi: Costruzione Android, Sign Android, Deploy Google Play, più passaggi di test e emulator. I keystore vengono caricati una volta nelle impostazioni di firma dell'app code. Il passaggio di Deploy Google Play supporta le tracce e le frazioni di rilascio in fase di staging. Si paga in crediti, quindi i costruzioni Android sono più economici rispetto a iOS ma ancora più costosi di un runner Linux crudo. Buono per le squadre mobili che vogliono un editor di workflow guidato da interfaccia utente.

Codemagic

Codemagic memorizza le chiavi di sicurezza come riferimenti denominati che codemagic.yaml non compare mai il file nel tuo repository o nei log. google_play publishing block sets the track, rollout fraction, and whether to submit as draft. It builds native Android, Flutter, React Native, Ionic, and Capacitor. Billing is per build minute or a fixed annual plan.

Appcircle

Appcircle stores keystores in its signing identities module and publishes to Google Play through its publish flow, alongside tester distribution and an enterprise app store. The self-hosted Appcircle Server option is the main reason regulated teams pick it: code and keys never leave their network.

CircleCI

CircleCI pubblica cimg/android Docker images with the SDK installed, plus an Android orb with helpers for emulator tests and caching. Signing and upload are scripts or fastlane. Billing uses credits, and Linux Docker executors are the cheapest resource classes. A reasonable choice when CircleCI already runs the rest of your stack.

costruire

Azure Pipelines dispone di attività di prima parte per ogni passo: Gradle@3 costruire AndroidSigning@3 Circolo CI pubblica immagini Docker con l'__CAPGO_KEEP_0__ installato, più un'orbita Android con aiuti per i test dell'emulatore e il caching. La firma e l'invio sono script o fastlane. La fatturazione utilizza crediti e i classi di risorse Docker Linux eseguono l'esecuzione più economica. Una scelta ragionevole quando Circolo CI già esegue il resto della tua pila.

Capgo Build

Capgo Build è un servizio di build per Capacitor app che il tuo CI chiama. Il lavoro esegue bun run build e bunx cap sync android, quindi

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

Capgo esegue Gradle sul suoi macchinari di costruzione, firma con il tuo keystore, legge il più alto versionCode dal Google Play e lo incrementa, e carica l'AAB sul tracciato che hai scelto. --android-release-status, --android-flavor, e --submit-to-store-review controlla il resto. Per le costruzioni APK fuori dal Google Play (dispositivi kiosk, MDM), --no-playstore-upload --output-upload ritorna un link di download al posto.

La configurazione è guidata: bunx @capgo/cli@latest build init --platform android crea o importa la chiave di sicurezza, e può provvedere al servizio account di Google Cloud e all'invito al Console di gioco attraverso l'accesso di Google, che è lo step che più spesso le squadre fanno male a mano.

To essere onesti: Android è la piattaforma dove Capgo Build risparmia il meno, perché i runner Linux sono economici in ogni parte del mondo. Il suo valore su Android è la consistenza con il flusso di lavoro di iOS, i codici di versione automatici, nessuna SDK o manutenzione di JDK in CI, e lo stesso CLI di spedizione aggiornamenti in tempo reale per modifiche esclusivamente web. Un singolo build è limitato a 10 minuti.

Punti deboli di Android e come ogni piattaforma gestisce questi problemi

Pertinenza della chiave di sicurezza

Perdere la chiave di sicurezza utilizzata a un certo punto significava che non si poteva più aggiornare l'app. Con Play App Signing, la chiave di sicurezza che si tiene è solo la chiave di caricamento e il supporto di Play Console può registrare una nuova chiave di caricamento. Comunque, conservare un backup offline. Ogni piattaforma sopra conserva la chiave di sicurezza crittografata; il rischio è generalmente la copia su un laptop del developer. Se si ha bisogno di una nuova chiave, il generatore di chiave di sicurezza Android crea una nuova chiave nel browser.

Collisioni di versione code

Play rifiuta un caricamento il cui versionCode era già stato utilizzato. Option: derivarlo dalla numero di esecuzione di CI (GitHub, GitLab, CircleCI), utilizzare la variabile di build del piattaforma (Bitrise, Codemagic, Appcircle), o lasciare che Capgo Build legga il valore più recente da Play e lo incrementi.

Costruzioni Gradle lente

A un Capacitor build Android freddo scarica centinaia di megabyte di dipendenze. Caching ~/.gradle/caches e ~/.gradle/wrapper rende i build ripetuti molto più veloci. Dà a Gradle abbastanza memoria nei gradle.properties (org.gradle.jvmargs=-Xmx4g) sui runner ospitati, e costruisci iOS e Android in job paralleli invece di uno dopo l'altro.

Plugin e AGP aggiornamenti

Le nuove versioni del Plugin Android Gradle rompono gli plugin più vecchi. Blocca AGP nel tuo progetto e aggiorna in una branch. Le soluzioni specifiche sono in Risolve gli errori di build del plugin Capacitor con AGP 9 e Come risolvere gli errori di build Android in Capacitor.

Permessi dell'account Play service

“L'invocatore non ha i permessi” è l'errore di caricamento più comune. L'account del servizio deve essere invitato in Play Console sotto Utenti e permessi con diritti di rilascio per l'app, e il Google Play Android Developer API deve essere abilitato nel suo progetto Cloud di Google. Gli account del servizio nuovi possono richiedere un po' di tempo prima che il API li accetti.

Come scegliere

Per la parte iOS della stessa decisione, leggi Comparare le piattaforme CI/CD per gli app iOS. Per le Capacitor app in particolare, comprese le aggiornamenti in tempo reale, vedi Comparare le piattaforme CI/CD per le Capacitor app.

Una rapida checklist prima di migrare

• Assicurati di avere il file del keystore di caricamento e le due password, e che l'alias corrisponda.
• Controlla nel Console di Gioco quale certificato è registrato come chiave di caricamento e confronta il suo SHA-1 con keytool -list -v -keystore release.jks.
• Crea un account di servizio dedicato per la nuova CI al posto di riutilizzare uno personale.
• Assicurati che la nuova piattaforma costruisca con JDK 21 per i progetti Capacitor 8.
• Esegui un caricamento di traccia interna prima di passare alle rilasci di produzione.