Что такое bundle app
Что такое Android App Bundle и в чём его отличие от APK
Наверное, все знают, что APK – это формат, в котором приложения для Android размещаются в Google Play и на сторонних платформах. Но если при загрузке из официального каталога установка происходит автоматически, и пользователь никак не взаимодействует с установочным файлом, то при использовании альтернативных площадок, всё происходит несколько иначе. Сначала вы скачиваете сам APK-файл и уже вручную его устанавливаете. Но некоторое время назад на альтернативных платформах, помимо привычных APK-файлов, стали появляться какие-то Android App Bundles. Разбираемся, что это и зачем вообще нужно.
Android App Bundle — это как APK, только лучше
Android App Bundle – это новый, так называемый «пакетный», формат приложений для Android. В отличие от APK, которые для успешной установки должны соответствовать параметрам смартфона, на который их устанавливают, AAB – это универсальный формат, который уже содержит в себе сведения обо всех устройствах и разных сочетаниях железа сразу.
Если вы откроете APKMirror – пожалуй, самый популярный альтернативный сайт с приложениями, — и перейдёте на страницу любого приложения, то увидите, что у него есть несколько разных версий APK. Каждая из них соответствует смартфонам с определёнными особенностями. Обычно это версия Android, тип процессора или показатель DPI, но бывают и другие.
Как установить Android App Bundle
Посмотрите, сколько APK-файлов у Instagram. Их все заменяет один пакет AAB
Android App Bundle представлены только в единственном экземпляре. Потому что они изначально созданы универсальными и совместимыми с различными устройствами, независимо от сочетаний их аппаратного обеспечения и технических характеристик. При установке пакет сам выдаст смартфону подходящий установочный файл, и тот его установит.
Что такое Camera2 API, зачем это нужно и как узнать, поддерживает ли её ваш смартфон
Поскольку Android App Bundle – это пакет различных компонентов, то они поставляются не в виде целостного файла, а в виде ZIP-архива. Это несёт как минимум одно существенное ограничение – AAB нельзя установить так же просто, как обычные APK-файлы просто по нажатию. С AAB это не прокатывает. Поэтому для их установки необходим специальный клиент, который всё распакует и установит вам на устройство.
Я для этой цели пользуюсь клиентом APKMirror. С ним установка Android App Bundle выглядит вот так:
Установить AAB как обычный APK-файл нельзя
Чем Android App Bundle лучше APK
Несмотря на то что что пакет AAB содержит базовый APK-файл, даже распаковав архив вручную, вы всё равно не сможете его установить. Дело в том, что пакет обычно включает в себя ещё ряд дополнительных компонентов, которые необходимы приложению для нормальной установки. Поэтому тут строго обязательно нужно-приложение установщик, которое работает со сторонними AAB. Так что Google Play для этой роли точно не годится.
В августе 2021 года Google полностью переходит на формат AAB
Может показаться, что всё это слишком сложно и запоминать всю последовательность действий, описанных выше, не имеет смысла. Однако это большое заблуждение, потому что уже в августе 2021 года Google откажется от использования классических APK. То есть все новые приложения и те, которые обновятся к тому времени, уже не будут иметь выделенных APK, а будут представлены на сторонних площадках только в виде AAB.
Google настаивает на использовании Android App Bundle, потому что они, несмотря на универсальность, более легковесны, чем классические APK, и их легче поддерживать. Формат AAB позволяет разработчикам создать только одну сборку приложения, которую будет проще обновлять, контролировать и совершенствовать. Так что учитесь работать с «бандлами», иначе останетесь без стороннего ПО.
Что такое Android App Bundle (AAB)
Возможно, Вы слышали термин «APK». Однако все более распространенным становится новый термин «Android App Bundle» (AAB). Так что же такое AAB и заменит ли он APK?
Что такое Android App Bundle
Начиная с августа 2021 года, Google будет требовать, чтобы все приложения Android, опубликованные в Play Store, использовали формат «Android App Bundle». Раньше приложения могли использовать формат AAB или старый формат APK.
AAB имеет все те же ресурсы, но также включает компоненты, называемые «Динамические функции» и «Пакеты активов». Преимущества этих функций заставляют Google отказываться от APK в пользу AAB.
Проще говоря, App Bundle включает в себя все компоненты для создания APK. Когда Вы загружаете App Bundle из Play Store, он создает APK, предназначенный для Вашего конкретного устройства.
Каковы преимущества AAB
Android App Bundle имеют несколько преимуществ. Прежде всего, AAB создают APK-файлы меньшего размера. Поскольку Bundle создает приложение специально для Вашего устройства, могут потребоваться не все компоненты, что приведет к уменьшению размеров файлов.
Также не все эти компоненты нужно загружать заранее. Концепция «динамической доставки» означает, что Вы изначально получаете приложение, которое может загружать и устанавливать новые функции по мере необходимости. Поэтому, если Вы никогда не используете определенные функции, они не загружаются на Ваше устройство.
Короче говоря, преимущество AAB в том, что они просто более гибкие и динамичные. Меньшие размеры файлов, более простая предварительная загрузка и предоставление компонентов по мере необходимости делают APK-файлы более разумными.
Заменят ли App Bundles файлы APK
Когда Google объявил, что для Play Store потребуются пакеты Android App Bundle вместо APK, возникло общее недоразумение: означает ли это, что Вы больше не сможете устанавливать APK на свое устройство? Ответ — нет.
Фактически, как объяснялось в разделе выше, App Bundle создают APK-файлы. APK — это то, что запускает Android, но AAB — это то, что разработчик загружает в Play Store.
App Bundles могут заменять APK-файлы в Play Store, но не на самих устройствах Android. Вы по-прежнему можете загружать APK-файлы на свое устройство, как всегда. Фактически, Вы также можете загружать неопубликованные файлы AAB. Будьте уверены, что это всего лишь изменение в Play Store, а не в том, как ОС Android работает с файлами приложений.
Новый способ публикации приложений с помощью Android App Bundle
На недавно прошедшей Google I/O 2018, среди множества нововведений, объявили также о добавлении нового формата приложений.
Этот формат получил название Android App Bundle и представляет собой улучшенный способ сборки вашего приложения. С его помощью можно легко оптимизировать размер приложения, при этом не нужно будет вносить какие-либо изменения в код. Android App Bundle включает весь скомпилированный код и ресурсы, отсеивая затем то, что не нужно конкретному устройству.
Важно! На данный момент Android App Bundle работает только в preview-версии Android Studio. Последняя версия Android Studio 3.2 Canary доступна здесь.
Формат Android App Bundle
Android App Bundle представляет собой файл (с расширением .aab), который загружается в Google. Каждый бандл включает скомпилированный код и ресурсы для всех модулей приложения и поддерживаемых конфигураций устройств.
Проще говоря, бандлы это подписанные ZIP-файлы, которые упорядочивают код и ресурсы приложения в модули.
Из этих модулей Google Play генерирует различные APK, которые предоставляются пользователям, такие как: базовые APK, dynamic feature APK, конфигурационные APK и (для устройств, которые не поддерживают разделённые APK) мульти-APK. Каталоги, окрашенные в синий цвет, представляют собой код и ресурсы, которые Google Play использует для создания конфигурационного APK для каждого модуля.
Примечание: бандл нужно создавать для каждого уникального приложения или applicationID. То есть, если вы используете несколько product flavor в своём приложении для создания различных APK, и каждая из этих веток использует уникальный applicationID, то вам нужно будет создать отдельный бандл для каждой ветки.
Код и ресурсы для каждого модуля организованы аналогично стандартным APK, и это логично, поскольку каждый из этих модулей может быть сгенерирован как отдельный APK. Ниже можно увидеть более подробное описание некоторых файлов и каталогов Android App Bundle:
Сборка App Bundle с помощью Android Studio
Создание бандла с помощью Android Studio очень похоже на создание APK. Для сборки достаточно выбрать в меню Build — Build Bundle(s)/APK(s) > Build Bundle(s) и IDE создаст бандл для выбранного варианта сборки и разместит его в каталоге
Если создаётся бандл для debug-версии приложения, Android Studio автоматически подпишет бандл с помощью отладочного ключа подписи. Для загрузки бандла в Google Play он должен быть подписан.
После того, как Android Studio завершит создание подписанного бандла, его можно будет открыть и проанализировать. Анализ бандла позволяет проверить содержимое и работает аналогично APK Analyzer.
Для создания App Bundle IDE использует тот же инструмент с открытыми исходным кодом, называемый bundletool, который Google Play использует для последующего преобразования бандла в подписанные APK.
Прежде чем загрузить бандл в консоль Google Play, его нужно подписать. Чтобы создать подписанный App Bundle, нужно выполнить следующие действия:
После того, как Android Studio завершит создание подписанного бандла, его можно будет найти и проанализировать, выбрав соответствующую опцию во всплывающем уведомлении. Если был выбран экспорт ключа подписи, то к нему можно будет быстро перейти, щёлкнув по стрелке вниз в правом нижнем углу всплывающего уведомления, чтобы развернуть его, и затем выбрав Show Exported Key File.
Загрузка App Bundle в консоль Google Play
После того, как бандл создан, его можно загрузить в Google Play для проверки, тестирования или публикации приложения. Прежде чем приступить к работе, следует соблюсти следующие условия:
Анализ APK с помощью проводника
Когда бандл загружен, Google Play автоматически генерирует разделённые APK и мульти-APK для всех конфигураций устройств, поддерживаемых приложением. В Play Console можно можно использовать App Bundle Explorer для просмотра всех вариантов APK, сгенерированных Google Play; анализа данных, таких как поддерживаемые устройства и экономия размера APK; загрузки созданных APK для тестирования.
Обновление приложения
После загрузки приложения в Play Console, для обновления приложения достаточно повысить код версии, а также создать и загрузить новый бандл. Затем Google Play сгенерирует обновлённые APK с новым кодом версии и будет предоставлять их по мере необходимости.
Заключение
Использование Android App Bundle даёт большие преимущества для оптимизации APK приложений. С помощью этого способа мы обновили одно из наших приложений, «Менеджер паролей от Wi-Fi сетей«, заменив в нём стандартный APK на App Bundle. Таким образом, размер APK файлов уменьшился на целый мегабайт, что является очень хорошим результатом.
Кроме того, Google на данный момент тестирует дополнение к App Bundle, Dynamic feature modules, с помощью которого можно разбивать базовый APK на части, которые будут докачиваться при необходимости, пока что эта технология находится в бета-версии.
Возможно, единственным недостатком банлдов на данный момент назвать необходимость использовать preview-версию Android Studio, однако эта проблема временная.
Android App Bundles. Как уменьшить размер вашего приложения?
Привет, Хабр! Сегодня расскажу, что такое Android App Bundles, как их использовать в реальном проекте и на сколько нам удалось уменьшить размер приложения, не прикладывая очень больших усилий.
Вступление. Что такое Android App Bundles?
Google Play использует ваш app bundle для создания и обслуживания оптимизированных APK-файлов для каждой конфигурации устройства, поэтому для запуска вашего приложения загружаются только код и ресурсы, необходимые для конкретного устройства. Вам больше не нужно создавать, подписывать и управлять несколькими APK-файлами, чтобы оптимизировать поддержку различных устройств, а пользователи получают более оптимизированные загрузки.
Ограничения Android App Bundles
Если при загрузке пакета приложений Play Console обнаружит, что размер любой из возможных загрузок вашего приложения или его on demand feature превышает 150 МБ, вы получите сообщение об ошибке.
Подготовка проекта к миграции
Прежде чем переходить к имплементации в проекте, пройдемся по основным этапам подготовки.
Используйте shrinking, обфускацию и оптимизацию вашего проекта, это позволит сократить размер приложения путем удаления неиспользуемого кода и ресурсов. Детальнее можно почитать в официальных гайдах.
Следуйте лучшим практикам, чтобы еще больше уменьшить размер приложения(использование drawable objects, использование WebP вместо jpg и png, и т.д.). Больше тут.
Рассмотрите возможность преобразования некоторого функционала, который используется только некоторыми из ваших пользователей, в dynamic feature modules, которые ваше приложение может загрузить позже по запросу. Имейте в виду, что для этого может потребоваться некоторый рефакторинг вашего приложения, поэтому сначала попробуйте другие предложения, описанные выше.
Используйте разделение ресурсов по папкам(drawables):
для векторной графики(svg) используйте папку drawable-nodpi, Система не масштабирует эти ресурсы независимо от плотности текущего экрана;
растровую графику распределяйте по папкам drawable-*dpi, для App Bundles не будет загружаться графика, не соответствующая размеру экрана.
Настройка базового модуля
App Bundle отличается от APK тем, что вы не можете развернуть его на устройстве. Это формат для публикации, который включает весь скомпилированный код и ресурсы вашего приложения в один артефакт сборки. После того, как вы загрузите App Bundle, подписанный релизным ключем, Google Play будет иметь все необходимое для создания и подписания APK-файлов вашего приложения и предоставления их пользователям.
Большинство проектов приложений не потребуют больших усилий для поддержки пакетов Android App Bundle. Это потому, что модуль, который включает код и ресурсы для базового APK вашего приложения, является стандартным модулем приложения, который вы получаете по умолчанию при создании нового проекта приложения в Android Studio. Модуль, к которому применяется application plugin ниже к своему build.gradle файлу, предоставляет код и ресурсы для основных функций вашего приложения.
Помимо предоставления основных функций для вашего приложения, базовый модуль также предоставляет множество конфигураций сборки и записей манифеста, которые влияют на весь проект вашего приложения.
Для большинства существующих проектов приложений вам не нужно ничего менять в конфигурации сборки вашего базового модуля. Однако, если вы планируете добавить feature modules в свой проект приложения или если вы ранее выпустили свое приложение с использованием нескольких APK, вам следует помнить о некоторых аспектах конфигурации сборки базового модуля. Вот так выглядит схема модулей при использовании App Bundles:
Код версии и обновления приложений
С пакетами Android App Bundle вам больше не нужно управлять кодами версий для нескольких APK, которые вы загружаете в Google Play. Вместо этого вы управляете только одним кодом версии в базовом модуле вашего приложения, как показано ниже:
После загрузки пакета приложений Google Play использует код версии в вашем базовом модуле, чтобы назначить один и тот же код версии всем APK, которые он генерирует из этого пакета. То есть, когда устройство загружает и устанавливает ваше приложение, все разделенные APK для этого приложения имеют один и тот же код версии.
Если вы хотите обновить свое приложение новым кодом или ресурсами, вы должны обновить код версии в базовом модуле вашего приложения и создать новый полный комплект приложения. Когда вы загружаете этот набор приложений в Google Play, он создает новый набор APK на основе кода версии, указанного в базовом модуле. Впоследствии, когда пользователи обновят ваше приложение, Google Play предоставит им обновленные версии всех APK, установленных в настоящее время на устройстве. То есть все установленные APK обновляются до кода новой версии.
Также стоит обратить внимание на следующие нюансы:
Релизная подпись приложения. Если вы включаете информацию о подписи в свои файлы сборки, вы должны включать ее только в файл конфигурации сборки базового модуля. Дополнительные сведения см. в разделе Настройка Gradle для подписи приложения.
Code shrinking. Если вы хотите включить сжатие кода для всего проекта приложения (включая его функциональные модули), вы должны сделать это из файла build.gradle базового модуля. То есть вы можете включить пользовательские правила ProGuard в feature module, но minifyEnabled свойство в конфигурациях сборки feature module игнорируется.
Блок splits игнорируется. При компиляции App Bundle, Gradle игнорирует свойства в android.splits блоке. Если вы хотите контролировать, какие типы APK-файлов конфигурации поддерживает ваш app bundle, вместо этого используйте android.bundle.
Итак, перейдем собственно к настройке gradle-файла вашего базового модуля:
Блок language.
Google Play определяет, какие языковые ресурсы устанавливать вместе с приложением, на основе выбора языка в настройках устройства пользователя. Представьте пользователя, который меняет свой системный язык по умолчанию после того, как уже загрузил ваше приложение. Если ваше приложение поддерживает этот язык, устройство запрашивает и загружает дополнительные APK-файлы конфигурации для этих языковых ресурсов из Google Play.
Для приложений, которые предлагают средство выбора языка внутри приложения и динамически изменяют язык приложения, независимо от языковых настроек системного уровня, необходимо внести некоторые изменения, чтобы предотвратить сбои из-за отсутствия ресурсов. Задайте для android.bundle.language.enableSplit свойства значение false или рассмотрите возможность реализации языковой загрузки по запросу с использованием библиотеки Play Core.
Другими словами, если у вас поддержка нескольких языков и есть возможность менять язык внутри приложения, вам необходимо для блока language задать enableSplit = false и реализовать подгрузку нужных языков, как описано в разделе Download additional language resources.
Блок destiny.
Этот блок отвечает за подгрузку графики только для нужной плотности экрана(то что мы делали на этапе подготовки к миграции, раскладывали ресурсы по попкам drawable-*dpi).
Параметр enableSplit отвечает за загрузку графики. Если выставить enableSplit = true, будет загружена графика только для текущей плотности экрана.
Блок abi.
В разных устройствах Android используются разные процессоры, которые, в свою очередь, поддерживают разные наборы инструкций. Каждая комбинация ЦП и набора команд имеет собственный Application Binary Interface(ABI).
Параметр enableSplit отвечает за загрузку ABI. Если выставить enableSplit = true, будет загружен набор инструкций только для текущего процессора.
В качестве итога скажу, что более 1 миллиона приложений и игр используют пакеты приложений для публикации своих производственных выпусков в Google Play, включая большинство популярных приложений, что составляет миллиарды активных установок. Если вы используете Google Play для установки приложений, многие приложения на вашем устройстве были опубликованы в виде App Bundles.
В нашем же случае, мы значительно смогли уменьшить размер нашего приложения. Размер при скачивании уменьшился с 44.22МБ до 27.61МБ(может варьироваться в зависимости от модели устройства, данные для Samsung S21):
Download APK-version 
Download AAB-version
Размер чистой только что установленной версии уменьшился с 117МБ до 72.52МБ (может варьироваться в зависимости от модели устройства, данные для Samsung S21):
Installed APK-version 
Installed AAB-version
Спасибо за внимание! Делитесь в комментариях, на сколько вам удалось уменьшить размер приложения =)
Почему замена APK на Android App Bundle пугает разработчиков и экспертов
В этой статье мы рассмотрим критику, которая связана с переходом на Android App Bundle, некоторые предлагаемые решения, а также об отношении Google к ним.
В ноябре прошлого года Google объявил, что разработчикам потребуется публиковать новые приложения в Play Store, используя формат Android App Bundle (AAB) вместо APK. На днях Google напомнил разработчикам об этом предстоящем требовании, вызвав бурю споров среди пользователей, которые считают, что Google убивает APK, запрещает стороннюю загрузку приложений, препятствует работе сторонних магазинов приложений и т.д.
Это правда, что Android App Bundle сильно отличаются от классического формата APK, к которому вы, возможно, привыкли, как пользователь и как разработчик. Хотя использование App Bundle дает немало преимуществ, есть один ключевой аспект их создания, который справедливо беспокоит некоторых разработчиков и экспертов по безопасности.
В этой статье мы рассмотрим критику, которая связана с переходом на Android App Bundle, некоторые предлагаемые решения, а также об отношении Google к ним.
Шаг назад: APK
Прежде чем перейти к сути, нам нужно немного поговорить о том, как в целом работает распространение приложений на Android. Если вы уже знаете, как работают подписи приложений и App Bundles, вы можете пропустить эту часть.
APK-файлы
По большей части приложения на Android распространяются в файлах APK. APK-файл содержит весь код и ресурсы приложения, а также несет в себе определенные функции безопасности. Когда APK установлен, он просто копируется в определенную папку и добавляется во внутреннюю базу данных установленных приложений.
Подписи
Во время установки также проверяется подпись приложения, чтобы убедиться, что она действительна. Если приложение уже установлено, Android сравнивает подпись нового приложения с уже установленной. Если подпись недействительна или не совпадает, Android откажется устанавливать приложение.
Эта проверка подписи является важной частью безопасности Android. Она гарантирует, что устанавливаемое вами приложение является действительным и, по крайней мере, из того же источника, что и то, которое вы уже установили. Например, если вы устанавливаете, скажем, мое приложение Lockscreen Widgets из Play Store, вы можете быть достаточно уверены, что это я подписал его и что оно подлинное. Если после этого вы попытаетесь установить обновление для виджетов экрана блокировки с какого-нибудь стороннего сайта, и это не удастся, вы узнаете, что кто-то подделал этот APK, возможно, чтобы добавить вредоносное ПО.
Ключ, используемый для подписи приложения, (в идеале) никогда не публикуется. Он известен как “закрытый ключ”. Закрытый ключ используется для генерации ключа, указанного в подписи приложения, известного как открытый ключ. Это то, что Android и магазины приложений используют для проверки действительности приложения. Я не буду вдаваться в подробности, как именно вы можете сгенерировать открытый ключ, не раскрывая закрытый ключ, поскольку в этом много математических вычислений. Если вам нужна дополнительная информация, ознакомьтесь с документацией Google по подписанию APK-файлов или изучите вопрос в Википедии.
Еще одна особенность подписей приложений — это возможность ограничивать разрешения только для приложений с соответствующими подписями. Android внутри делает это для множества функций, при этом только приложения, подписанные тем же ключом, что и платформа, могут получить доступ к определенным функциям.
Пакеты приложений (App Bundles)
Итак, теперь, когда мы сделали краткий обзор APK-файлов и подписей, давайте поговорим о App Bundle. Здесь на сцену выходят ресурсы APK. Ресурсы — это макеты экранов, изображения, аудио и т.д. По сути, это все, что не является кодом. Чтобы лучше поддерживать разные конфигурации и разные языки, разработчики могут создавать несколько версий одного и того же ресурса, которые используются в зависимости от устройства и языка.
Но в APK все эти ресурсы уже существуют, независимо от того, что за устройство вы используете. И они занимают место. В зависимости от сложности вашего приложения на многих устройствах может быть много неиспользуемых ресурсов. Вот для чего созданы бандлы. Разработчики могут создать App Bundle так же, как APK, и такой App Bundle затем может быть загружен в Play Store, как и APK.
Google использует этот пакет приложений для создания множества разных APK для разных конфигураций устройств. Каждый бандл содержит только ресурсы, необходимые для определенной конфигурации. Когда пользователь загружает приложение, ему выдается сгенерированный APK, соответствующий его конфигурации. Это помогает уменьшить объем как загружаемых, так и устанавливаемых приложений, экономя трафик и пространство для хранения.
Конечно, установка такого специфического APK-файла, сделанного конкретно для вашего устройства означает, что вам сложнее просто скопировать и установить его на другое устройство. В зависимости от точки зрения, это может быть хорошо или плохо. С одной стороны, это затрудняет пиратство, поскольку у пользователей больше нет целого приложения. С другой стороны, это затрудняет законное архивирование приложений по той же причине.
Подпись приложений
Поскольку Android App Bundle не являются APK-файлами, вы не можете просто открыть файл AAB и установить его прямо на устройство. Когда вы загружаете такой пакет в Play Store, Google использует этот пакет для создания разных (неподписанных) APK-файлов. Эти APK-файлы необходимо подписать перед установкой.
Вместо того, чтобы просить разработчика подписать и повторно загрузить эти сгенерированные APK, Google сам управляет подписью. Play Store либо использует новый ключ, который он создает, либо запрашивает у разработчика ключ, который они используют для подписи APK. В любом случае Google сам выполняет публичную подпись вместо разработчика и предоставляет ключ для загрузки. Google использует этот ключ для внутренней проверки, является ли пакет приложения (или в некоторых случаях APK), который загружает разработчик, правильным.
Если ключ загрузки скомпрометирован или утерян, разработчики могут запросить новый, а ключ подписи, используемый для распространения приложения, останется неизменным.
Подписание приложений — это гораздо более сложный процесс, но это то, что имеет отношение к этой статье. Если вы хотите, вы можете узнать больше о App Bundle и App Signing в этой статье на Medium Войтека Каличинского.
Критика App Bundle
В теории и на практике App Bundle довольно хороши. Они уменьшают потребляемый трафик и размер установки, при этом пользователю ничего не нужно делать. Но из-за того, как это реализовано, некоторые разработчики и исследователи безопасности в последние несколько месяцев выразили обеспокоенность. Прежде чем резюмировать эти опасения, я хочу воспользоваться моментом, чтобы сказать, что большая часть того, что написано ниже, непосредственно основано на серии статей разработчика Марка Мерфи из CommonsWare. Вы обязательно должны проверить его статьи, поскольку они содержат больше деталей и критику с точки зрения разработчика.
Безопасность
В классической модели распространения разработчик сохраняет ключ, который он использует для подписи APK, у себя. Он никогда не публикуется, и только авторизованные люди должны иметь к нему доступ. Это гарантирует, что только эти люди могут создать правильный работющий APK.
Но если вы используете App Bundle в Play Store, Google — это тот, кто управляет ключом, которым подписываются APK-файлы, получаемые пользователями. По умолчанию для новых приложений, загружаемых в Google Play, начиная с августа 2021 года, Google создает собственный ключ распространения, который хранится в тайне от разработчика.
Разработчики, отправляющие новые приложения, по умолчанию будут использовать Google для управления своим закрытым ключом, хотя разработчики, отправляющие обновления для существующих приложений, могут продолжать использовать APK, создавая новый ключ, который Google будет использовать для новых пользователей. Существующим приложениям не требуется переключаться с распространения APK на пакеты Android App Bundle, хотя этот вариант доступен для них, если они захотят. После некоторого отката Google даже позволит загрузить ваш собственный закрытый ключ в Google для подписи как для новых, так и для существующих приложений. Ни одна из этих ситуаций не идеальна, поскольку у Google все равно будет доступ к вашему закрытому ключу, если вы захотите использовать пакеты Android App Bundle (а у разработчиков нет выбора, если они хотят отправить новое приложение после августа 2021 года!).
Хотя мы уверены, что Google очень серьезно относится к безопасности, на Земле нет компании, застрахованной от утечки данных. Если ключ, который Google использует для подписи вашего приложения для распространения, пострадает, то любой может подписать свою версию вашего приложения и сделать так, чтобы она выглядела так, как будто она была подписана вами. И некоторых разработчиков и экспертов по безопасности такая возможность не радует. Да, это очень, вероятность этого очень мала, но тот факт, что это вообще возможно, пугает некоторых в сообществе информационной безопасности.
Если разработчики подписывают APK-файлы Android, каждый может проверить APK-файлы через Google Play, слепое доверие не требуется. Это нормальная конструкция, обеспечивающая поддающуюся проверке безопасность. Пакеты приложений меняют ситуацию с ног на голову и, похоже, структурированы таким образом, чтобы способствовать привязке к поставщику. Существует множество альтернативных технических подходов, которые предоставляют небольшие APK-файлы, все еще подписанные разработчиками, но они не отдают предпочтение Play. Например, все варианты APK могут быть созданы и подписаны разработчиком, а затем загружены в любой магазин приложений, — Ханс-Кристоф Штайнер, участник Guardian Project.
Конечно, есть аргументы в пользу того, что лучше оставить безопасное хранилище закрытых ключей в руках Google или отдельных разработчиков. Но эти разработчики (вероятно) обычно не используют центральное хранилище для своих ключей. Вынуждая разработчиков использовать функцию подписи приложений Play, злоумышленник может только один раз взломать систему безопасности Google и получить тысячи или миллионы ключей.
Как бы то ни было, вот что Google говорит о том, как он защищает ваш ключ подписи в своей инфраструктуре:
Когда вы используете Play App Signing, ваши ключи хранятся в той же инфраструктуре, которую Google использует для хранения собственных ключей.
Доступ к ключу регулируется строгими списками ACL и журналами аудита для всех операций с контролем несанкционированного доступа.
Все артефакты, созданные и подписанные ключом разработчика, доступны вам в консоли Google Play для проверки/подтверждения.
Кроме того, чтобы предотвратить потерю ключей, мы очень часто делаем резервные копии нашего основного хранилища. Эти резервные копии надежно зашифрованы, и мы регулярно тестируем восстановление из этих резервных копий.
Если вы хотите узнать о технической инфраструктуре Google, прочтите официальные документы по безопасности Google Cloud.
Как бы хорошо это не звучало, потери и кражи возможны. А журналы аудита только помогают предотвратить атаки в будущем, но не не вернут взломанные ключи.
Возможность несанкционированных изменений
Одна большая проблема с тем, как Google использует App Bundle, — это возможность неавторизованных модификаций в приложениях. Процесс создания APK из App Bundle по своей сути включает модификации, поскольку Google должен вручную создавать каждый APK. Хотя Google пообещал, что не будет внедрять или изменять код, проблема с процессом App Bundle заключается в том, что он может это делать.
Вот несколько примеров того, что может сделать компания, занимающая положение Google:
Допустим, есть приложение для безопасного обмена сообщениями, которое люди используют, чтобы общаться без риска наблюдения со стороны правительства. Это может быть невероятно полезным инструментом для людей, протестующих против авторитарного правительства, или даже для людей, которые просто хотят сохранить свою конфиденциальность. Это правительство, желая иметь возможность видеть, что говорят пользователи приложения, может попытаться заставить Google добавить бэкдор в код приложения.
Этот пример достаточно безобиден, но некоторых людей он беспокоит. Допустим, есть приложение, которое скачивают миллионы пользователей в день, но в нем нет рекламы или аналитики. такое приложение — огромный источник данных без возможности доступа к ним. Google, будучи рекламной компанией, может захотеть получить доступ к этим данным.
В классической модели распространения приложений APK, Google не может изменить приложения без изменения подписи. Если Google изменит подпись, особенно в популярном приложении, люди заметят, что обновление не установится. Но с помощью App Bundle и App Signing Google может незаметно внедрять собственный код в приложения перед их распространением. Подпись не изменится, потому что ключ подписи будет принадлежать Google.
Чтобы было ясно, эти примеры невероятно маловероятны. Google стремится просто полностью уйти с проблемных рынков, а не адаптироваться. Но даже если это маловероятно, все же это возможно. То, что компания обещает чего-то не делать, не означает, что этого не произойдет.
Прозрачность кода (Code Transparency)
Узнав об этих опасениях, Google на этой неделе представил новую функцию под названием Code Transparency for App Bundles. Прозрачность кода позволяет разработчику создать вторую подпись, которая поставляется пользователям вместе с приложением. Эта дополнительная подпись должна быть создана из отдельного закрытого ключа, к которому имеет доступ только разработчик. Однако у этого метода есть некоторые ограничения.
Прозрачность кода распространяется только на код. Это может показаться очевидным с учетом названия, но это также означает, что оно не позволяет пользователям проверять ресурсы, манифест или что-либо еще, кроме файла DEX или нативной библиотеки. Хотя злонамеренные модификации файлов, не связанных с кодом, обычно оказывают гораздо меньшее влияние, это все же брешь в безопасности приложения.
Еще одна проблема с Code Transparency заключается в отсутствии встроенной проверки. Во-первых, это дополнительная функция, поэтому разработчики должны не забывать включать ее в каждый новый загружаемый APK-файл. На данный момент это нужно делать из командной строки и с помощью версии bundletool, которой нет в Android Studio. Даже когда разработчик включает его, Android не имеет встроенной проверки, чтобы убедиться, что манифест прозрачности кода соответствует коду в приложении.
Конечный пользователь может проверить свое приложение, сравнив манифест с открытым ключом, который может предоставить разработчик, или отправив APK разработчику для проверки.
Хотя прозрачность кода позволяет подтвердить, что код в приложении не изменен, она не включает никаких проверок для других частей приложения. В этом процессе также отсутствует внутреннее доверие. Вы могли бы возразить, что если вы не доверяете Google, вы, вероятно, справитесь с задачей независимой проверки, но зачем вам это нужно?
Есть и другие проблемы с функцией прозрачности кода, как указал Марк Мерфи из CommonsWare. Я рекомендую прочитать его статью для более глубокого анализа этой функции.
Удобство и выбор разработчика
Третья (и последняя для этой статьи) причина, по которой некоторые разработчики не согласны с App Bundles, — это ограниченное удобство и выбор.
Если разработчик создает новое приложение в Play Store после того, как Google начинает требовать App Bundle, и он выбирает вариант по умолчанию, позволяющий Google управлять ключом подписи, у него никогда не будет доступа к этому ключу. Если этот же разработчик затем захочет распространить это приложение в другом магазине приложений, ему придется использовать свой собственный ключ, который не будет совпадать с ключом Google.
Это означает, что пользователям придется устанавливать и обновлять версию из Google Play или из сторонних источников. Если они захотят изменить источник, они должны будут полностью удалить приложение, что может привести к потере данных. Агрегаторам APK, таким как APKMirror, также придется иметь дело с несколькими официальными подписями для одного и того же приложения. (Технически они уже должны это сделать, потому что App Signing позволяет вам создать новый, более безопасный ключ для новых пользователей, но для этого и и других сайтов станет только хуже, когда всем придется делать это.)
В ответ на эту проблему Google использует проводник App Bundle или Artifact Explorer в Play Console, чтобы скачать полученные APK, полученные из оригинального бандла. Как и в случае с прозрачностью кода, это не полное решение. APK-файлы, загруженные из Play Console, будут разделены для разных устройств. Play Console поддерживает загрузку нескольких APK-файлов для одной версии одного приложения, но многие другие каналы распространения этого не делают.
Таким образом, многие преимущества использования App Bundle исчезают, когда разработчики работают с несколькими магазинами, что затрудняет распространение. В связи с новостями о том, что Windows 11 получает поддержку приложений Android благодаря Amazon Appstore, некоторые считают, что требование App Bundles лишит разработчиков стимулов к распространению на Amazon. Конечно, в первую очередь Google заботится о собственном магазине приложений, но именно из-за этого они оказались в затруднительном положении, когда конкуренты вынудили их внести небольшие примирительные изменения в работу сторонних магазинов приложений на Android.
Relevant: Epic’s direct distribution of Fortnite on Android is via APK. And Microsoft’s new Windows 11 support for Android apps is based on APKs.https://t.co/2stinObIsf
Пара проблем, связанных с несколькими магазинами, — это взаимодействие приложений и быстрое тестирование.
Начнем с взаимодействия приложений. Вы когда-нибудь загружали приложение, которое блокирует функции за пейволом? Наверняка. Некоторые разработчики закрывают функции в покупках в приложении, но другие могут сделать отдельное платное приложение. Когда это дополнительное приложение будет установлено, основные функции приложения будут разблокированы.
Но что мешает просто установить такое дополнительное приложение из пиратского источника? У разработчиков есть много вариантов для защиты, но по крайней мере один предполагает использование разрешений, защищенных подписью. Скажем, основное приложение объявляет разрешение, защищенное подписью. Затем платное приложение-надстройка заявляет, что хочет использовать это разрешение. В идеале в дополнительном приложении также должна быть какая-то функция проверки лицензии, которая подключается к Интернету, чтобы убедиться, что пользователь легитимный.
Если оба приложения имеют одинаковую подпись, Android предоставит разрешение приложению-дополнению, и проверки защиты от пиратства пройдут. Если у дополнительного приложения нет нужной подписи, разрешение не будет предоставлено, и проверка не будет выполнена.
В классической модели распространения APK пользователь может получить любое приложение из любого законного источника и закончить с этим. В текущей модели App Bundle по умолчанию подписи в основном и дополнительных приложениях не совпадают. Google создает уникальный ключ для каждого приложения. Разработчик всегда может отказаться от разрешения, защищенного подписью, и использовать прямую проверку хэша подписи, но это намного менее безопасно.
А потом идет другое испытание. Пользователи постоянно пишут разработчикам сообщения о проблемах в их приложениях. Иногда эти проблемы являются простыми в исправлении — воспроизвести проблему, найти проблему, исправить ее и загрузить новую версию. Но иногда это не так. Иногда разработчики не могут воспроизвести проблему. Они могут исправить то, что, по их мнению, является проблемой, но затем пользователь должен ее протестировать. Теперь предположим, что пользователь установил приложение через Google Play.
С помощью модели APK разработчик может изменить код, создать и подписать новый APK и отправить его конкретному пользователю для тестирования. Поскольку подпись тестового APK совпадает с подписью, установленной пользователем, это простой процесс для обновления, тестирования и отправки отчета. С App Bundle все разваливается.
Поскольку Google сам подписывает APK-файл, изначально установленный пользователем, он не будет соответствовать подписи APK-файла, отправленного разработчиком. Если это приложение будет опубликовано после истечения крайнего срока для внедрения App Bundles, разработчик не получит доступа даже к ключам, которые использует Google. Для тестирования пользователю необходимо будет удалить текущее приложение перед установкой тестовой версии.
Возникает куча проблем. Во-первых, неудобство как со стороны разработчика, так и со стороны пользователя. Удалять приложение только для того, чтобы проверить исправление, неинтересно. А если проблема исчезнет? Были ли это изменения, внесенные разработчиком, или это было связано с тем, что пользователь эффективно очистил данные приложения? В Play Store есть внутреннее тестирование, которое, как предполагается, позволяет разработчикам выполнять быстрые сборки и распространение, но для этого требуется, чтобы пользователь сначала удалил релизную версию. На самом деле это ничего не исправляет.
Если все это звучит как набор гипотетической чепухи, вот очень реальный пример разработчика, у которого возникнут эти проблемы, если он позволит Google сгенерировать закрытый ключ: Жоао Диас. Он разработчик Tasker, а также целого ряда плагинов, включая пакет AutoApps. С новым требованием App Bundles цикл разработки Жоао может стать намного сложнее, по крайней мере, для новых приложений. Отправлять тестовые версии напрямую будет менее удобно. Проверка лицензий будет менее эффективной.
Это может прозвучать как частный пограничный случай, но Жоао не похож на небольшого разработчика, и, вероятно, он не одинок. В Play Store есть много приложений, которые полагаются на проверку подписи для обнаружения нелегитимных пользователей.
Конечно, с новой возможностью для разработчиков загружать свои собственные ключи подписи в Google эти проблемы, по крайней мере, несколько смягчаются. Но разработчики должны включить эту опцию для каждого приложения. В противном случае система перестанет работать, и для оперативной поддержки потребуется загрузить пакет в Google и дождаться создания APK-файлов, прежде чем отправлять пользователю нужный. Кроме того, это по-прежнему означает, что разработчики должны поделиться своим закрытым ключом, что возвращает нас к проблемам, которые мы обсуждали ранее.
Решения
Это старая проблема, поскольку требования к App Bundle были опубликованы много месяцев назад, поэтому было предложено довольно много решений за это время.
Одно из решений — избежать необходимости в Play App Signing. Вместо создания App Bundle, который Google затем преобразует в APK-файлы и подписывает, эту обработку может выполнять Android Studio. Затем разработчики могут просто загрузить ZIP-файл с локально подписанными APK-файлами для каждой конфигурации, созданной Google.
С этим решением Google вообще не потребуется доступ к ключам разработчиков. Этот процесс будет очень похож на классическую модель распространения APK, но будет включать несколько APK меньшего размера, а не один.
Другое решение — просто не требовать использования App Bundle и продолжать разрешать разработчикам загружать локально подписанные APK. Хотя App Bundle могут быть более удобными для пользователя во многих случаях, некоторые приложения на самом деле не выигрывают от разделения по конфигурации с минимальным уменьшением размера.
Ответы Google
Самостоятельно подписание
Когда их впервые спросили о разрешении разработчикам подписывать пакеты приложений, Google ответил очень уклончиво:
«Я кратко рассказал о требовании в следующем году для новых приложений использовать пакеты приложений, и одна вещь, которая идет с этим, заключается в том, что в дальнейшем нам потребуется подписывание приложений в Play. Таким образом, разработчикам нужно будет либо сгенерировать ключ подписи приложения в Play, либо загрузить свой собственный ключ в Play… потому что это предварительное условие для App Bundle. Мы слышали от разработчиков, что некоторые из них просто не хотят этого делать. Они не хотят, чтобы ключи управлялись Play. В настоящее время это невозможно, если вы хотите использовать наборы App Bundle.
Но мы услышали эту обратную связь, и… Я не могу сейчас ни о чем говорить, нам не о чем сообщать, но мы ищем способы облегчить некоторые из этих опасений. Необязательно разрешать хранить свой собственный ключ при загрузке пакетов. Мы рассматриваем разные варианты. У нас просто нет решения, о котором можно было бы объявить прямо сейчас. Но до выполнения требования у нас еще около года, поэтому я очень надеюсь, что у нас будет ответ для разработчиков».
Это было в конце ноября прошлого года, и вроде бы ничего не произошло. Поскольку до вступления в силу требования о App Bundle осталось всего несколько месяцев, разработчики все еще не могут подписать свои собственные приложения. Хотя теперь Google позволил загружать собственный ключ как для новых, так и для существующих приложений, это по-прежнему лишает разработчика управления подписью.
Изменения кода
Хотя Google специально пообещал, что Play Store не будет изменять код приложения, обещание не является гарантией. При использовании App Bundle и App Signing отсутствуют известные нам технические ограничения, мешающие Google изменять загруженные приложения перед распространением.
Google представил Code Transparency в качестве дополнительной функции, и, хотя это в некоторой степени помогает, у функции есть немало проблем, как мы обсуждали ранее.
Самодельные пакеты
Когда Google спросили о разрешении разработчикам создавать свои собственные «пакеты» (ZIP-файлы, содержащие разделенные APK), ответ был в основном «мы не собираемся этого делать».
Интересно, что Google оправдывается тем, что это усложнит публикацию. Однако Google по-прежнему может автоматизировать этот процесс как часть диалога при создании APK в Android Studio. Кроме того, если рассматриваемое приложение распространяется в нескольких магазинах, это фактически упростит процесс публикации, поскольку разработчикам не придется управлять несколькими ключами подписи и разбираться с жалобами от пользователей.
А с введением Code Transparency кажется, что сложность в конце концов перестала быть проблемой. Code Transparency, по крайней мере на данный момент, требует, чтобы разработчик использовал инструмент командной строки, а пользователи явно проверяли действительность приложения, которое они получают. Это сложнее, чем процесс самостоятельного создания пакетов, и непонятно, почему именно это решение предпочитает Google.
Что дальше
App Bundles станут обязательным форматом распространения для новых приложений, представленных в Google Play, начиная с 1 августа. Хотя Google, по крайней мере, в какой-то мере решил большинство проблем, поднятых разработчиками и экспертами по безопасности, ответы оставляют желать лучшего. У App Bundle как формата распространения следующего поколения, есть много очевидных преимуществ, но всегда будут сохраняться проблемы с предоставлением частичного или полного контроля над подписью приложений Google.
Ответ и усилия Google, безусловно, ценятся, но некоторые, например Марк Мерфи, считают, что они не продвинулись достаточно далеко. Поскольку такие решения, как самодельные пакеты, не внедряются, а крайний срок для пакетов Android App Bundle быстро приближается, не похоже, что разработчики в Google Play смогут сохранять полный контроль над своими приложениями.