APK и AAB: разница

Введение: два формата, которые путают все

«Чем APK отличается от AAB?» — вопрос, который задают и на собеседованиях, и при первой публикации в Google Play. И оба раза в ответ чаще всего звучит «это почти одно и то же». Это не так: между ними принципиальная разница.

APK вы видели точно: это файл, который можно скачать, переслать и установить на телефон. AAB — тоже файл, но установить его напрямую нельзя, и это не баг, а замысел. Один формат создан для установки, второй — для публикации.

Разница между ними — не академическая мелочь: от неё зависит, как вы собираете релиз, кто подписывает ваше приложение и почему пользователи скачивают меньше данных. Разберём оба формата по порядку.

APK: установочный формат

APK (Android Package Kit) — это готовый установочный пакет: подписанный архив с кодом, ресурсами и манифестом, который Android-устройство может установить напрямую. Его можно получить, собрать и положить на сайт, переслать в мессенджере, установить вручную — никакого Google Play для этого не нужно.

Именно APK видит устройство при установке из любого источника: из Play, с сайта разработчика, из файлового менеджера. Одно устройство — один APK, который включает всё: код для всех архитектур процессора, все плотности экрана, все языки.

В Gradle APK собирается задачей assembleRelease, и это хорошо знакомый каждому релизный путь: собрали → подписали → загрузили → пользователи устанавливают.

Раньше разработчики обходили это ограничение, собирая несколько APK под разные конфигурации устройств: отдельно под ARM, отдельно под x86, отдельно под разные плотности экрана. Работало, но превращало релиз в конвейер из пяти-десяти артефактов, которые нужно было подписывать, загружать и поддерживать.

AAB: формат публикации

AAB (Android App Bundle) — это публикационный формат. Определение из официальной документации: App Bundle включает весь скомпилированный код и ресурсы приложения, но откладывает генерацию и подписание APK на сторону Google Play.

Вы загружаете AAB в Play Console, а Google Play на основе вашего бандла собирает оптимизированные APK под каждую конфигурацию устройства: только нужная архитектура процессора, только нужная плотность экрана, только нужный язык. Пользователь скачивает минимум данных, а вы не собираете и не поддерживаете десяток артефактов — это происходит автоматически. Как сказано в той же документации, вам больше не нужно «собирать, подписывать и поддерживать несколько APK» для разных устройств.

Собирается бандл задачей bundleRelease. В Android Studio ему соответствует пункт меню Generate Signed App Bundle / APK.

У формата есть и дополнительные возможности: Play Feature Delivery — модули, которые скачиваются по условию или по требованию, и Play Asset Delivery — доставка больших игровых ассетов. И важное ограничение: формат AAB не поддерживает файлы расширений .obb, которые раньше использовались для больших ресурсов.

Разница: установка против публикации

Теперь главное — как отвечать на вопрос «в чём разница» коротко и по делу:

• APK — установочный формат: готовый, подписанный, ставится на устройство напрямую, один файл под все устройства.
• AAB — публикационный формат: не устанавливается, не подписывается разработчиком, а служит «исходником», из которого Google Play генерирует APK под каждое устройство.

Отсюда следуют два частых заблуждения, которые встречаются на собеседованиях:

Про подпись стоит сказать отдельно: при публикации через AAB вы обязательно используете Play App Signing — сервис Google, который хранит ключи подписи и подписывает сгенерированные APK. У этого есть и плюс, и ответственность: утерянный ключ перестаёт быть катастрофой (Google может выпустить обновление по резервному ключу), но доступ к аккаунту Play нужно беречь особенно.

Есть у бандла и практическое ограничение, о котором полезно знать: суммарный размер сжатых APK, которые скачает пользователь при установке (базовый APK плюс конфигурационные APK), не должен превышать 4 ГБ — об этом Play Console предупреждает при загрузке. На практике это редко становится проблемой, но при работе с тяжёлыми ассетами лучше помнить.

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

Вопросы на собеседовании

Тему APK/AAB спрашивают на стыке сборки и публикации — она быстро показывает, выпускал ли кандидат релизы или только писал код. Что нужно уметь сказать:

• APK — установочный формат, AAB — публикационный; AAB нельзя установить напрямую.
• Google Play генерирует и подписывает APK из бандла под каждое устройство — пользователи скачивают меньше данных.
• assembleRelease собирает APK, bundleRelease собирает AAB.
• Публикация в Play идёт через AAB, подпись — через Play App Signing.
• AAB даёт Feature Delivery и Asset Delivery, но не поддерживает .obb.

И типичный промах, который я слышу на собеседованиях регулярно:

Если спросят «зачем тогда APK вообще нужен» — отвечайте уверенно: APK остаётся конечным продуктом сборки. Из бандла Play собирает именно APK, и именно их устанавливают устройства. Дистрибуция вне Google Play (свой сайт, внутренние тесты, обходные площадки) — тоже через APK.

Полезно знать и рабочие сценарии, которые пригодятся в реальном проекте:

• Внутренняя раздача тестировщикам — собрали assembleRelease (или debug) и отправили APK в мессенджер или на внутренний сервер. AAB для этого не подходит: он не устанавливается.
• Локальная генерация APK из бандла — если нужно проверить, что именно Play соберёт из вашего AAB, используется официальный инструмент bundletool: он разворачивает бандл в набор APK на вашей машине, и поведение будет максимально близко к тому, что увидят пользователи Play.
• Публикация в Play — только AAB. Файл загружается в Play Console, остальное делает Google.

Меня зовут Рустем Бикбулатов, я senior Android-разработчик и ментор Яндекс Практикума, провожу технические собеседования. За время менторства у меня больше 100 учеников и разборов — темы сборки и публикации стабильно входят в список «слабых мест», которые мешают кандидатам с опытом 1–2 года перейти на уровень middle.

Итоги

APK и AAB — не конкуренты, а два этапа одной цепочки: вы публикуете AAB, Google Play превращает его в APK, пользователи устанавливают APK.

• APK — установочный пакет: подписанный, самодостаточный, один под все устройства.
• AAB — исходник для Play: не устанавливается, не подписывается разработчиком, генерирует APK под каждое устройство.
• Сборка: assembleRelease → APK, bundleRelease → AAB; подпись — через Play App Signing.

Если вы писали код, но релизы всегда выпускал кто-то другой, и теперь чувствуете пробелы в сборке и публикации — это нормальная точка роста. Напишите в Telegram, разберём вашу ситуацию и составим план подготовки.