Устанавливаемый пакет содержит исходный код, несовместимый с процессором abi устройства что делать huawei

Обновлено: 21.11.2024

Аннотация

Утечка информации может происходить через многие приложения Android, включая несанкционированный доступ к данным датчиков. Перехват — важный метод защиты приложений Android и добавления в них функций безопасности даже без исходного кода. Разработаны различные фреймворки для перехвата событий и обработки собственных специфических событий. Инструменты перехвата для методов Java разнообразны, однако собственный перехватчик имеет несколько методов. Кроме того, широко используемые фреймворки Android-хуков не могут удовлетворить требования по подключению нативных методов в общих библиотеках на устройствах без полномочий root. Несмотря на то, что некоторые подходы могут использовать эти методы, они имеют ограничения или сложны в реализации. В статье предлагается и реализуется возможный подход к перехвату нативных методов Android, который не требует каких-либо модификаций как платформы Android, так и кода приложения. При таком подходе адрес ссылки метода изменяется, а поток управления перенаправляется. Кроме того, в этом исследовании этот подход сочетается с VirtualXposed, целью которого является запуск без привилегий root. Эту структуру перехвата можно использовать для обеспечения соблюдения политик безопасности и мониторинга конфиденциальных методов в общих объектах. Оценка схемы демонстрирует ее способность выполнять операцию ловушки без существенного снижения производительности во время выполнения на реальных устройствах, а также ее совместимость и функциональность для встроенной ловушки.

1. Введение

Большинство устройств Android имеют встроенные датчики, которые измеряют движение, ориентацию и различные условия окружающей среды. Как самая популярная операционная система для смартфонов во всем мире [1], платформа Android поддерживает три широкие категории датчиков: датчики движения, датчики окружающей среды и датчики положения [2,3]. Каким бы ни был датчик, Android позволяет приложению получать необработанные данные с этих датчиков. К сожалению, из-за характера открытого исходного кода и его популярности существует ряд различных угроз, которые могут пострадать от продолжающейся утечки данных [4,5,6], таких как вредоносное ПО [7,8], шпионское ПО или отсутствие отказоустойчивости. -safe по умолчанию в Android SDK [9]. Даже безопасные приложения могут подвергать пользователей различным угрозам, которые содержат уязвимые компоненты [10], такие как использование небезопасного шифрования, утечка разрешений [11,12,13], захват данных во время передачи [14] и удаленное выполнение кода [15]. . Более того, статический анализ приложений для Android в настоящее время становится все более и более сложным, поскольку как добросовестные, так и злонамеренные разработчики используют различные методы защиты, такие как обфускация кода [16], чтобы предотвратить реверсирование приложений. Были предложены различные технологии предотвращения утечек информации [17,18,19,20]. Методы перехвата могут использоваться разработчиками для развертывания новых расширений безопасности на своих устройствах или для динамического анализа приложений [21], что позволяет избежать модификации исходного кода.

В настоящее время, несмотря на наличие различных инструментов для перехвата методов Java, существует несколько инструментов для нативного перехвата Android. Следует отметить, что если мы изменим общие библиотеки приложения напрямую, чтобы изменить инструкции целевого метода, и переупаковать приложение, нам нужно повторно подписать приложение, что нарушает политику Android на основе подписи того же происхождения и, кроме того, приводит к юридическим опасениям по поводу незаконное вмешательство в чужой код [22]. Что касается нативного хука, в основном существует два основных маршрута: хук таблицы связывания процедур (PLT) и встроенный хук. У этих методов перехвата есть свои преимущества и недостатки, и они очень разные по принципу и применимым сценариям. Перехватчик PLT напрямую модифицирует глобальную таблицу смещения (GOT) в файлах исполняемого и связываемого форматов (ELF) для перехода к определяемому пользователем коду функции перехватчика при вызове внешних функций разделяемой библиотеки [23]. Это технически менее сложно, требует только вычисления и модификации адресов памяти. Однако таблицы PLT и GOT содержат только внешние функции разделяемой библиотеки, которые необходимо вызывать ELF. Недостаток в том, что внутренние пользовательские функции, так как их нет в таблице PLT, не могут быть перехвачены. Основной принцип Inline Hook заключается в том, чтобы вставить инструкции перехода в сегмент кода, чтобы направить процесс выполнения программы на функциональный код, требуемый пользователем [24]. Преимущество этого метода в том, что он полностью не зависит от того, находится ли функция в таблице PLT. Однако могут быть разные проблемы совместимости и стабильности для процессоров с разными архитектурами, наборами инструкций процессора, параметрами оптимизации компилятора и версиями операционной системы. Кроме того, анализ и локализация проблем могут быть очень сложными. Байты встроенной замены для ARM составляют 8–14 байтов, что намного больше, чем 5 байтов для платформ x86. Когда функция относительно короткая, она не работает.

Из-за ограничений существующих нативных методов перехвата, в этом документе будет предложен осуществимый и эффективный нативный метод перехвата Android. Этот метод может перехватывать как внешние методы, так и внутренние пользовательские функции, следовательно, имеет широкий диапазон. Идея этого метода перехвата заключается в изменении адреса ссылки в разделе перемещения, что сохраняет смещения методов, определенных в разделе .text. Разделы, содержащие ссылку на методы, содержат .got, в котором хранится адрес входа внешнего вызова, .data.rel.ro, в котором находится виртуальная таблица класса C++ и указатель на виртуальные методы, и другой раздел перемещения. Этот метод перехвата достигается путем вычисления абсолютного адреса и перезаписи этого адреса на адрес новой функции, чтобы перенаправить потоки управления на код исправления. Этот метод перехвата не требует вычисления регистров и модификации ассемблерного кода, а требует только вычисления и модификации адреса памяти, соответственно, он имеет низкую техническую сложность. Поскольку этот метод может перехватывать внутренние функции C++, его использование может компенсировать отсутствие метода PLT.

2. Фон

Приложения для Android реализованы на языке java, скомпилированном в байт-код DEX. Программы для Android выполняются либо на виртуальной машине Dalvik, либо в среде выполнения Android (ART). Разработчики используют ряд инструментов Native Development Kit (NDK) для быстрой разработки динамической библиотеки C/C++ и автоматической упаковки библиотеки динамической компоновки и приложений Java в пакет Android (APK). Java Native Interface (JNI) — это собственный программный интерфейс, механизм, предоставляемый языком Java для взаимных вызовов Java и C/C++. Файлы общих объектов (SO) – это файлы с динамическими ссылками, и их формат – файл ELF.

2.1. Структура файла ELF

Как и в традиционной модели Linux, общие библиотеки в Android представляют собой перемещаемые файлы ELF, которые при загрузке сопоставляются с адресным пространством процесса. Чтобы сэкономить память и избежать дублирования кода, все общие объекты, поставляемые с Android, динамически связаны с библиотекой Bionic libc [23]. Совместно используемые библиотеки будут загружены в произвольное пространство памяти. Для разрешения адреса неизвестных символов во время загрузки используется метод динамического связывания.

Основными частями формата ELF являются заголовок файла ELF, таблица заголовков разделов (SHT) и таблица заголовков программ (PHT). В начале файла ELF находится заголовок файла фиксированной длины, который включает начальную позицию и длину SHT и PHT в текущем файле ELF. ELF организует и управляет информацией по разделам. ELF использует SHT для записи основной информации для всех разделов. В основном это тип раздела, смещение в файле, размер, относительный адрес виртуальной памяти после загрузки в память, выравнивание байтов в памяти и так далее.

Для ELF-файла, динамически связанного с другими общими объектными файлами, вызов функций общего объекта представляет собой инструкцию для перехода к какой-либо функции-заглушке в таблице PLT. Чтобы получить реальный адрес целевой функции, функция-заглушка затем выполняет загрузку памяти для записи в таблице GOT. То есть таблица GOT содержит массив указателей всех динамически связанных внешних функций, на которые ссылается их код. В период динамического связывания таблица GOT заполняется правильными указателями функций в зависимости от сопоставления между записью GOT и функцией в общих объектных файлах при контроле метаданных, хранящихся в файле ELF.

Хук PLT использует этот уровень косвенности, обеспечиваемый динамическим связыванием. Он просматривает каждый загруженный файл ELF и перезаписывает его записи GOT указателем на определенный пользователем метод, что эквивалентно выполнению динамической компоновки в другой раз, но заменяет указатель метода.

2.2. Динамическая отправка в C++

В этом разделе кратко рассматривается, как динамическая диспетчеризация вызывает методы объекта в C++. Правила динамической диспетчеризации C++ предписывают, что при вызове виртуального метода реальная реализация зависит от типа среды выполнения вызывающего объекта. Этот уровень косвенности позволяет подклассам переопределять реализацию методов родительского класса и является одним из ключевых механизмов полиморфизма в C++. Будет ли вызываться родительский или дочерний метод, зависит от того, на что ссылается объект во время выполнения.

Виртуальные таблицы методов (vtable) обычно используются в стратегиях реализации динамической диспетчеризации. Популярные компиляторы C++, такие как GCC, Visual C++ и Clang++, из-за их эффективности используют виртуальные таблицы. Vtable — это таблица, в которой хранятся адреса виртуальных методов класса. Для реализации vtable компилятор присваивает идентификатор каждому виртуальному методу класса C++, мы предполагаем, что это порядковый номер метода. Виртуальная таблица — это массив, элемент которого представляет соответствующий метод класса.При компиляции кода компилятор создает виртуальную таблицу для каждого класса и инициализирует первое слово созданного объекта указателем на виртуальную таблицу, вставляя код в конструктор класса.

Чтобы реализовать вызов виртуального метода, компилятор должен выполнить следующие шаги: во-первых, загрузить указатель виртуальной таблицы, расположенный в начальной позиции вызывающего объекта. Затем найдите элемент с индексом i в виртуальной таблице, где i — порядковый номер вызываемого метода. Наконец, вызовите реализацию метода, адрес которой хранится в элементе виртуальной таблицы. На рис. 1 показано, как загружаются общие библиотеки и выполняются внутренние виртуальные методы во время выполнения.

1. Библиотека и библиотеки
упомянуты в lib и включены в libs.
Файлы, помещенные в библиотеки, будут автоматически включены редактором. Так что не помещайте API в библиотеки.
Содержимое библиотеки не будет упаковано в APK, содержимое библиотеки будет упаковано в APK

2. Библиотека .so
Библиотека динамической компоновки, скомпилированная NDK.
Некоторые важные алгоритмы шифрования или базовые протоколы обычно пишутся на C, а затем вызываются на Java. Это позволяет избежать просмотра исходного кода приложения после декомпиляции.

3. Как хранить библиотеку .so
. Правильная поза для размещения файла .so на самом деле состоит из двух предложений:
• Чтобы уменьшить размер apk, оставьте только две папки armeabi и armeabi-v7a и убедитесь, что файлы .so находятся в этих две папки. Постоянное количество
• Для стороннего .so, который предоставляет только версию для armeabi, скопируйте копию в папку armeabi-v7a
. Правила хранения so:
Вы должны предоставить как можно больше файлов .so, оптимизированных для каждого ABI, но либо все Support, либо ни одного: смешивать их не следует. Вы должны предоставить соответствующий файл .so для каждого каталога ABI.
Что касается хранения, вы можете посмотреть в этой статье
. Какова роль armeabi под libs?
Библиотека Storage .so в основном совместима с различными устройствами или, можно сказать, совместима с архитектурой процессора на разных телефонах Android.
Давайте поговорим о
типах ЦП устройств Android с процессором Android (обычно называемых «ABI»)

Введение в архитектуру

Нет изображения, нет правды:

только неизвестный телефон oppo, система Android 4.3, использующая архитектуру v7

Как работает ABI

Основной ABI устройства соответствует машинному коду, используемому в самом образе системы.
(Необязательно) Дополнительный ABI, соответствующий другим ABI, также поддерживаемым образом системы.
Этот механизм гарантирует, что система извлечет лучший машинный код из программного пакета во время установки.

Для достижения наилучшей производительности компилируйте непосредственно с основным ABI. Например, типичное устройство на базе ARMv5TE будет определять только основной ABI: armeabi. Напротив, типичное устройство на базе ARMv7 определяет основной ABI как armeabi-v7a, а вспомогательный ABI — как armeabi, поскольку оно может запускать собственные двоичные файлы приложения, созданные для каждого ABI.

64-разрядные устройства также поддерживают его 32-разрядный вариант. Возьмем, к примеру, устройство arm64-v8a. Это устройство также может запускать коды armeabi и armeabi-v7a. Однако обратите внимание, что если приложение ориентировано на arm64-v8a, а не на устройство, на котором запущена версия приложения armeabi-v7a, приложение будет работать намного лучше на 64-разрядных устройствах.

Многие устройства на базе x86 также могут запускать исполняемые файлы armeabi-v7a и armeabi NDK. Для этих устройств основным ABI будет x86, а дополнительным ABI будет armeabi-v7a.

Как правило, устройство Android может поддерживать несколько ABI, основной ABI и вспомогательный ABI устройства, устройство с arm64-v8a в качестве основного ABI, вспомогательный ABI — armeabi-v7a и armeabi, а устройство с armeabi -v7a в качестве основного ABI, вспомогательный ABI — armeabi.
Кроме того, мобильные телефоны с архитектурой x86 будут включать инструмент динамического транскодирования набора инструкций под названием Houdini, предоставленный Intel для достижения совместимости с arm.so, что означает, что приложения, совместимые с платформой armeabi, могут работать на телефонах x86.

Специальный процесс адаптации ABI

Для мобильного телефона с процессором архитектуры arm64-v8a, когда он запускает приложение, когда он входит в jnilibs для чтения файла библиотеки, сначала посмотрите, есть ли папка arm64-v8a, если нет такая папка, перейдите в папку armeabi-v7a, если нет, перейдите в папку armeabi. Если такой папки нет, будет выброшено исключение;
если есть папка arm64-v8a, то переходим в файл .so с конкретным именем. Примечание. Если вы не найдете то, что хотите. Файл so не будет искаться ниже (папка armeabi-v7a), а сразу будет выдано исключение.

Как адаптироваться в нашем проекте

В1: Адаптирован только armeabi-v7a, поэтому, если приложение установлено на мобильный телефон с другой архитектурой, такой как arm64-v8a, будет ли оно сброшено?
О: Нет, а наоборот.
Поскольку armeabi-v7a и arm64-v8a будут обратно совместимы:

Приложение, которое адаптируется только к armeabi, может работать на armeabi, x86, x86_64, armeabi-v7a, arm64-v8
Только адаптация к armeabi-v7a может работать на armeabi-v7a и arm64-v8a
Адаптируется только для arm64-v8a, может работать на arm64-v8a

Как мы должны адаптироваться? Даны следующие решения:
Решение 1: Адаптировать только к armeabi

Преимущества: в основном адаптированы ко всем архитектурам ЦП (кроме устаревших mips и mips_64)
Недостатки: низкая производительность, эквивалентная необходимости вспомогательного ABI или динамического транскодирования для совместимости с большинством мобильных телефонов

Решение 2. Адаптируйте только к armeabi-v7a. То же, что
решение 1, за исключением того, что некоторые из старых устройств отфильтрованы, а производительность и совместимость более сбалансированы.
Решение 3. Адаптируйтесь только к arm64-v8

Преимущества: Лучшая производительность.
Недостатки: Может работать только на arm64-v8, некоторым пользователям старых устройств приходится отказываться

Все эти три схемы возможны. В настоящее время приложение Dachang адаптируется ко всем трем из них, и большинство из них являются первыми двумя схемами. Какой из них выбрать, зависит от ваших собственных соображений, производительность заменяется совместимостью, arm64-v8, а совместимость заменяется производительностью armeabi, а баланс между ними — armeabi-v7a.

Для 64-разрядных телефонов и 64-разрядных процессоров

64-разрядные процессоры ARM и компьютерные 64-разрядные процессоры — две совершенно несовместимые концепции. Дело не в том, что 64-разрядная архитектура может быть изначально совместима с 32-разрядными программами, а в том, что 32-разрядная архитектура интегрируется в 64-разрядные процессоры для запуска 32-разрядных программ. Битовая программа. Проще говоря, он не запускает 32-разрядные программы в 64-разрядной форме, а запускает 32-разрядные программы в 32-разрядной форме.

Поскольку новый 64-битный процессор содержит две архитектуры, а техпроцесс не улучшен (28нм), в то же время на мобильных телефонах и планшетах площадь чипа строго ограничена и не может быть чрезмерно увеличена, что приводит к равномерному распределению 64-битных процессоров ARM Количество транзисторов в каждой архитектуре резко сократилось, а это значит, что из 32-битной архитектуры 64-битного процессора для 32-битного процессора той же спецификации не только производительность не улучшилась, но производительность в определенной степени снизилась. Но производители процессоров должны дать потребителям объяснение, как лучше продвигать 64-битные процессоры, поэтому производители должны повышать производительность в других областях, чтобы компенсировать потери, вызванные уменьшением количества транзисторов в ЦП. Например: замена графических процессоров на более производительные, увеличение пропускной способности памяти, многоядерные виртуальные одноядерные процессоры для повышения производительности одноядерных, совместная работа поставщиков программного обеспечения для изменения весовых коэффициентов (увеличение показателей графических процессоров, снижение весовых показателей ЦП) и т. д. Таким образом, сильные и слабые стороны максимизируются и, наконец, доходят до потребителей. После обкатки с работающим софтом оно действительно улучшилось, пользователи довольны, да и у производителей карманы оттопыриваются.

Подводя итог, можно сказать, что 64-разрядный процессор ARM правильнее называть ARM32+64 в строгом смысле этого слова. По сравнению с 32-разрядным процессором ARM у него есть шаг назад и есть возможности для улучшения, но именно из-за регресса он вдохновил ARM на прогресс. Решимость заставить его резко измениться вперед, надо сказать, это тоже своего рода прогресс. Но действительно ли ARM64 полезен для мобильных телефонов? Могу только сказать, что это действительно бесполезно на данный момент, но может быть в будущем. (Собраны в другом месте) Подводя итог, можно сказать, что ARM64-битный процессор правильнее называть ARM32+64 в строгом смысле. По сравнению с 32-битным процессором ARM есть шаг назад и есть возможности для совершенствования, но именно потому, что Backward вызвал агрессивную решимость ARM, пусть она сделает кардинальные изменения вперед, нужно сказать, что это тоже своего рода прогресс. Но действительно ли ARM64 полезен для мобильных телефонов? Могу только сказать, что это действительно бесполезно на данный момент, но может быть в будущем. (Собраны в другом месте)

Настоящий 64-битный мобильный телефон не просто держится на процессоре. Если его называют 64-битным мобильным телефоном только потому, что его процессор 64-битный, мы можем без колебаний сказать, что это может быть ложной пропагандой. К счастью, Lenovo Очень умно, когда выпускались A678t и A805e, упоминались только телефоны с 64-битным процессором.
«Мобильный телефон с 64-битным процессором» и «64-битный мобильный телефон» — это два совершенно разных понятия: поскольку процессор содержит 64-битную архитектуру, его можно назвать «мобильным телефоном с 64-битным процессором». Такой мобильный телефон может не работать.64-битные программы используются только для захвата рынка, и преимущества не очевидны по сравнению с 32-битными телефонами.

"64-битный мобильный телефон" отличается: он содержит 64-битный процессор, 64-битную стандартную систему, 64-битную виртуальную машину Android и 64-битную программу. Это настоящий 64-битный мобильный телефон!
Google уже давно официально заявил, что Android поддерживает 64-битную версию. Это верно. От Android 4.0 до Android 4.4 системы Android поддерживают 64-разрядное оборудование, но это означает только то, что базовый драйвер поддерживает 64-разрядное оборудование и может работать. На 64-битном железе ничего лишнего. Однако верхний уровень, на котором работает программное обеспечение, будь то виртуальная машина Dalvik или виртуальная машина ART, является 32-разрядным. Другими словами, пока на вашем мобильном телефоне установлена система Android 4.0-4.4, даже если ваш процессор 64-разрядный, вы можете запускать 32-разрядные программы только под 32-разрядной виртуальной машиной, даже если настоящая 64-разрядная программы перед вами, Его тоже нельзя установить. .

Тем не менее, Google официально объявила об обязательном требовании 64-битной архитектуры в начале этого года:

Еще в январе этого года (2019) Google опубликовала уведомление о том, что с 1 августа в этом году помимо предоставления 32-разрядных версий приложений требуется 64-разрядная версия.

Поэтому больше нельзя принудительно использовать только armeabi в качестве архитектуры перед проектом.
Так что именно здесь упоминается о поддержке 64-битной версии?
Если ваше приложение полностью написано на Java или Kotlin и не содержит нативной поддержки, то это означает, что приложение уже поддерживает 64-битную версию.
Однако, если в приложении используется какая-либо нативная поддержка (so-библиотека), необходимо предоставить разные версии so-поддержки для этих so-файлов и для разных архитектур ЦП.
Следует отметить, что иногда в нашем собственном коде нативная поддержка действительно не используется, но включены некоторые сторонние библиотеки, используемые в приложении.
В настоящее время самым безопасным способом является анализ APK-файла, созданного окончательным пакетом, чтобы определить, необходимо ли обеспечивать поддержку 64-разрядной архитектуры.

Конфигурация пакета

разделение субконтракта
Эта команда может быть субконтрактирована в соответствии с различными правилами, такими как субконтракт в соответствии с abi, плотностью экрана (например, ldpi, hdpi и т. д.)

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

Но эта конфигурация создаст два пакета, один из которых будет содержать только библиотеку so для x86, а другой — только библиотеку so для armabi. , явно не соответствует спросу

ndk filtering
Эта команда может быть настроена для упаковки только настроенной вами библиотеки so, а не для упаковки, если нет конфигурации, это очень гибко.

Сторонние файлы aar, если этот SDK имеет полную поддержку abi, он может включать пять видов abi, armeabi, armeabi-v7a, x86, arm64-v8a, x86_64 и другие, поэтому вы применяете только поддержку armeabi, armeabi -v7a, x86 Три, прямо обратитесь к аару sdk, он автоматически скомпилирует пакет, поддерживающий 5 видов аби. Но в другом приложении отсутствует поддержка двух других abi, тогда, если приложение работает на arm64-v8a, x86_64 является предпочтительным устройством abi, оно выйдет из строя, поэтому нам нужно настроить конфигурацию abiFilter в нашем приложении. Избегайте неизвестных ошибок

Эта конфигурация упаковывает so-библиотеки трех пакетов armeabi, armeabi-v71, arm64-v8a в один apk, в отличие от сплитов, в которых для каждого пакета будет один apk.

По мере того, как мы приближаемся к стабильной версии Android 12, Google вносит некоторые фундаментальные изменения в доставку и распространение приложений на устройствах Android. С августа 2021 года все новые приложения в Play Store будут публиковаться в формате Android App Bundles (.aab) вместо существующего формата APK. Итак, каковы основные различия между APK и Android App Bundle (AAB)? Можем ли мы загружать AAB так же, как APK? Чтобы ответить на все ваши вопросы, мы составили это подробное руководство по APK и AAB. Итак, не теряя времени, давайте приступим к делу.

APK и AAB (наборы приложений для Android): всестороннее сравнение

Здесь мы объяснили форматы AAB и APK с точки зрения непрофессионала, чтобы любой мог легко понять концепцию. Мы также подробно рассказали, как устанавливать файлы AAB, извлекать APK из файлов AAB и многое другое. Вы можете развернуть таблицу ниже, чтобы быстро перейти к любому соответствующему разделу.

APK и AAB: понимание основ

Во-первых, нам нужно понять некоторые основы, чтобы правильно понять, в чем разница между APK и Android App Bundle.

APK был основным пакетом приложений для распространения на Android с момента его создания.APK в основном состоит из кодов приложений, тяжелых ресурсов, таких как изображения, аудио и т. д., а также ключа подписи приложения, сгенерированного разработчиком. Обратите внимание, что устройства Android бывают разных форм-факторов и спецификаций. Например, устройства могут иметь различную степень плотности экрана (320dpi, 480dpi и т. д.), тип процессора (ARM, ARM64, x86) и многое другое. Кроме того, в зависимости от региона пользователя приложение должно иметь языковой пакет (en, fr, ger и т. д.).

В идеальной ситуации разработчик должен создать и загрузить в Play Маркет несколько APK-файлов в зависимости от региона пользователя, типа процессора и плотности экрана. Когда пользователь нажимает кнопку «Установить» в Play Store, правильный и наиболее подходящий APK устанавливается на его устройство. Однако все это ставит перед разработчиком огромную задачу. Им нужно не только разрабатывать приложения, но и управлять несколькими APK-файлами для поддержки множества устройств.

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

Google хочет решить эту проблему и взять на себя большую часть этого бремени для разработчиков с помощью Android App Bundles (AAB). Это, в свою очередь, поможет уменьшить размер приложения, время установки и потребление полосы пропускания. Компания представила AAB на Google I/O 2018, и теперь, почти два года спустя, Google предписывает вам отправлять новые приложения в формате AAB в Play Store.

По сравнению с APK формат AAB не является совершенно новым дистрибутивом. По сути, AAB — это контейнер, в котором размещается базовый APK и несколько разделенных APK. По сути, AAB — это формат публикации, который разработчик отправляет в Play Маркет, а APK — это формат упаковки для приложений Android, которые вы устанавливаете на свое устройство.

Так что же здесь действительно меняется? Начиная с августа 2021 года разработчикам не нужно обрабатывать и управлять целой кучей APK для широкого спектра устройств. С помощью AAB разработчики передают Google все — код приложения, активы, большие ресурсы, все языковые пакеты и, самое главное, закрытый ключ подписи приложения. Теперь Google может создавать и предоставлять оптимизированные APK-файлы пользователям в зависимости от конфигурации их устройств. Он может создать гораздо меньший пакет AAB, компактный по размеру, устанавливаемый в один миг и потребляющий меньше данных для недорогих устройств. Это главное преимущество AAB против APK, но есть еще кое-что, что нужно раскрыть.

Обмен закрытым ключом подписи с Google

Глядя на то, что предлагает AAB, кажется, что это отличная альтернатива APK. Формат AAB уменьшает размер приложения, и разработчикам не нужно создавать несколько APK. Однако многие разработчики выразили обеспокоенность по поводу передачи закрытого ключа подписи в Google.

Как я упоминал выше, ключ подписи — это самая важная информация для проверки целостности APK. Даже если вы загружаете APK-файл из стороннего источника, Google Play Маркет проверяет ключ подписи, чтобы убедиться, что ничего не было изменено.

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

Кроме того, чтобы развеять опасения разработчиков, Google объявил о прозрачности кода, которая позволяет разработчикам создавать отдельный закрытый ключ, доступный только им. Затем из отдельного закрытого ключа разработчики могут создать дополнительную подпись, которую можно использовать для проверки целостности приложения. Однако у этого метода есть ограничение. Прозрачность кода имеет дело только с кодом, а не с активами, ресурсами или манифестом.Кроме того, это необязательная функция, которая может оставить многих разработчиков в стороне.

Собирается ли AAB усложнить жизнь сторонним магазинам приложений?

Еще одна проблема, связанная с передачей закрытого ключа Google, заключается в том, что это может затруднить работу сторонних магазинов приложений. Например, если вы устанавливаете приложение из Play Маркета, но хотите обновить его до последней версии из другого альтернативного магазина Play (скажем, из Amazon App Store или Aptoide Store), установка может завершиться ошибкой из-за несоответствия подписи.

Это связано с тем, что Google теперь управляет закрытым ключом подписи, поэтому вы не можете использовать тот же ключ при загрузке своего приложения в сторонний магазин приложений для Android. Вам придется использовать другой закрытый ключ, что приведет к ошибке несоответствия закрытого ключа. Будет ли это проблемой для поддержки приложений Android в Windows 11? Нам придется подождать и узнать. Приложения для Android появятся в Microsoft Store

Кроме этого, предположение о том, что AAB будет мешать разработчикам загружать APK в сторонние магазины приложений, кажется неверным. Google уже создал инструмент с открытым исходным кодом под названием bundletool, который позволяет разработчикам создавать APK из пакетов AAB. Единственная проблема на данный момент заключается в том, что передача закрытого ключа подписи повлияет на опытных пользователей Android.

Можем ли мы загружать файлы AAB так же, как APK?

Насколько нам известно, загрузка неопубликованных файлов AAB на устройства Android будет возможна, но это будет не так удобно, как загрузка неопубликованных APK. Установщик пакетов Android в настоящее время не поддерживает формат упаковки AAB, а это означает, что установка AAB на устройстве будет невозможна изначально. Однако вы можете использовать сторонние приложения-установщики для установки пакета AAB на устройство.

Например, в настоящее время установщик APKMirror (бесплатно, предлагает покупку в приложении) позволяет устанавливать пакеты APKM (базовый APK + разделенные APK) с помощью приложения-установщика. У нас уже есть подробное руководство по установке Android App Bundle на ваш телефон, поэтому ознакомьтесь со статьей по ссылке.

Кроме того, вы не сможете использовать adb для установки AAB. Вам нужно будет использовать пакет инструментов с открытым исходным кодом, чтобы получить правильный APK, совместимый с вашим устройством. По мере того, как AAB становятся все более распространенными, могут появиться новые и удобные методы боковой загрузки. Имейте в виду, что простая загрузка базового APK приведет к сбою на вашем устройстве.

APK и AAB: преимущества и недостатки

Рассмотрев все пункты, вы можете сказать, что AAB не будут иметь большого значения с точки зрения пользовательского опыта для большинства пользователей. Да, это уменьшит размер приложения, что будет полезно для большинства пользователей. Например, Airbnb уменьшил размер своего приложения на 22% после перехода с APK на AAB, тогда как Netflix уменьшил размер своего приложения на 57%. Это значительная разница в размере приложения. Кроме того, заброшенная функция приложения с мгновенным запуском получит новую жизнь с AAB на устройствах Android.

Однако опытным пользователям, которые хотят загружать AAB-файлы, все станет немного сложнее и неудобнее. Возможно, вам придется использовать bundletool для извлечения APK для вашего устройства или использовать сторонний установщик. Следует отметить, что AAB отойдет от OBB (непрозрачного двоичного двоичного объекта) для загрузки больших активов и ресурсов. Вместо этого он будет использовать Play Asset Delivery или Play Feature Delivery для загрузки тяжелых ресурсов размером 150 МБ или больше. Посмотрим, как это повлияет на загрузку неопубликованных игр, таких как Battlegrounds Mobile India, PUBG Mobile, FAU-G и других.

Что касается разработчиков, которых это изменение больше всего затронуло, им не нужно рефакторить свой код, и это здорово. AAB также обеспечивают модульность, что означает, что они могут изменить фрагмент кода и объединить его с основной базой, не сталкиваясь со многими конфликтами слияния. Одним из больших преимуществ AAB является то, что он предоставляет разработчикам возможности настройки. Они могут выбрать, какой уровень API использовать или какой тип устройства поддерживать. Разработчики также могут решить, какие функции должны предоставляться на устройствах определенного типа или смартфонах, работающих с минимальной версией SDK.

Что касается недостатков, суть проблемы заключается в совместном использовании закрытого ключа, которым теперь будет управлять Google.Несовместимость со сторонними магазинами приложений может стать еще одной серьезной проблемой, и разработчикам придется приложить дополнительные усилия, чтобы публиковать APK-файлы и управлять ими (так же, как в настоящее время Play Store) в других магазинах приложений.

APK и AAB (наборы приложений для Android): что вы думаете?

Для меня самой большой проблемой с этим изменением является чрезмерная зависимость от Google. Этим изменением гигант Маунтин-Вью следит за тем, чтобы Play Store оставался де-факто магазином приложений на устройствах Android. От размещения приложений до управления закрытыми ключами — теперь Google контролирует все аспекты публикации и распространения приложений на Android. Разработчики могут быть довольны новыми изменениями, поскольку им больше не нужно управлять несколькими APK, но как это отразится на пользователях в долгосрочной перспективе? Мы еще не знаем. Принесет ли это хорошие изменения, если разработчики передадут контроль Google? Нам придется подождать и посмотреть. Впрочем, это все от нас. Но расскажите нам, что вы думаете об этих дебатах между APK и AAB в разделе комментариев ниже.

Элемент DSL «android.dataBinding.enabled» устарел и был заменен на «android.buildFeatures.dataBinding».

что угодно by Wide-eyed Wren on 01 Aug 2020 Comment

Элемент DSL «android.dataBinding.enabled» устарел и был заменен на «android.buildFeatures.dataBinding».

что угодно by Wide-eyed Wren on 01 Aug 2020 Comment

Любые ответы, связанные с «Элемент DSL 'android.dataBinding.enabled' устарел и был заменен на 'android.buildFeatures.dataBinding'».

Любые запросы, связанные с «элементом DSL 'android.dataBinding.enabled', устарели и заменены на 'android.buildFeatures.dataBinding'».

Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding».
android.databinding.enabled устарел и заменен на android.buildfeatures.databinding
Элемент dsl 'annotationprocessoroptions.includecompileclasspath' устарел.
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding». он будет удален в версии 5.0 плагина Android Gradle. затронутые модули: приложение
android.databinding.enabled устарел и заменен на android.buildfeatures.databinding
элемент 'android.databinding.enabled'
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding».\
Элемент dsl 'android.databinding.enabled' устарел и заменен на
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding». он будет удален в версии 7.0 плагина Android Gradle. затронутые модули: приложение Android Studio kinary
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding». он будет удален в версии 5.0 плагина Android Gradle.
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding». он будет удален в версии 7.0 плагина Android Gradle. затронутые модули: приложение

Элемент dsl android.databinding.enabled устарел и заменен на android.buildfeatures.databinding
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding». он будет удален в версии 5.0 плагина Android Gradle.
предупреждение: элемент dsl android.databinding.enabled устарел и заменен на android.buildfeatures.databinding.
android.databinding.enabled устарел и заменен на android.buildfeatures.databinding.
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding». он будет удален в версии 5.0 плагина Android Gradle. затронутые модули: приложение
'android.databinding.enabled' устарел
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding».
связывание данных включено = true не рекомендуется
градус привязки данных buildfeatures
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding». андроид
элемент android studio dsl

Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding». он будет удален в версии 7.0 плагина Android Gradle.
Элемент dsl «android.viewbinding.enabled» устарел и был заменен на «android.buildfeatures.viewbinding».
Элемент dsl android.databinding.enabled устарел и заменен на android.buildfeatures.databinding
элемент android.databinding.enabled устарел и заменен на android.buildfeatures.databinding
предупреждение: элемент dsl «android.databinding.enabled» устарел и заменен на «android.buildfeatures.databinding». он будет удален в версии 5.0 плагина Android Gradle.
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding».
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding». он будет удален в версии 5.0 плагина Android Gradle.
ndroid.databinding.enabled» устарел и был заменен на
"android.databinding.enabled" устарело и заменено на "android.buildfeatures.databinding".
android.databinding.enabled устарел
Элемент dsl «android.databinding.enabled» устарел и был заменен на «android.buildfeatures.databinding». он будет удален в версии 5.0 плагина Android Gradle. затронутые модули:

Зарегистрируйтесь, чтобы голосовать и добавлять примеры кода. Присоединяйтесь к нашему сообществу разработчиков, чтобы улучшить свои навыки разработки и программировать как босс!

Помогите нам улучшить наши примеры кода, зарегистрировавшись, чтобы проголосовать и добавить ответы. Присоединяйтесь к нашему сообществу разработчиков, чтобы улучшить свои навыки разработки и программировать как босс!

Читайте также: