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 ГБ) використовується 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", "Module installed")
    }

Конфігурація модуля в 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 розділяє ресурси за трьома вимірами: мова, щільність екрана (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. Ці дані допомагають оптимізувати конфігурацію сплітів та зменшувати розмір завантаження для різних категорій пристроїв.