Google Play вскоре заставит разработчиков загружать пакеты приложений вместо APK, что вызывает неудобные вопросы безопасности по поводу этого требования.
В прошлом ноябре, Google объявил что разработчики будут обязаны публиковать новые приложения в Play Store, используя формат Android App Bundle (AAB) вместо APK. Буквально на днях Google напомнил разработчикам об этом предстоящем требовании, вызвав бурю споров. от пользователей, которые считают, что Google убивает APK, устраняет неопубликованную загрузку, препятствует работе сторонних магазинов приложений и еще много чего.
Это правда, что пакеты приложений Android довольно сильно отличаются от классического формата APK, к которому вы, возможно, привыкли как пользователь, так и разработчик. Несмотря на то, что использование пакетов приложений имеет немало преимуществ, есть один ключевой аспект их создания, который справедливо беспокоит некоторых разработчиков и экспертов по безопасности.
В этой статье мы рассмотрим критические замечания по поводу перехода на пакеты приложений Android, а также некоторые предлагаемые решения, а также поговорим о предлагаемом Google решении этих проблем.
Фон
Однако прежде чем это произойдет, нам нужно немного поговорить о том, как в целом работает распространение приложений на Android. Если вы уже знаете, как работают подписывание приложений и пакеты приложений, вы можете пропустить эту часть.
APK-файлы
По большей части приложения на Android распространяются внутри APK-файлов. APK-файл содержит весь код и ресурсы приложения, а также некоторые функции безопасности, такие как манифест подписи. Когда APK установлен, он просто копируется в определенную папку и добавляется во внутреннюю базу данных установленных приложений.
Подписи
Во время установки подпись этого приложения также проверяется, чтобы убедиться в ее действительности. Если приложение уже установлено, Android сверяет подпись нового приложения с уже установленной. Если подпись недействительна или не совпадает, Android откажется устанавливать приложение.
Проверка подписи является важной частью безопасности в Android. Он гарантирует, что устанавливаемое вами приложение является действительным и, по крайней мере, из того же источника, что и то, которое вы уже установили. Например, если вы устанавливаете, скажем, мое приложение «Виджеты экрана блокировки» из Play Store, вы можете быть достаточно уверены, что это я подписал его и что оно подлинное. Если затем вы попытаетесь установить обновление для виджетов блокировки экрана с какого-то сомнительного стороннего сайта и это не удастся, вы будете знать, что кто-то вмешался в этот APK, возможно, чтобы добавить вредоносное ПО.
Ключ, используемый для подписи приложения (в идеале) никогда публично выпущен. Это известно как закрытый ключ. Затем закрытый ключ используется для создания ключа, показанного в подписи приложения, известного как открытый ключ. Это то, что магазины Android и приложений используют для проверки достоверности приложения. Я не буду вдаваться в подробности, как именно можно сгенерировать открытый ключ, не раскрывая закрытый ключ, поскольку это требует большого количества математических вычислений по шифрованию. Если хотите подробнее, посмотрите Документация Google по подписанию APK или проведите исследование односторонних математических функций.
Еще одна особенность подписей приложений — возможность ограничивать разрешения только для приложений с совпадающими подписями. Android делает это внутренне для многих функций, причем только приложения, подписанные тем же ключом, что и платформа, могут получить доступ к определенным функциям.
Пакеты приложений
Итак, теперь, когда мы дали краткий обзор APK и сигнатур, давайте поговорим о App Bundles. Здесь на помощь приходят ресурсы APK. Ресурсы — это такие вещи, как макеты, изображения, аудио и т. д. По сути, это все, что не является кодом. Чтобы лучше поддерживать различные конфигурации дисплея и разные языки, разработчики могут создавать несколько версий одного и того же ресурса, которые используются в зависимости от устройства и языка.
Но в APK присутствуют все эти ресурсы, независимо от того, какие вы используете. И они занимают место. В зависимости от сложности вашего приложения на многих устройствах может быть много неиспользуемых ресурсов. Именно для решения этой проблемы созданы пакеты приложений. Разработчики могут создать пакет приложений так же, как APK, и затем этот пакет приложений можно загрузить в Play Store, как это делает APK.
Затем Google использует этот пакет приложений для создания целой группы различных APK для разных конфигураций устройств. Каждый пакет приложений содержит только ресурсы, необходимые для этой конфигурации. Когда пользователь загружает это приложение, ему предоставляется сгенерированный APK, соответствующий его конфигурации. Это помогает уменьшить размер загрузки и установки приложений, экономя пропускную способность и место для хранения.
Конечно, установка APK, специфичного для вашего устройства, означает, что вам сложнее просто скопировать его на другое устройство и без проблем установить. В зависимости от вашей точки зрения, это может быть хорошо или плохо. С одной стороны, это усложняет пиратство, поскольку у пользователей больше нет всего приложения. С другой стороны, по той же причине это затрудняет законное архивирование приложений.
Подписание приложений
Поскольку пакеты приложений Android не являются APK-файлами, вы не можете просто открыть файл AAB и установить его непосредственно на устройство. Когда вы загружаете его в Play Store, Google использует этот пакет для создания различных (неподписанных) APK-файлов. Эти APK-файлы необходимо подписать, прежде чем их можно будет установить.
Вместо того, чтобы просить разработчика подписать и повторно загрузить сгенерированные APK, Google сам управляет подписью. Play Store либо использует новый ключ, который он создает, либо запрашивает у разработчика ключ, который они используют для подписи. APK-файлы. В любом из вариантов Google выполняет публичную подпись для разработчика и обеспечивает загрузку ключ. Google использует ключ загрузки для внутренней проверки и проверяет, подходит ли разработчик App Bundle (или в некоторых случаях APK), который загружает разработчик.
Если ключ загрузки скомпрометирован или утерян, разработчики могут запросить новый, а ключ подписи, используемый для распространения приложения, останется неизменным.
Подписание приложений включает в себя гораздо больше, но именно это имеет отношение к данной статье. Если хотите, вы можете узнать больше о App Bundle и App Signing на странице эта статья Medium от Войтека Каличинского.
Критика
В теории и на практике пакеты приложений довольно хороши. Они сокращают использование данных и размер установки, причем пользователю не нужно ничего делать. Но из-за того, как это реализовано, некоторые разработчики и исследователи безопасности в последние несколько месяцев выразили обеспокоенность. Прежде чем подвести итог этим опасениям, я хочу воспользоваться моментом и сказать, что большая часть того, что написано ниже, напрямую на основе серии статей разработчик Марк Мерфи из CommonsWare. Вам обязательно следует ознакомиться с его статьями, поскольку в них содержится более подробная информация и критика с точки зрения разработчика.
Безопасность
В классической модели распространения разработчик сохраняет ключ, который он использует для подписи APK, в секрете. Он никогда не публикуется, и доступ к нему должны иметь только авторизованные люди. Это гарантирует, что только эти люди смогут создать действительный APK.
Но если вы используете пакеты приложений в Play Store, именно Google управляет ключом, которым подписываются пользователи APK. по умолчанию поведение новых приложений, загруженных в Google Play начиная с августа 2021 г. заключается в том, что Google должен создать свой собственный ключ распространения, который будет храниться в тайне от разработчика.
Разработчики отправляют новые приложения по умолчанию Google будет управлять их закрытым ключом, хотя разработчики отправляют обновления в существующие приложения можно продолжать использовать APK или они могут переключиться на распространение AAB, создав новый ключ, который Google будет использовать для новых пользователей. Существующие приложения не требуются переключиться с распространения APK на пакеты приложений Android, хотя эта опция доступна им, если они захотят. После некоторого сопротивления Google даже сделает это возможным загрузить свой собственный закрытый ключ для подписи Google как для новых, так и для существующих приложений. Ни одна из этих ситуаций не идеальна, так как, несмотря ни на что, Google будет иметь доступ к вашему личному ключу, если вы захотите. используйте пакеты приложений Android (и у разработчиков нет выбора, если они хотят представить новое приложение после августа 2021!)
Хотя мы уверены, что Google очень серьезно относится к безопасности, на Земле нет компании, которая была бы застрахована от утечки данных. Если ключ, который Google использует для подписи вашего приложения для распространения, находится в одной из этих уязвимостей, тогда любой может подписать версию вашего приложения и сделать так, чтобы оно выглядело так, как будто оно подписано вами. И некоторые разработчики и эксперты по безопасности недовольны такой возможностью. Да, это очень, очень малая вероятность, но сам факт такой возможности пугает некоторых представителей сообщества информационной безопасности.
Наличие подписи разработчиков APK-файлов Android означает, что любой может проверить APK-файлы из Google Play, слепое доверие не требуется. Это элегантный дизайн, обеспечивающий проверяемую безопасность. Пакеты приложений переворачивают это с ног на голову и, похоже, структурированы так, чтобы способствовать привязке к поставщику. Существует множество альтернативных технических подходов, которые позволяют создавать небольшие APK-файлы, все еще подписанные разработчиками, но они не отдают предпочтение Play. Например, все варианты APK могут быть созданы и подписаны разработчиком, а затем загружены в любой магазин приложений.
Конечно, можно привести аргументы о том, лучше ли оставить безопасное хранение закрытых ключей в руках Google или отдельных разработчиков. Но эти разработчики (вероятно) обычно не используют центральный репозиторий для своих ключей. Заставляя разработчиков использовать подпись приложений Play, злоумышленнику достаточно всего один раз нарушить безопасность Google, чтобы получить тысячи или миллионы ключей.
Вот что говорит Google о том, как он защищает ваш ключ подписи в своей инфраструктуре:
[blockquoteauthor="Войтек Каличински, адвокат разработчиков Android в Google"]Когда вы используете подписывание приложений Play, ваши ключи хранятся в той же инфраструктуре, которую Google использует для хранения своих собственных ключей.
Доступ к ключам регулируется строгими списками контроля доступа и журналами аудита с защитой от несанкционированного доступа для всех операций.
Все артефакты, созданные и подписанные ключом разработчика, доступны вам в консоли Google Play для проверки/аттестации.
Кроме того, чтобы предотвратить потерю ключей, мы очень часто делаем резервные копии нашего основного хранилища. Эти резервные копии надежно зашифрованы, и мы регулярно тестируем восстановление из этих резервных копий.
Если вы хотите узнать о технической инфраструктуре Google, прочитайте Технические документы по облачной безопасности Google.[/blockquote]
Как бы здорово это ни звучало, потеря и кража все еще возможны. А контрольные журналы только помогают предотвратить будущие атаки; им не вернут взломанные ключи.
Возможность несанкционированных модификаций
Одной из больших проблем с тем, как Google настроил пакеты приложений, является возможность добавления в приложение несанкционированных модификаций. Процесс извлечения APK из пакета приложений по своей сути включает в себя изменения, поскольку Google приходится вручную собирать каждый APK. Пока Google пообещал, что не будет вводить или изменять код, проблема с процессом App Bundle заключается в том, что у него есть на это возможность.
Вот несколько примеров того, на что способна компания, занимающая положение Google:
Допустим, есть безопасное приложение для обмена сообщениями, которое люди используют для общения без риска государственного надзора. Это может быть невероятно полезным инструментом для людей, протестующих против авторитарного правительства, или даже для людей, которые просто хотят сохранить свою конфиденциальность. Это правительство, желая иметь возможность видеть, что говорят пользователи приложения, может попытаться заставить Google добавить бэкдор для наблюдения в код приложения.
Этот пример немного более безобиден, но он также беспокоит некоторых людей. Допустим, есть приложение, которое загружают миллионы раз в день, но в нем нет рекламы или аналитики. Это огромный источник данных, к которому нет возможности получить доступ. Google, будучи рекламной компанией, возможно, захочет получить доступ к этим данным.
В классической модели распространения приложений APK Google не может изменять приложения без изменения подписи. Если Google изменит подпись, особенно в популярном приложении, люди это заметят, потому что обновление не будет установлено. Но с помощью App Bundles и App Signing Google может незаметно внедрять собственный код в приложения перед их распространением. Подпись не изменится, поскольку ключ подписи будет принадлежать Google.
Чтобы внести ясность, эти примеры невероятно маловероятны. Google имеет тенденцию просто вообще уйти с проблемных рынков, а не адаптироваться. Но даже если это маловероятно, это все же возможно. Если компания обещает, что чего-то не произойдет, она еще не гарантирует этого.
Прозрачность кода
Google, услышав эти опасения, на этой неделе представил новую функцию под названием Прозрачность кода для пакетов приложений. Прозрачность кода позволяет разработчику по существу создать вторую подпись, которая поставляется вместе с приложением пользователям. Эта дополнительная подпись должна быть создана на основе отдельного закрытого ключа, доступ к которому имеет только разработчик. Однако у этого метода есть некоторые ограничения.
Прозрачность кода распространяется только на код. Это может показаться очевидным, учитывая название, но это также означает, что оно не позволяет пользователям проверять ресурсы, манифест или что-либо еще, кроме файла DEX или собственной библиотеки. Хотя вредоносные модификации файлов, не содержащих кода, обычно оказывают гораздо меньшее влияние, это все равно остается дырой в безопасности приложения.
Еще одна проблема прозрачности кода заключается в отсутствии встроенной проверки. Для одного, это дополнительная функция, поэтому разработчикам следует не забывать включать его в каждый новый загружаемый APK. На данный момент это нужно делать из командной строки и с помощью версии bundletool этого нет в Android Studio. Даже если разработчик включает его, Android не имеет встроенной проверки соответствия манифеста прозрачности кода коду в приложении.
Конечный пользователь должен проверить это самостоятельно, сравнив манифест с открытым ключом, который может предоставить разработчик, или отправив APK разработчику для проверки.
Хотя прозрачность кода позволяет подтвердить, что код в приложении не был изменен, она не включает в себя какую-либо проверку других частей приложения. В этом процессе также нет внутреннего доверия. Вы можете возразить, что если вы не доверяете Google, вам, вероятно, придется пройти независимую проверку, но зачем вам это нужно?
Существуют и другие проблемы с функцией прозрачности кода, например: указал Марк Мерфи из CommonsWare. Рекомендую прочитать его статью для более глубокого анализа этой функции.
Удобство и выбор для разработчиков
Третья (и последняя в этой статье) причина, по которой некоторые разработчики недовольны пакетами приложений, — это ограниченное удобство и ограниченный выбор.
Если разработчик создает новое приложение в Play Store после того, как Google начинает требовать пакеты приложений, и он выбирает опция по умолчанию, позволяющая Google управлять ключом подписи, у них никогда не будет доступа к этой подписи ключ. Если тот же разработчик затем захочет распространить это приложение в другом магазине приложений, ему придется использовать свой собственный ключ, который не будет совпадать с ключом Google.
Это означает, что пользователям придется либо устанавливать и обновлять приложение из Google Play, либо из сторонних источников. Если они хотят изменить источник, им придется полностью удалить приложение (возможно, потеряв данные) и переустановить его. Агрегаторы APK, такие как APKЗеркало тогда также придется иметь дело с несколькими официальными подписями для одного и того же приложения. (Технически им уже придется это сделать, потому что подписывание приложений позволяет создать новый, более безопасный ключ для новых пользователей, но для них и других сайтов будет хуже, когда все имеет сделать это.)
Ответ Google на эту проблему заключается в использовании App Bundle Explorer или Artifact Explorer в Play Console для загрузки полученных APK-файлов из загруженного пакета. Как и в случае с прозрачностью кода, это не полное решение. APK-файлы, загруженные из Play Console, будут разделены для разных профилей устройств. Хотя Play Console поддерживает загрузку нескольких APK-файлов для одной версии одного приложения, многие другие каналы распространения этого не делают.
Таким образом, многие преимущества использования App Bundles теряются, когда разработчики управляют несколькими магазинами, что затрудняет распространение. С новостью о том, что Windows 11 является получение поддержки приложений для Android благодаря Amazon Appstore некоторые считают, что требование App Bundles лишит разработчиков стимула распространять приложения на Amazon. Конечно, главная забота Google — собственный магазин приложений, но это именно то, что поставили их в тупик с конкурентами побуждая их сделать небольшие, примирительные изменения о том, как сторонние магазины приложений работают на Android.
Пара проблем, связанных с несколькими магазинами, — это взаимосвязь приложений и быстрое тестирование.
Начнем с взаимодействия приложений. Вы когда-нибудь загружали приложение, которое блокирует функции через платный доступ? Почти наверняка. Некоторые разработчики предусматривают покупку функций внутри приложения, но другие могут решить создать отдельное платное приложение. Когда это дополнительное приложение будет установлено, основные функции приложения будут разблокированы.
Но что мешает кому-то просто установить дополнение из пиратского источника? Что ж, у разработчиков есть много вариантов, но по крайней мере один предполагает использование разрешений, защищенных подписью. Предположим, что основное приложение объявляет разрешение, защищенное подписью. Затем дополнительное приложение заявляет, что хочет использовать это разрешение. В идеале, дополнительное приложение также будет иметь какую-то функцию проверки лицензии, которая подключается к Интернету, чтобы убедиться, что пользователь является законным.
Если оба приложения имеют одинаковую подпись, Android предоставит разрешение дополнительному приложению, и проверки на защиту от пиратства пройдут. Если у дополнительного приложения нет правильной подписи, разрешение не будет предоставлено, и проверка завершится неудачей.
Благодаря классической модели распространения APK пользователь может получить любое приложение из любого законного источника и покончить с этим. При использовании текущей модели App Bundle по умолчанию подписи в основном и дополнительных приложениях не будут совпадать. Google собирается создать уникальный ключ для каждого приложения. Разработчик всегда может отказаться от разрешения, защищенного подписью, и использовать прямую проверку хэша подписи, но это намного менее безопасно.
А потом идут быстрые огневые испытания. Пользователи постоянно пишут разработчикам о проблемах в их приложениях. Иногда эти проблемы можно решить просто: воспроизведите проблему, найдите проблему, исправьте ее и загрузите новую версию. Но иногда это не так. Иногда разработчики не могут воспроизвести проблему. Они могут исправить то, что, по их мнению, является проблемой, но затем пользователь должен это проверить. Теперь предположим, что пользователь установил приложение через Google Play.
С помощью модели APK разработчик может изменить некоторый код, создать и подписать новый APK и отправить его пользователю для тестирования. Поскольку подпись тестового APK соответствует тому, который установил пользователь, его можно легко обновить, протестировать и отправить отчет. С пакетами приложений это разваливается. Поскольку Google подписывает APK, первоначально установленный пользователем, он не будет совпадать с подписью APK, отправленного разработчиком. Если это приложение будет опубликовано после истечения крайнего срока App Bundle, разработчик даже не получит доступа к ключам, которые использует Google. Чтобы протестировать, пользователю придется удалить текущее приложение перед установкой тестовой версии.
Здесь есть куча проблем. Во-первых, это неудобства как со стороны разработчика, так и со стороны пользователя. Удалять приложение только для того, чтобы проверить исправление, невесело. А что, если проблема исчезнет? Были ли это изменения, внесенные разработчиком, или это произошло потому, что пользователь фактически очистил данные приложения? В магазине Play Store есть внутреннее тестирование, которое должно позволить разработчикам быстро создавать и распространять приложения, но оно требует от пользователя сначала удалить релизную версию. Это особо ничего не исправляет.
Если все это звучит как гипотетическая чепуха, вот вполне реальный пример разработчика, у которого возникнут такие проблемы, если он позволит Google сгенерировать для него закрытый ключ: Жоао Диаш. Он разработчик Tasker, а также целого ряда плагинов, включая пакет AutoApps. С учетом нового требования к пакетам приложений цикл разработки Жоао может стать намного сложнее, по крайней мере, для новых приложений. Отправка тестовых версий напрямую будет менее удобной. Проверка лицензий будет менее эффективной.
Это может звучать как крайний случай, но Жоао не является каким-то мелким разработчиком, и, вероятно, он не одинок. В Play Store есть множество приложений, которые используют проверку подписи для обнаружения незаконных пользователей.
Конечно, благодаря новой возможности для разработчиков загружать свои собственные ключи подписи в Google эти проблемы, по крайней мере, несколько смягчаются. Но разработчикам необходимо дать согласие, чтобы включить эту опцию для каждого приложения. В противном случае межсоединения не будут работать, и для быстрой поддержки потребуется загрузить пакет в Google и дождаться создания APK-файлов, прежде чем отправлять правильный файл пользователю. Кроме того, это по-прежнему означает, что им придется делиться своим секретным ключом, что возвращает нас к проблемам, которые мы обсуждали ранее.
Решения
Это старая проблема, поскольку требования к App Bundle были опубликованы несколько месяцев назад, поэтому за это время было предложено довольно много решений.
Одно из решений — избежать необходимости подписывания приложений Play. Вместо создания пакета приложений, который Google затем преобразует в APK и подписывает, эту обработку может выполнять Android Studio. Затем разработчики могут просто загрузить ZIP-архив, полный локально подписанных APK для каждой конфигурации, созданной Google.
Благодаря этому решению Google вообще не понадобится доступ к ключам разработчиков. Этот процесс будет очень похож на классическую модель распространения APK, но будет включать в себя несколько APK меньшего размера, а не один.
Другое решение — просто не требовать использования пакетов приложений и продолжать позволять разработчикам загружать APK-файлы с локальной подписью. Хотя пакеты приложений могут во многих случаях будет удобнее для пользователя, некоторые приложения на самом деле не получают выгоды от разделения на каждую конфигурацию с минимальным размером снижение.
Если Google внедрит оба этих решения, то разработчику, желающему использовать App Bundles, не придется вручную подписываться на Google, и разработчику, чье приложение не получит особой выгоды от этого формата, не придется использовать его в все.
Ответы Google
Самоподписающийся
Когда их впервые спросили о том, чтобы разрешить разработчикам подписываться на App Bundles, ответ Google был очень уклончивым:
[blockquoteauthor=""]Итак, я кратко рассказал о требовании в следующем году к новым приложениям использовать пакеты приложений, и в связи с этим мы потребуем подписания приложений Play. Таким образом, разработчикам придется либо сгенерировать ключ подписи приложения в Play, либо загрузить в Play свой собственный ключ… потому что это обязательное условие для пакетов приложений. Мы слышали от разработчиков, что некоторые из них просто не хотят этого делать. Они не хотят, чтобы ключи управлялись Play. И в настоящее время это невозможно, если вы хотите использовать пакеты приложений.
Но мы услышали эту обратную связь, и… Я не могу сейчас ни о чем говорить, нам нечего объявить, но мы ищем способы облегчить некоторые из этих проблем. Не обязательно разрешать сохранять собственный ключ при загрузке пакетов. Мы рассматриваем разные варианты. У нас просто нет решения, о котором можно было бы объявить прямо сейчас. Но до появления требования у нас еще есть около года, поэтому я очень надеюсь, что у нас будет ответ для разработчиков.[/blockquote]
Это было в конце ноября прошлого года, и, похоже, ничего не произошло. До конца года осталось всего несколько месяцев Требование к App Bundle вступает в силу, у разработчиков до сих пор нет возможности подписывать свои собственные приложения. Хотя Google теперь сделал возможным загрузить ваш собственный ключ как для новых, так и для существующих приложений, при этом часть подписи по-прежнему выходит из-под контроля разработчика.
Изменения кода
Хотя Google пообещал, что Play Store не будет изменять код приложения, обещание не является гарантией. При использовании наборов приложений и подписи приложений нам не известны никакие технические ограничения, запрещающие Google изменять загруженные приложения перед их распространением.
Google представил Прозрачность кода в качестве дополнительной функции, и хотя это в некоторой степени помогает, у нее есть немало проблем, как мы обсуждали ранее.
Самодельные комплекты
Когда Google спросили о разрешении разработчикам создавать свои собственные «пакеты» приложений (ZIP-файлы, содержащие разделенные APK), ответ был в основном «мы не собираемся этого делать»:
Вероятно, не так, как описано в вопросе, поскольку это еще больше усложнит процесс публикации для разработчиков, а мы действительно хотим сделать его проще и безопаснее. Однако, опять же, мы услышали эту обратную связь и будем искать варианты, как сделать это возможным, но, вероятно, не так, как описано здесь.
Интересно, что Google оправдывает это тем, что это усложнит публикацию. Тем не менее, Google все равно может автоматизировать этот процесс в диалоговом окне создания APK в Android Studio. Более того, если рассматриваемое приложение распространяется в нескольких магазинах, это фактически приведет к процесс публикации упрощается, поскольку разработчикам не придется управлять несколькими ключами подписи и жалобами от пользователи.
А с появлением прозрачности кода кажется, что сложность вообще не является проблемой. Прозрачность кода, по крайней мере на данный момент, требует, чтобы разработчик использовал инструмент командной строки, а пользователи явно проверяли достоверность приложения, которое им обслуживается. Это сложнее, чем процесс самостоятельного создания пакетов, и неясно, почему именно это решение предпочитает Google.
Идти вперед
Пакеты приложений станут обязательным форматом распространения новых приложений, отправляемых в Google Play, начиная с 1 августа. Хотя Google, по крайней мере, в некоторой степени решил большинство проблем, поднятых разработчиками и экспертами по безопасности, ответы оставляют желать лучшего. У App Bundles как формата распространения следующего поколения есть много очевидных преимуществ, но всегда будут сохраняться проблемы с предоставлением Google частичного или полного контроля над подпиской приложений.
Ответы и усилия Google, безусловно, оценены по достоинству, но некоторые, например Марк Мерфи, считают, что они зашли недостаточно далеко. Поскольку такие решения, как самодельные пакеты, не реализуются, а крайний срок для пакетов приложений для Android требуется быстро. приближается, не похоже, что разработчики Google Play смогут надолго сохранить полный контроль над своими приложениями. дольше.
Сегодня днем мы поговорим о последствиях требования к набору приложений для Android в Твиттере, так что присоединяйтесь!