AAB — шта је то, разлика од APK и принцип рада

Шта је AAB

AAB (Android App Bundle) — је формат објављивања који је развио Google као замјену за APK за дистрибуцију путем Google Play. Унутар AAB се налази ZIP архив са екстензијом .aab, који садржи компајлирани код, ресурсе и метаподатке. Кључна разлика: AAB се не инсталира директно на уређај.

Принцип рада

Програмер поставља AAB у Google Play Console. Када корисник покуша да инсталира апликацију, Google Play анализира конфигурацију уређаја: густину екрана (DPI), архитектуру CPU, језик и верзију Android-а. На основу ове анализе генерише се минимални APK који садржи само неопходне компоненте.

Историја имплементације

Google је представио AAB 2018. године на конференцији I/O. Од августа 2021, формат је постао обавезан за све нове апликације у Google Play. Постојеће апликације могу наставити да користе APK, али нове морају бити објављене само у AAB формату.

Како се AAB разликује од APK

Разлика између AAB и APK је фундаментална: APK је готов инсталациони фајл, спреман за инсталацију. AAB је контејнер са изворним компонентама који захтијева обраду.

APK је погодан за дистрибуцију изван Google Play — путем веб сајтова, е-поште или корпоративних MDM система. AAB је везан за инфраструктуру Google Play и не инсталира се директно. За тестирање AAB користи се алат bundletool, који емулира генерисање APK на локалној машини.

Структура AAB фајла

Унутрашња структура AAB је слична APK, али садржи додатне директоријуме и фајлове за описивање модула и њихових зависности.

Основни модул (base)

Модул base — обавезна компонента AAB. Он садржи главни код, ресурсе и манифест апликације. Без base модула апликација не може бити изграђена. Сви остали модули су опционални и повезују се путем Dynamic Delivery.

Protobuf формат

Конфигурација AAB користи Protocol Buffers (protobuf) умјесто XML. .pb фајлови су компактнији и брже се парсирају од стране Google серверске инфраструктуре. Алат bundletool претвара protobuf у читљив формат за отклањање грешака.

Dynamic Delivery и модули апликације

Dynamic Delivery — кључна технологија на којој је изграђен AAB. Она омогућава испоруку кориснику само оних дијелова апликације који одговарају његовом уређају и језику, као и учитавање додатних модула на захтјев.

Типови модула

Install-time модули се учитавају заједно са базним APK-ом приликом инсталације. Conditional модули се испоручују само када су испуњени услови — на примјер, модул са материјалима за 4K екране. On-demand модули се учитавају на захтјев корисника унутар апликације.

Play Asset Delivery (PAD)

За велике ресурсе (до 2 GB) користи се Play Asset Delivery умјесто OBB фајлова. PAD подржава иста три начина испоруке: install-time, fast-follow (одмах након инсталације) и on-demand.

// Учитавање on-demand модула путем SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

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

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Модул је инсталиран")
    }

Конфигурација модула у Gradle-у

Сваки динамички модул се описује посебним build.gradle фајлом са навођењем типа испоруке. Модул може садржати сопствене ресурсе, код и манифест, независне од базне апликације.

Изградња AAB кроз Gradle

Изградња AAB се врши путем Android Gradle Plugin-а са задатком bundleRelease (или bundleDebug). Резултат — .aab фајл у директоријуму build/outputs/bundle/.

Конфигурација изградње

За изградњу AAB нису потребна посебна подешавања — Android Gradle Plugin подржава пакете подразумијевано. Довољно је навести задатак bundle умјесто assemble.

// build.gradle.kts — изградња AAB са потписом
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// Задатак: ./gradlew bundleRelease

Локално тестирање путем bundletool-а

Google пружа алат bundletool за генерисање APK из AAB на локалној машини. Команда `bundletool build-apks --bundle=app.aab --output=app.apks` креира скуп APK-ова за тестирање на различитим конфигурацијама уређаја.

bundletool такође може да распакује AAB, прикаже његову конфигурацију и провјери интегритет потписа прије постављања у Google Play Console. За отклањање грешака користи се команда `bundletool dump manifest --bundle=app.aab`, која приказује манифест базног модула.

Конфигурација подијела у AAB

Подразумијевано, AAB дијели ресурсе по три димензије: језик (language), густина екрана (density) и архитектура CPU (abi). Програмер може онемогућити било који подијел у build.gradle — на примјер, ако апликација подржава само енглески језик. Онемогућавање подијела значи да ће ресурси за све варијанте бити укључени у базни APK.

Resource optimisation — AAB аутоматски конвертује PNG у WebP без губитка квалитета, компримује некоришћене ресурсе и уклања дуплиране стрингове. Ове оптимизације се примјењују на страни Google Play приликом генерисања коначног APK-а. Као резултат, корисник добија APK 15–25% мањи од пуног архива.

Објављивање AAB у Google Play

Процес објављивања AAB у Google Play Console разликује се од APK само по формату постављеног фајла. Конзола прихвата .aab, провјерава његову структуру, потпис и конфигурацију модула, након чега генерише APK за сваки тип уређаја.

App Signing by Google Play

Приликом постављања AAB, Google Play преузима управљање кључевима потписа. Програмер поставља пакет потписан кључем upload, а Google поново потписује генерисане APK својим кључем. Ово поједностављује ротацију кључева и обнављање приступа у случају губитка keystore-а.

Тестирање прије објављивања

Google Play Console пружа уграђено тестирање AAB: можете преузети генерисани APK за одређени уређај или покренути интерно тестирање кроз track-ове Internal Testing, Closed Alpha и Open Beta.

Типични проблеми са AAB и њихово рјешење

Прелазак на AAB може изазвати проблеме, посебно у пројектима са великим бројем динамичких модула или сложеном конфигурацијом ресурса.

Грешке конфигурације модула

Ако динамички модул референцира ресурсе базног модула са погрешним именом, Google Play одбија AAB у фази провјере. Рјешење — коришћење lint провјере прије изградње и тестирање свих модула путем bundletool-а локално.

Језички подијели и пад перформанси

Подијела по језицима може успорити покретање апликације ако се ресурси за тренутну локализацију учитавају динамички. Препорука Google-а — не дијелити језике ако их је мање од 10, или користити install-time за најпопуларније.

Компатибилност са SDK-овима трећих страна

Неки SDK-ови (аналитика, огласи, мапе) захтијевају приступ пуном манифесту и ресурсима. Провјера компатибилности са AAB је обавезан корак прије миграције. Већина великих SDK-ова (Firebase, Google Ads, Crashlytics) потпуно подржава AAB од 2022. године. За провјеру компатибилности користи се bundletool са флагом --validate, која емулира серверско генерисање APK.

Верзионисање AAB

AAB користи versionCode из манифеста базног модула. За разлику од APK, AAB такође подржава versionCode за сваки модул појединачно — то омогућава ажурирање појединачних дијелова апликације без потпуне поновне инсталације. Dynamic Delivery прати инсталиране модуле и испоручује само измијењене компоненте приликом ажурирања путем Google Play.

Праћење и аналитика AAB

Google Play Console пружа детаљну аналитику за сваки AAB: колико APK-ова је генерисано, који подијели су били затражени, која је просјечна величина преузимања по уређајима. Android Vitals приказује метрике перформанси генерисаних APK-ова. Ови подаци помажу у оптимизацији конфигурације подијела и смањењу величине преузимања за различите категорије уређаја.