APK и AAB: чем отличаются форматы Android-приложений

Короткий ответ

• APK (Android Package) — готовый к установке файл. Его можно скопировать на телефон и установить.
• AAB (Android App Bundle) — формат для публикации. На устройство его не установить: Google Play берёт AAB и генерирует из него набор split APK, оптимизированный под конкретный телефон.

Новые приложения в Google Play публикуются только в формате AAB. APK остаётся нужен для установки вне магазина, внутреннего тестирования и некоторых других сторов.

Что внутри APK

APK — это ZIP-архив со стандартной структурой:

• AndroidManifest.xml — манифест в бинарном виде: пакет, разрешения, компоненты;
• classes.dex — скомпилированный код приложения;
• resources.arsc и папка res/ — ресурсы: строки, разметка, изображения;
• assets/ — произвольные файлы, которые приложение читает как есть;
• lib/<abi>/ — нативные библиотеки под архитектуры процессора;
• META-INF/ и блок подписи — данные о подписи разработчика.

Проблема классического универсального APK в том, что в нём лежит всё сразу: библиотеки для всех архитектур, картинки для всех плотностей экрана, строки на всех языках. Пользователь скачивает то, что его устройству никогда не понадобится.

Что внутри AAB

AAB тоже ZIP-архив, но устроен по модулям:

• base/ — основной модуль с манифестом, кодом (dex/), ресурсами, lib/ и assets/;
• папки feature-модулей, если приложение разбито на части;
• BundleConfig.pb и метаданные сборки.

Подписи для конечных устройств в AAB нет — её добавляет Google Play при генерации APK.

Как split APK уменьшают загрузку

Из AAB Google Play собирает базовый APK и конфигурационные сплиты:

Устройство получает базовый APK и только подходящие ему сплиты. Сверху можно использовать Play Feature Delivery (модули, которые скачиваются по требованию) и Play Asset Delivery (крупные ресурсы игр).

Как работает подпись

Каждый APK должен быть подписан, иначе Android его не установит. Обновление принимается, только если подпись совпадает с подписью уже установленной версии.

С AAB обязательна Play App Signing, и ключей становится два:

• upload key — им вы подписываете AAB перед загрузкой в Play Console;
• app signing key — его хранит Google и подписывает им APK, которые получают пользователи.

Плюс схемы: если upload key утерян или скомпрометирован, его можно сбросить через Play Console. Ключ подписи приложения при этом в сохранности.

Важный нюанс: если вы распространяете приложение ещё и вне Google Play, подписи могут не совпасть, и пользователь не сможет обновиться «поверх» версии из другого источника. При подключении Play App Signing можно загрузить собственный ключ подписи, чтобы использовать один ключ везде.

Как собрать оба формата

# AAB для Google Play
./gradlew bundleRelease

# APK для прямой установки и тестов
./gradlew assembleRelease

# Проверить AAB локально: собрать APK под подключённое устройство и установить
java -jar bundletool.jar build-apks --bundle=app-release.aab --output=app.apks --connected-device
java -jar bundletool.jar install-apks --apks=app.apks

Во Flutter аналогичные команды — flutter build appbundle и flutter build apk. Подробности — в документации Android App Bundle.

Частые ошибки

• Keystore хранится только на ноутбуке разработчика. Нужна резервная копия и пароли в менеджере паролей компании.
• AAB отправляют тестировщикам напрямую. Он не установится — используйте внутреннее тестирование в Play Console или универсальный APK.
• Размер AAB принимают за размер загрузки. Реальный размер для пользователей смотрите в отчёте о размере приложения в Play Console.
• Ключи и пароли попадают в репозиторий. Храните их в секретах CI, а не в build.gradle.