AAB — vad är det, skillnad från APK och funktionsprincip

Vad är AAB

AAB (Android App Bundle) — är ett publiceringsformat utvecklat av Google som ersättning för APK för distribution via Google Play. Inuti AAB finns ett ZIP-arkiv med tillägget .aab som innehåller kompilerad kod, resurser och metadata. Den viktigaste skillnaden: AAB installeras inte direkt på enheten.

Funktionsprincip

Utvecklaren laddar upp AAB till Google Play Console. När en användare försöker installera applikationen analyserar Google Play enhetens konfiguration: skärmdensitet (DPI), CPU-arkitektur, språk och Android-version. Baserat på denna analys genereras en minimal APK som endast innehåller nödvändiga komponenter.

Implementeringshistorik

Google introducerade AAB 2018 vid I/O-konferensen. Från augusti 2021 blev formatet obligatoriskt för alla nya applikationer i Google Play. Befintliga applikationer kan fortsätta använda APK, men nya måste publiceras endast i AAB-format.

Hur skiljer sig AAB från APK

Skillnaden mellan AAB och APK är fundamental: APK är en komplett installationsfil, redo för installation. AAB är en behållare med källkomponenter som kräver bearbetning.

APK är lämplig för distribution utanför Google Play — via webbplatser, e-post eller företags-MDM-system. AAB är bunden till Google Plays infrastruktur och installeras inte direkt. För testning av AAB används verktyget bundletool, som emulerar APK-generering på den lokala maskinen.

Struktur för en AAB-fil

Den interna strukturen av AAB liknar APK, men innehåller ytterligare kataloger och filer för att beskriva moduler och deras beroenden.

Basmodul (base)

Basmodulen base — är en obligatorisk komponent i AAB. Den innehåller huvudkoden, resurserna och manifestet för applikationen. Utan basmodulen kan applikationen inte byggas. Alla andra moduler är valfria och ansluts via Dynamic Delivery.

Protobuf-format

AAB-konfiguration använder Protocol Buffers (protobuf) istället för XML. .pb-filer är mer kompakta och parsas snabbare av Googles serverinfrastruktur. Verktyget bundletool konverterar protobuf till ett läsbart format för felsökning.

Dynamic Delivery och applikationsmoduler

Dynamic Delivery — den viktigaste tekniken som AAB är byggd på. Den gör det möjligt att leverera till användaren endast de delar av applikationen som matchar dennes enhet och språk, samt att ladda ytterligare moduler på begäran.

Modultyper

Install-time moduler laddas tillsammans med bas-APK:n vid installation. Conditional moduler levereras endast när villkor uppfylls — till exempel en modul med material för 4K-skärmar. On-demand moduler laddas på användarens begäran inuti applikationen.

Play Asset Delivery (PAD)

För stora resurser (upp till 2 GB) används Play Asset Delivery istället för OBB-filer. PAD stöder samma tre leveranslägen: install-time, fast-follow (direkt efter installation) och on-demand.

// Ladda on-demand-modul via SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

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

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Modul installerad")
    }

Modulkonfiguration i Gradle

Varje dynamisk modul beskrivs av en separat build.gradle-fil med angivelse av leveranstyp. Modulen kan ha egna resurser, kod och manifest, oberoende av basapplikationen.

Bygga AAB via Gradle

Att bygga AAB görs via Android Gradle Plugin med uppgiften bundleRelease (eller bundleDebug). Resultatet — en .aab-fil i katalogen build/outputs/bundle/.

Byggkonfiguration

För att bygga AAB krävs inga speciella inställningar — Android Gradle Plugin stöder paket som standard. Det räcker med att ange uppgiften bundle istället för assemble.

// build.gradle.kts — bygga AAB med signatur
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// Uppgift: ./gradlew bundleRelease

Lokal testning via bundletool

Google tillhandahåller verktyget bundletool för att generera APK:er från AAB på den lokala maskinen. Kommandot `bundletool build-apks --bundle=app.aab --output=app.apks` skapar en uppsättning APK:er för testning på olika enhetskonfigurationer.

bundletool kan också packa upp AAB, visa dess konfiguration och kontrollera signaturintegriteten före uppladdning till Google Play Console. För felsökning används kommandot `bundletool dump manifest --bundle=app.aab`, som visar manifestet för basmodulen.

Konfiguration av uppdelningar i AAB

Som standard delar AAB upp resurser efter tre dimensioner: språk (language), skärmdensitet (density) och CPU-arkitektur (abi). Utvecklaren kan inaktivera valfri uppdelning i build.gradle — till exempel om applikationen endast stöder engelska. Att inaktivera en uppdelning innebär att resurser för alla varianter hamnar i bas-APK:n.

Resource optimisation — AAB konverterar automatiskt PNG till WebP utan kvalitetsförlust, komprimerar oanvända resurser och tar bort dubbletter av strängar. Dessa optimeringar tillämpas på Google Plays sida vid generering av den slutliga APK:n. Som ett resultat får användaren en APK som är 15–25% mindre än det fullständiga arkivet.

Publicera AAB i Google Play

Processen att publicera AAB i Google Play Console skiljer sig från APK endast i formatet på den uppladdade filen. Konsolen accepterar .aab, kontrollerar dess struktur, signatur och modulkonfiguration, varefter den genererar APK:er för varje enhetstyp.

App Signing by Google Play

Vid uppladdning av AAB tar Google Play över hanteringen av signeringsnycklar. Utvecklaren laddar upp paketet signerat med upload-nyckeln, och Google signerar om de genererade APK:erna med sin egen nyckel. Detta förenklar nyckelrotation och återställning av åtkomst vid förlust av keystore.

Testning före lansering

Google Play Console erbjuder ett inbyggt test av AAB: man kan ladda ner den genererade APK:n för en specifik enhet eller köra intern testning via trackarna Internal Testing, Closed Alpha och Open Beta.

Typiska problem med AAB och deras lösning

Övergången till AAB kan orsaka problem, särskilt i projekt med många dynamiska moduler eller komplex resurskonfiguration.

Konfigurationsfel för moduler

Om en dynamisk modul refererar till basmodulens resurser med ett felaktigt namn, avvisar Google Play AAB:n i verifieringssteget. Lösning — använd lint-kontroll före byggning och testa alla moduler lokalt via bundletool.

Språkuppdelningar och prestandaförsämring

Uppdelning efter språk kan sakta ner applikationens start om resurser för den aktuella lokaliseringen laddas dynamiskt. Googles rekommendation — dela inte upp språk om det är färre än 10, eller använd install-time för de mest populära.

Kompatibilitet med tredjeparts-SDK:er

Vissa SDK:er (analys, annonser, kartor) kräver åtkomst till hela manifestet och resurser. Kontroll av kompatibilitet med AAB är ett obligatoriskt steg före migrering. De flesta stora SDK:er (Firebase, Google Ads, Crashlytics) stöder fullt AAB från 2022. För kompatibilitetskontroll används bundletool med flaggan --validate, som emulerar servergenerering av APK.

Versionhantering av AAB

AAB använder versionCode från basmodulens manifest. Till skillnad från APK stöder AAB också separat versionCode för varje modul — detta gör det möjligt att uppdatera enskilda delar av applikationen utan fullständig ominstallation. Dynamic Delivery håller reda på installerade moduler och levererar endast ändrade komponenter vid uppdatering via Google Play.

Övervakning och analys av AAB

Google Play Console tillhandahåller detaljerad analys för varje AAB: hur många APK:er som genererats, vilka uppdelningar som använts, vad den genomsnittliga nedladdningsstorleken per enhet är. Android Vitals visar prestandamått för genererade APK:er. Dessa data hjälper till att optimera uppdelningskonfigurationen och minska nedladdningsstorleken för olika enhetskategorier.