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 — через сайты, email или корпоративные 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 разделяет ресурсы по трём измерениям: язык (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 года. Для проверки совместимости используется bundle tool с флагом --validate, который эмулирует серверную генерацию APK.

Версионирование AAB

AAB использует versionCode из манифеста базового модуля. В отличие от APK, AAB также поддерживает versionCode для каждого модуля отдельно — это позволяет обновлять отдельные части приложения без полной переустановки. Dynamic Delivery отслеживает установленные модули и доставляет только изменённые компоненты при обновлении через Google Play.

Мониторинг и аналитика AAB

Google Play Console предоставляет детальную аналитику по каждому AAB: сколько APK сгенерировано, какие сплиты были востребованы, какой средний размер загрузки по устройствам. Android Vitals показывает метрики производительности сгенерированных APK. Эти данные помогают оптимизировать конфигурацию сплитов и уменьшать размер загрузки для разных категорий устройств.