AAB — co to jest, różnica od APK i zasada działania

Co to jest AAB

AAB (Android App Bundle) — to format publikacji opracowany przez Google jako zamiennik APK do dystrybucji przez Google Play. Wewnątrz AAB — archiwum ZIP z rozszerzeniem .aab, zawierające skompilowany kod, zasoby i metadane. Kluczowa różnica: AAB nie jest instalowany bezpośrednio na urządzeniu.

Zasada działania

Deweloper przesyła AAB do Google Play Console. Gdy użytkownik próbuje zainstalować aplikację, Google Play analizuje konfigurację urządzenia: gęstość ekranu (DPI), architekturę CPU, język i wersję Androida. Na podstawie tej analizy generowany jest minimalny APK, zawierający tylko niezbędne komponenty.

Historia wdrożenia

Google przedstawiło AAB w 2018 roku na konferencji I/O. Od sierpnia 2021 format stał się obowiązkowy dla wszystkich nowych aplikacji w Google Play. Istniejące aplikacje mogą nadal używać APK, ale nowe muszą być publikowane tylko w formacie AAB.

Czym AAB różni się od APK

Różnica między AAB a APK jest fundamentalna: APK — to gotowy plik instalacyjny, gotowy do instalacji. AAB — to kontener z komponentami źródłowymi, wymagający przetworzenia.

APK nadaje się do dystrybucji poza Google Play — przez strony internetowe, e-mail lub korporacyjne systemy MDM. AAB jest powiązany z infrastrukturą Google Play i nie jest instalowany bezpośrednio. Do testowania AAB używa się narzędzia bundletool, które emuluje generowanie APK na lokalnej maszynie.

Struktura pliku AAB

Wewnętrzna budowa AAB przypomina APK, ale zawiera dodatkowe katalogi i pliki do opisywania modułów i ich zależności.

Moduł bazowy (base)

Moduł base — obowiązkowy komponent AAB. Zawiera główny kod, zasoby i manifest aplikacji. Bez modułu base aplikacja nie może zostać zbudowana. Wszystkie pozostałe moduły są opcjonalne i podłączane przez Dynamic Delivery.

Format protobuf

Konfiguracja AAB używa Protocol Buffers (protobuf) zamiast XML. Pliki .pb są bardziej kompaktowe i szybciej parsowane przez infrastrukturę serwerową Google. Narzędzie bundletool przekształca protobuf w czytelny format do debugowania.

Dynamic Delivery i moduły aplikacji

Dynamic Delivery — kluczowa technologia, na której zbudowany jest AAB. Pozwala ona dostarczać użytkownikowi tylko te części aplikacji, które odpowiadają jego urządzeniu i językowi, a także ładować dodatkowe moduły na żądanie.

Typy modułów

Install-time moduły są ładowane razem z bazowym APK podczas instalacji. Conditional moduły są dostarczane tylko po spełnieniu warunków — na przykład moduł z materiałami dla ekranów 4K. On-demand moduły są ładowane na żądanie użytkownika wewnątrz aplikacji.

Play Asset Delivery (PAD)

Dla dużych zasobów (do 2 GB) używa się Play Asset Delivery zamiast plików OBB. PAD obsługuje te same trzy tryby dostarczania: install-time, fast-follow (zaraz po instalacji) i on-demand.

// Ładowanie modułu on-demand przez SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

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

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Moduł zainstalowany")
    }

Konfiguracja modułu w Gradle

Każdy moduł dynamiczny jest opisywany osobnym plikiem build.gradle z określeniem typu dostawy. Moduł może zawierać własne zasoby, kod i manifest, niezależne od bazowej aplikacji.

Budowa AAB przez Gradle

Budowa AAB jest wykonywana przez Android Gradle Plugin za pomocą zadania bundleRelease (lub bundleDebug). Wynik — plik .aab w katalogu build/outputs/bundle/.

Konfiguracja budowy

Do budowy AAB nie są wymagane specjalne ustawienia — Android Gradle Plugin obsługuje pakiety domyślnie. Wystarczy wskazać zadanie bundle zamiast assemble.

// build.gradle.kts — budowa AAB z podpisem
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// Zadanie: ./gradlew bundleRelease

Testowanie lokalne przez bundletool

Google udostępnia narzędzie bundletool do generowania APK z AAB na lokalnej maszynie. Polecenie `bundletool build-apks --bundle=app.aab --output=app.apks` tworzy zestaw APK do testowania na różnych konfiguracjach urządzeń.

bundletool umożliwia także rozpakowywanie AAB, wyświetlanie jego konfiguracji i sprawdzanie integralności podpisu przed przesłaniem do Google Play Console. Do debugowania używa się polecenia `bundletool dump manifest --bundle=app.aab`, które pokazuje manifest modułu bazowego.

Konfiguracja podziałów w AAB

Domyślnie AAB dzieli zasoby według trzech wymiarów: język (language), gęstość ekranu (density) i architektura CPU (abi). Deweloper może wyłączyć dowolny podział w build.gradle — na przykład jeśli aplikacja obsługuje tylko język angielski. Wyłączenie podziału oznacza, że zasoby dla wszystkich wariantów trafią do bazowego APK.

Resource optimisation — AAB automatycznie konwertuje PNG do WebP bez utraty jakości, kompresuje nieużywane zasoby i usuwa zduplikowane ciągi. Te optymalizacje są stosowane po stronie Google Play podczas generowania końcowego APK. W rezultacie użytkownik otrzymuje APK o 15–25% mniejszy niż pełne archiwum.

Publikacja AAB w Google Play

Proces publikacji AAB w Google Play Console różni się od APK tylko formatem przesyłanego pliku. Konsola przyjmuje .aab, sprawdza jego strukturę, podpis i konfigurację modułów, po czym generuje APK dla każdego typu urządzeń.

App Signing by Google Play

Przy przesyłaniu AAB Google Play przejmuje zarządzanie kluczami podpisu. Deweloper przesyła pakiet podpisany kluczem upload, a Google podpisuje ponownie wygenerowane APK swoim kluczem. Upraszcza to rotację kluczy i przywracanie dostępu w przypadku utraty keystore.

Testowanie przed wydaniem

Google Play Console udostępnia wbudowany test AAB: można pobrać wygenerowany APK dla konkretnego urządzenia lub uruchomić testy wewnętrzne poprzez tracki Internal Testing, Closed Alpha i Open Beta.

Typowe problemy z AAB i ich rozwiązanie

Przejście na AAB może powodować problemy, szczególnie w projektach z dużą liczbą modułów dynamicznych lub złożoną konfiguracją zasobów.

Błędy konfiguracji modułów

Jeśli moduł dynamiczny odwołuje się do zasobów modułu bazowego z nieprawidłową nazwą, Google Play odrzuca AAB na etapie weryfikacji. Rozwiązanie — użycie kontroli lint przed budową i testowanie wszystkich modułów przez bundletool lokalnie.

Podziały językowe i spadek wydajności

Podział według języków może spowolnić uruchamianie aplikacji, jeśli zasoby dla bieżącej lokalizacji są ładowane dynamicznie. Zalecenie Google — nie dzielić języków, jeśli jest ich mniej niż 10, lub używać install-time dla najpopularniejszych.

Zgodność z SDK stron trzecich

Niektóre SDK (analityka, reklamy, mapy) wymagają dostępu do pełnego manifestu i zasobów. Sprawdzenie zgodności z AAB — obowiązkowy krok przed migracją. Większość dużych SDK (Firebase, Google Ads, Crashlytics) w pełni obsługuje AAB od 2022 roku. Do sprawdzenia zgodności używa się bundletool z flagą --validate, która emuluje serwerowe generowanie APK.

Wersjonowanie AAB

AAB używa versionCode z manifestu modułu bazowego. W przeciwieństwie do APK, AAB obsługuje także versionCode dla każdego modułu osobno — pozwala to aktualizować poszczególne części aplikacji bez pełnej reinstalacji. Dynamic Delivery śledzi zainstalowane moduły i dostarcza tylko zmienione komponenty przy aktualizacji przez Google Play.

Monitorowanie i analityka AAB

Google Play Console udostępnia szczegółową analitykę dla każdego AAB: ile APK zostało wygenerowanych, które podziały były wykorzystywane, jaki jest średni rozmiar pobierania według urządzeń. Android Vitals pokazuje metryki wydajności wygenerowanych APK. Te dane pomagają optymalizować konfigurację podziałów i zmniejszać rozmiar pobierania dla różnych kategorii urządzeń.