AAB — cos'è, differenza dall'APK e principio di funzionamento

Cos'è AAB

AAB (Android App Bundle) è un formato di pubblicazione sviluppato da Google come sostituto dell'APK per la distribuzione tramite Google Play. All'interno dell'AAB c'è un archivio ZIP con estensione .aab contenente codice compilato, risorse e metadati. La differenza principale: l'AAB non viene installato direttamente su un dispositivo.

Come funziona

Lo sviluppatore carica l'AAB in Google Play Console. Quando un utente tenta di installare l'applicazione, Google Play analizza la configurazione del dispositivo: densità dello schermo (DPI), architettura della CPU, lingua e versione di Android. Sulla base di questa analisi, viene generato un APK minimo contenente solo i componenti necessari.

Storia dell'adozione

Google ha presentato AAB nel 2018 alla conferenza I/O. Da agosto 2021, il formato è diventato obbligatorio per tutte le nuove applicazioni su Google Play. Le applicazioni esistenti possono continuare a usare APK, ma quelle nuove devono essere pubblicate solo in AAB.

Differenza tra AAB e APK

La differenza tra AAB e APK è fondamentale: APK è un file di installazione completo pronto per l'installazione. AAB è un contenitore con componenti sorgente che richiede elaborazione.

APK è adatto per la distribuzione al di fuori di Google Play — tramite siti web, email o sistemi MDM aziendali. AAB è legato all'infrastruttura di Google Play e non può essere installato direttamente. Per testare AAB si utilizza lo strumento bundletool, che emula la generazione di APK su una macchina locale.

Struttura del file AAB

La struttura interna di AAB è simile all'APK ma contiene directory e file aggiuntivi per descrivere i moduli e le loro dipendenze.

Modulo base (base)

Il modulo base è un componente obbligatorio di AAB. Contiene il codice principale, le risorse e il manifesto dell'applicazione. Senza il modulo base, l'applicazione non può essere compilata. Tutti gli altri moduli sono opzionali e vengono collegati tramite Dynamic Delivery.

Formato Protobuf

La configurazione di AAB utilizza Protocol Buffers (protobuf) invece di XML. I file .pb sono più compatti e vengono analizzati più velocemente dall'infrastruttura server di Google. Lo strumento bundletool converte protobuf in un formato leggibile per il debug.

Dynamic Delivery e moduli dell'applicazione

Dynamic Delivery è la tecnologia chiave su cui si basa AAB. Consente di fornire all'utente solo le parti dell'applicazione che corrispondono al suo dispositivo e alla sua lingua, nonché di caricare moduli aggiuntivi su richiesta.

Tipi di moduli

I moduli Install-time vengono caricati insieme all'APK di base durante l'installazione. I moduli Conditional vengono forniti solo quando vengono soddisfatte determinate condizioni — ad esempio, un modulo con materiali per schermi 4K. I moduli On-demand vengono caricati su richiesta dell'utente all'interno dell'applicazione.

Play Asset Delivery (PAD)

Per risorse di grandi dimensioni (fino a 2 GB), viene utilizzato Play Asset Delivery invece dei file OBB. PAD supporta le stesse tre modalità di consegna: install-time, fast-follow (subito dopo l'installazione) e on-demand.

// Caricamento modulo on-demand tramite SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

val request = SplitInstallRequest
    .newBuilder()
    .addModule("level_pack_3")
    .build()

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Module installed")
    }

Configurazione del modulo in Gradle

Ogni modulo dinamico è descritto in un file build.gradle separato con il tipo di consegna specificato. Un modulo può contenere proprie risorse, codice e manifesto, indipendenti dall'applicazione di base.

Compilazione di AAB tramite Gradle

La compilazione di AAB viene eseguita tramite Android Gradle Plugin con l'attività bundleRelease (o bundleDebug). Il risultato è un file .aab nella directory build/outputs/bundle/.

Configurazione di compilazione

Non è necessaria alcuna configurazione speciale per compilare AAB — Android Gradle Plugin supporta i bundle per impostazione predefinita. È sufficiente specificare l'attività bundle invece di assemble.

// build.gradle.kts — compilazione AAB con firma
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// Attività: ./gradlew bundleRelease

Test locale tramite bundletool

Google fornisce lo strumento bundletool per generare APK da AAB su una macchina locale. Il comando `bundletool build-apks --bundle=app.aab --output=app.apks` crea un insieme di APK per i test su diverse configurazioni di dispositivi.

bundletool può anche decomprimere AAB, visualizzarne la configurazione e verificare l'integrità della firma prima del caricamento in Google Play Console. Per il debug, viene utilizzato il comando `bundletool dump manifest --bundle=app.aab` che mostra il manifesto del modulo base.

Configurazione degli split in AAB

Per impostazione predefinita, AAB divide le risorse in tre dimensioni: lingua, densità dello schermo (density) e architettura della CPU (abi). Lo sviluppatore può disabilitare qualsiasi suddivisione in build.gradle — ad esempio, se l'applicazione supporta solo l'inglese. Disabilitare una suddivisione significa che le risorse per tutte le varianti saranno incluse nell'APK di base.

Ottimizzazione delle risorse — AAB converte automaticamente PNG in WebP senza perdita di qualità, comprime le risorse inutilizzate e rimuove le stringhe duplicate. Queste ottimizzazioni vengono applicate lato Google Play durante la generazione dell'APK finale. Di conseguenza, l'utente riceve un APK più piccolo del 15–25% rispetto all'archivio completo.

Pubblicazione di AAB su Google Play

Il processo di pubblicazione di AAB in Google Play Console differisce dall'APK solo nel formato del file caricato. La console accetta .aab, ne verifica la struttura, la firma e la configurazione dei moduli, quindi genera APK per ogni tipo di dispositivo.

App Signing by Google Play

Quando si carica AAB, Google Play assume la gestione delle chiavi di firma. Lo sviluppatore carica un pacchetto firmato con una chiave upload e Google ri-firma gli APK generati con la propria chiave. Questo semplifica la rotazione delle chiavi e il recupero dell'accesso in caso di perdita del keystore.

Test prima del rilascio

Google Play Console fornisce un test AAB integrato: è possibile scaricare l'APK generato per un dispositivo specifico o eseguire test interni tramite i track Internal Testing, Closed Alpha e Open Beta.

Problemi comuni con AAB e soluzioni

La migrazione ad AAB può causare problemi, specialmente in progetti con molti moduli dinamici o configurazione complessa delle risorse.

Errori di configurazione dei moduli

Se un modulo dinamico fa riferimento a risorse del modulo base con un nome errato, Google Play rifiuta l'AAB durante la verifica. Soluzione — utilizzare il controllo lint prima della compilazione e testare tutti i moduli tramite bundletool localmente.

Suddivisioni linguistiche e impatto sulle prestazioni

La suddivisione per lingua può rallentare l'avvio dell'applicazione se le risorse per la lingua corrente vengono caricate dinamicamente. La raccomandazione di Google è di non suddividere le lingue se sono meno di 10, o di utilizzare install-time per quelle più popolari.

Compatibilità con SDK di terze parti

Alcuni SDK (analytics, pubblicità, mappe) richiedono l'accesso al manifesto completo e alle risorse. La verifica della compatibilità con AAB è un passaggio obbligatorio prima della migrazione. La maggior parte dei principali SDK (Firebase, Google Ads, Crashlytics) supporta completamente AAB dal 2022. Per verificare la compatibilità, si utilizza bundletool con il flag --validate, che emula la generazione di APK lato server.

Versionamento di AAB

AAB utilizza il versionCode dal manifesto del modulo base. A differenza di APK, AAB supporta anche un versionCode separato per ogni modulo — ciò consente di aggiornare parti individuali dell'applicazione senza una reinstallazione completa. Dynamic Delivery tiene traccia dei moduli installati e fornisce solo i componenti modificati durante gli aggiornamenti tramite Google Play.

Monitoraggio e analisi di AAB

Google Play Console fornisce analisi dettagliate per ogni AAB: quanti APK sono stati generati, quali split sono stati richiesti, qual è la dimensione media del download per dispositivo. Android Vitals mostra le metriche delle prestazioni degli APK generati. Questi dati aiutano a ottimizzare la configurazione degli split e a ridurre la dimensione del download per diverse categorie di dispositivi.