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 за конкретно устройство или да стартирате вътрешно тестване чрез траковете 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. Тези данни помагат за оптимизиране на конфигурацията на разделяния и намаляване на размера на изтегляне за различни категории устройства.