Le migliori piattaforme CI/CD per app Android nel 2026, a confronto

La migliore piattaforma CI/CD per app Android è spesso quella che già utilizzi, poiché le build Android richiedono solo Linux, Java, l'SDK Android e Gradle. Le differenze tra le piattaforme emergono durante la build: come gestiscono il keystore, come effettuano l'upload sui track di Google Play, quanto velocemente la cache di Gradle velocizza le build ripetute e se la stessa piattaforma gestisce anche iOS. Questo confronto copre GitHub Actions, GitLab CI, Bitrise, Codemagic, Appcircle, CircleCI, Azure DevOps e Capgo Build.

Il workflow di rilascio Android nel 2026

Ogni pipeline Android fa più o meno la stessa cosa:

1. Installare un JDK e l'Android SDK (o usare un'immagine che li contenga).
2. Esegui ./gradlew bundleRelease.
3. Firmare l'AAB con il proprio carica chiave.
4. Caricarlo su un track di Play Console (interno, chiuso, aperto o di produzione) tramite il Google Play Developer API.
5. Opzionalmente, distribuirlo a una percentuale di utenti.

Regole che ogni piattaforma deve rispettare:

• L'AAB è obbligatorio per le nuove app su Google Play, e Google firma di nuovo gli APK consegnati con la chiave di firma dell'app che detiene (Play App Signing).
• Il livello API target aumenta ogni anno. Google alza il minimo targetSdkVersion per gli aggiornamenti ogni agosto. Capacitor 8 punta già a API 36.
• Dimensioni di pagina da 16 KB. I dispositivi più recenti usano pagine di memoria da 16 KB, e Play richiede che le librerie native nelle app aggiornate le supportino. Vedi Dimensione di pagina Android 16 KB per i plugin Capacitor.
• JDK 21 è la base per i progetti Capacitor 7 e 8 e per le versioni recenti di Android Gradle Plugin.

Tabella comparativa

Xcode Cloud non è nella tabella perché compila solo per piattaforme Apple. Capgo Build compila solo app Capacitor; tutte le altre piattaforme qui compilano anche progetti nativi Kotlin e Java.

Piattaforma per piattaforma

Azioni GitHub

Linux runner con Java e SDK Android preinstallati su ubuntu-latest, quindi ./gradlew bundleRelease funziona dopo actions/setup-java. gradle/actions/setup-gradle gestisce bene la cache di Gradle. I test sull'emulatore girano su runner Linux con KVM tramite azioni della community come reactivecircus/android-emulator-runner.

La firma significa decodificare il keystore da un secret e passare le password tramite le proprietà Gradle. L'upload usa fastlane supply, il plugin Gradle Play Publisher o un'azione della community. Niente è gestito, ma niente è nascosto, e i minuti Linux sono i più economici che troverai. Guida: Build Android Capacitor automatica con GitHub Actions.

GitLab CI

Stessa storia su GitLab: qualsiasi immagine Docker con SDK Android funziona sui runner Linux condivisi. Le funzionalità Mobile DevOps di GitLab includono i secure files per i keystore e un'integrazione con Google Play che espone l'account di servizio ai job, eliminando parte del boilerplate dalle configurazioni fastlane. Guida: Build Android automatico Capacitor su GitLab.

Bitrise

Il supporto Android di Bitrise si basa su step: Android Build, Android Sign, Google Play Deploy, più step per test ed emulatori. I keystore vengono caricati una sola volta nelle impostazioni di firma code dell'app. Lo step Google Play Deploy supporta track e percentuali di rollout graduale. Si paga a crediti, quindi le build Android costano meno di quelle iOS, ma più di un runner Linux standard. Ideale per team mobili che vogliono un editor di workflow guidato da UI.

Codemagic

Codemagic memorizza i keystore come riferimenti nominati che codemagic.yaml puntano, in modo che il file non compaia mai nel repository o nei log. Il google_play blocco publishing imposta la track, la percentuale di rollout e se inviare come bozza. Esegue build native per Android, Flutter, React Native, Ionic e Capacitor. La fatturazione è a minuti di build o con un piano annuale fisso.

Appcircle

Appcircle memorizza i keystore nel modulo identità di firma e pubblica su Google Play tramite il flusso di publishing, insieme alla distribuzione ai tester e a un app store enterprise. L'opzione self-hosted Appcircle Server è la ragione principale per cui i team regolamentati lo scelgono: code e chiavi non lasciano mai la loro rete.

CircleCI

CircleCI pubblica cimg/android immagini Docker con SDK installato, più un orb Android con helper per test su emulatore e caching. Firma e upload sono script o fastlane. La fatturazione usa crediti, e gli executor Docker Linux sono le classi di risorse più economiche. Una scelta ragionevole se CircleCI gestisce già il resto del tuo stack.

Azure DevOps

Azure Pipelines offre task first-party per ogni passaggio: Gradle@3 per il build, AndroidSigning@3 per la firma e zipalign, la sicurezza dei file del keystore e il task di rilascio dell'estensione Google Play per upload delle track e rollouts graduali. Il prezzo è per job parallelo. È la destinazione naturale per i team che usavano i build Android di App Center.

Build Capgo

Build Capgo è un servizio di build per app Capacitor che la tua CI chiama. Il job 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 sui suoi build machine, firma con il tuo keystore, legge il valore più alto versionCode da Google Play e lo incrementa, poi carica l'AAB nella track che hai scelto. --android-release-status, --android-flavor, e --submit-to-store-review controlla il resto. Per le build APK al di fuori di Google Play (dispositivi kiosk, MDM), --no-playstore-upload --output-upload restituisce un link di download.

La configurazione è guidata: bunx @capgo/cli@latest build init --platform android crea o importa il keystore e può configurare il service account di Google Cloud e l'invito alla Play Console tramite Google sign-in, il passaggio che la maggior parte dei team sbaglia quando lo fa a mano.

Per essere onesti: Android è la piattaforma dove Capgo Build fa risparmiare meno, perché i runner Linux costano poco ovunque. Il suo valore su Android è la coerenza con la pipeline iOS, i version code automatici, niente manutenzione di Android SDK o JDK in CI, e lo stesso CLI per il rilascio live updates per modifiche solo web. Una singola build è limitata a 10 minuti.

Criticità Android e come ogni piattaforma le gestisce

Smarrimento del keystore

Perdere il keystore un tempo significava non poter più aggiornare l'app. Con Play App Signing, il keystore in tuo possesso è solo la upload key, e l'assistenza di Play Console può registrarne una nuova. Tuttavia, tieni sempre un backup offline. Tutte le piattaforme sopra cifrano il keystore; il rischio è di solito la copia sul laptop di un developer. Se ne serve uno nuovo, Generatore di keystore per Android lo crea direttamente nel browser.

Collisioni della versione code

Play rifiuta un upload il cui versionCode era già stato usato. Opzioni: derivarlo dal numero di run della CI (GitHub, GitLab, CircleCI), usare la variabile del build number della piattaforma (Bitrise, Codemagic, Appcircle), o lasciare che Capgo Build legga l'ultimo valore da Play e lo incrementi.

Build Gradle lente

Una build Android Capacitor a freddo scarica centinaia di megabyte di dipendenze. Il caching ~/.gradle/caches e ~/.gradle/wrapper rende le build ripetute molto più veloci. Assegna abbastanza memoria a Gradle in gradle.properties (org.gradle.jvmargs=-Xmx4g) sui runner ospitati, e fai la build di iOS e Android in job paralleli invece che una dopo l'altra.

Upgrade di plugin e AGP

Le nuove versioni di Android Gradle Plugin rompono i plugin più vecchi. Fissa la versione di AGP nel tuo progetto e aggiorna su un branch. I fix specifici sono in Fix degli errori di build del plugin Capacitor con AGP 9 e Come risolvere gli errori di build Android in Capacitor.

Permessi dell'account di servizio Play

“The caller does not have permission” è l'errore di upload più comune. Il service account deve essere invitato in Play Console sotto Utenti e autorizzazioni con i permessi di rilascio per l'app, e il Google Play Android Developer API deve essere abilitato nel relativo progetto Google Cloud. I nuovi service account possono impiegare un po' prima che API li accetti.

Come scegliere

Per il lato iOS della stessa decisione, leggi Confronto tra piattaforme CI/CD per app iOS. Per le app Capacitor in particolare, inclusi gli aggiornamenti live, vedi Confronto tra piattaforme CI/CD per app Capacitor.

Una rapida checklist prima di migrare

• Verifica di avere il file keystore di upload e entrambe le password, e che l'alias corrisponda.
• Verifica in Play Console quale certificato è registrato come chiave di upload e confronta il suo SHA-1 con keytool -list -v -keystore release.jks.
• Crea un account di servizio dedicato per la nuova CI invece di riutilizzare uno personale.
• Assicurati che la nuova piattaforma compili con JDK 21 per i progetti Capacitor 8.
• Esegui un upload su una traccia interna prima di passare ai rilasci di produzione.