Почему замена APK на Android App Bundle пугает разработчиков и экспертов

В ноябре прошлого года 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

— Tim Sweeney (@TimSweeneyEpic) June 30, 2021

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

Начнем с взаимодействия приложений. Вы когда-нибудь загружали приложение, которое блокирует функции за пейволом? Наверняка. Некоторые разработчики закрывают функции в покупках в приложении, но другие могут сделать отдельное платное приложение. Когда это дополнительное приложение будет установлено, основные функции приложения будут разблокированы.

Но что мешает просто установить такое дополнительное приложение из пиратского источника? У разработчиков есть много вариантов для защиты, но по крайней мере один предполагает использование разрешений, защищенных подписью. Скажем, основное приложение объявляет разрешение, защищенное подписью. Затем платное приложение-надстройка заявляет, что хочет использовать это разрешение. В идеале в дополнительном приложении также должна быть какая-то функция проверки лицензии, которая подключается к Интернету, чтобы убедиться, что пользователь легитимный.

Если оба приложения имеют одинаковую подпись, 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 реализует оба этих решения, то разработчику, который хочет использовать App Bundle, не придется передавать подписку в Google, а разработчику, чье приложение не получит особой выгоды от формата, вообще не придется его использовать. .

Ответы 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 смогут сохранять полный контроль над своими приложениями.

Источник