Что такое cpu abi устройства

Русские Блоги

Android CPU ABI

Кратко об ABI

В разных телефонах Android используются разные процессоры, поэтому они поддерживают разные наборы команд. Каждая комбинация процессора и набора команд имеет собственный двоичный интерфейс приложения (или ABI). ABI может очень точно определить, как машинный код приложения взаимодействует с системой во время выполнения. Вы должны указать ABI для каждой архитектуры ЦП, которая будет использоваться приложением.

Типичный ABI содержит следующую информацию:

Несколько Android CPU ABI

Установите соответствующую поддержку для APK

Просмотр ABI процессора

Обычно мы можем просмотреть архитектуру ABI, поддерживаемую ЦП, следующим образом:

Просмотр через команду adb

1. Подключаем телефон к компу
2. Откройте командное окно cmd и введите команду adb shell.
3. Затем введите команду cat / proc / cpuinfo.

Источник

Ваш ABI, скорее всего, неверен

ABI, или двоичный интерфейс приложения (Application Binary Interface), определяет способ взаимодействия двоичных файлов друг с другом на конкретной платформе и включает соглашение о вызовах. Большинство ABI имеют один конструктивный недостаток, который снижает производительность.

Давайте начнем с рассмотрения ABI System V для процессоров линейки x86. ABI классифицирует аргументы функции по ряду различных категорий; мы будем рассматривать только две:

INTEGER: Этот класс состоит из целочисленных типов, которые помещаются в один из регистров общего назначения.

MEMORY: Этот класс состоит из типов, которые будет переданы в память и возвращены через стек.

Я не буду подробно описывать правила классификации аргументов; достаточно сказать, что в общем смысле:

Целые числа, указатели и небольшие структуры имеют класс INTEGER и передаются в регистры.

Если структура слишком большая, она имеет класс MEMORY и передается в стек.

Если аргументов слишком много, те, которые не помещаются в регистры, будут переданы в стек.

Другими словами, передача больших структур по значению влечет за собой большие копии, и это меня огорчает.

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

И действительно, ABI должен поступать правильно по умолчанию. void foo ( struct bla ) намного легче читать, чем void foo ( const struct bla *restrict ), не говоря уже о том, что он лучше передает намерение и фактически обеспечивает более сильную семантическую гарантию.

Что ж, такова System V. Как обстоят дела с другими ABI? Microsoft похожа, но она передает структуры с указателем:

Структуры или объединения [не малых] размеров передаются как указатель на память, выделенную вызывающей стороной.

Это дает вам некоторую гибкость (хотя это также, вероятно, немного сбивает с толку переименователь памяти), но не решает реальной проблемы. «Память, выделенная вызывающей стороной», принадлежит вызываемой стороне, которая может изменять ее по своему желанию, поэтому вызывающей стороне по-прежнему необходимо излишнее копирование.

Больше ABI! ARM (извините, AAA arch 64):

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

RISC-V:

Агрегаты размером более 2×XLEN бит [примечание: какого черта вы говорите о битах?] передаются по ссылке и заменяются в списке аргументов адресом.

Аргументы, переданные по ссылке, могут быть изменены вызываемой стороной.

PowerPC:

Все [неоднородное] агрегаты передаются в последовательные регистры общего назначения (GPR), в регистры общего назначения и в память, или в память.

MIPS n32:

Структуры (structs), объединения (unions),или другие составные типы рассматриваются как последовательность двойных слов (doublewords), и передаются в целые регистры или регистры с плавающей запятой, как если бы они были простыми скалярными параметрами в той степени, в которой они помещаются, с любым избытком в стеке, упакованным в соответствии с обычной структурой памяти объекта.

Все это повторения одних и тех же двух ошибок.

Правильно установленный ABI должен передавать большие структуры по immutable ссылке, по большому счету избегая копирования. В случае, если требуется копия, это обычно происходит только один раз на вызываемой стороне, вместо того, чтобы повторяться каждой вызывающей стороной. Вызываемая сторона также обладает большей гибкостью и может копировать только те части структуры, которые фактически изменяются.

Источник

Устройства с несколькими ядрами & Xamarin. Android

ОС Android может работать в разных компьютерных архитектурах. В этом документе рассматриваются варианты архитектуры ЦП, в которых допускается выполнение приложения Xamarin.Android. Также в этом документе описываются принципы упаковки приложений Android для поддержки нескольких архитектур ЦП. Мы познакомим вас с двоичным интерфейсом приложений (ABI) и подскажем, какие интерфейсы ABI следует применять в приложениях Xamarin.Android.

Обзор

Это означает, что каждое приложение Android поддерживает по крайней мере один двоичный интерфейс внедренных приложений (EABI). EABI — это соглашения, специально созданные для внедренного программного обеспечения. Типичный интерфейс EABI описывает следующие форматы:

набор инструкций ЦП;

порядок следования байтов для операций загрузки и сохранения в памяти во время выполнения;

двоичный формат объектных файлов и библиотек программ, а также допустимые и поддерживаемые типы содержимого для этих файлов и библиотек;

различные соглашения о передаче данных между кодом приложения и системой (например, порядок применения регистров и (или) стека при вызове функций, ограничения выравнивания и т. д.);

ограничения выравнивания и размера для типов перечисления, структур, полей и массивов;

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

Архитектура armeabi и потокобезопасность

Описания интерфейсов ABI

Каждый ABI, поддерживаемый в Android, имеет уникальное имя.

armeabi

Это имя EABI для ЦП с архитектурой ARM, поддерживающих по меньшей мере набор инструкций ARMv5TE. Android соблюдает ABI для ARM GNU/Linux с прямым порядком байтов. Этот интерфейс ABI не поддерживает вычисления с плавающей запятой с использованием аппаратуры. Все операции с плавающей запятой выполняются вспомогательными программными функциями, которые собраны в статическую библиотеку libgcc.a компилятора. В armeabi не поддерживаются устройства SMP.

armeabi-v7a

Машинный код armeabi-v7a не выполняется на устройствах ARMv5.

arm64-v8a

Это набор 64-разрядных инструкций, основанный на архитектуре ЦП ARMv8. Эта архитектура используется в устройствах Nexus 9. В Xamarin.Android 5.1 реализована поддержка этой архитектуры (дополнительные сведения см. в разделе о поддержке 64-разрядной среды выполнения).

Это имя ABI для процессоров, поддерживающих набор инструкций, известный как x86 или IA-32. Этот интерфейс ABI соответствует набору инструкций для Pentium Pro, включая наборы для MMX, SSE, SSE2 и SSE3. Он не включает другие необязательные расширения IA-32, такие как:

Хотя платформа Google TV работает на архитектуре x86, ее не поддерживает Android NDK.

x86_64

Это имя ABI для процессоров, которые поддерживают 64-разрядный набор инструкций x86 (также известен как x64 или AMD64). В Xamarin.Android 5.1 реализована поддержка этой архитектуры (дополнительные сведения см. в разделе о поддержке 64-разрядной среды выполнения).

Формат файлов APK

AndroidManifest.xml — это файл в двоичном формате XML.

Classes. DEX — содержит код приложения, скомпилированный в Формат файла, который используется виртуальной машиной среды выполнения Android.

Resources. ARSC — этот файл содержит все предварительно скомпилированные ресурсы для приложения.

META-INF — этот каталог (если он есть) используется для хранения сведений о подписываниях, пакетов и данных конфигурации расширений.

Файл libmonodroid.so является обязательной собственной библиотекой для всех приложений Xamarin.Android.

Поддержка ABI для устройств Android

Каждое устройство Android поддерживает выполнение машинного кода, соответствующего одному из двух ABI:

«Основной» ABI — соответствует коду компьютера, используемому в образе системы.

«Дополнительный» ABI — это дополнительный интерфейс ABI, который также поддерживается образом системы.

Установка собственной библиотеки Android

Алгоритм установки собственных библиотек Android существенно различается для разных версий Android.

Установка собственных библиотек в Android до версии 4.0

После установки каталог собственных библиотек будет содержать следующее:

Другими словами, libone.so не устанавливается. Это приведет к проблемам, так как libone.so отсутствует и приложение не сможет загрузить его во время выполнения. Такое поведение нелогично, но заявка о включении его в список ошибок была классифицирована как «работает ожидаемым образом».

Следовательно, при использовании версий Android до 4,0 необходимо предоставить все собственные библиотеки для каждого интерфейса ABI, который будет поддерживаться приложением, то есть должен содержать:

Установка собственных библиотек: Android 4,0 — Android 4.0.3

В Android 4.0 Ice Cream Sandwich логика извлечения изменилась. Теперь Android просматривает все собственные библиотеки и для каждого файла проверяет, извлечена ли уже библиотека с таким базовым именем и выполняются ли следующие два условия:

файл еще не извлечен;

интерфейс ABI этой собственной библиотеки совпадает с основным или дополнительным интерфейсом ABI для целевого объекта.

После установки такого приложения каталог собственных библиотек будет содержать следующее:

К сожалению, результат этого алгоритма зависит от порядка файлов, что подробно описано в документе Issue 24321: Galaxy Nexus 4.0.2 uses armeabi native code when both armeabi and armeabi-v7a is included in apk (Проблема 24321: Galaxy Nexus 4.0.2 использует машинный код armeabi, если в APK есть файлы для armeabi и armeabi-v7a).

Кроме того, даже если armeabi указаны оба и armeabi-v7a ABI (как описано ниже в разделе armeabi ), Xamarin. Android создаст следующий элемент в. csproj :

Установка собственных библиотек в Android версии 4.0.4 и выше

После установки такого приложения каталог собственных библиотек будет содержать следующее:

Xamarin.Android и интерфейсы ABI

Xamarin.Android поддерживает следующие варианты 64-разрядной архитектуры:

Начиная с августа 2018 г. новые приложения должны будут использовать API уровня 26, а с августа 2019 г. будет необходимо выпускать 64-разрядные версии приложений в дополнение к 32-разрядным.

Xamarin.Android поддерживает следующие варианты 32-разрядной архитектуры:

^ Начиная с версии ^ armeabi больше не поддерживается.

Объявление поддерживаемых ABI

В Visual Studio для Mac поддерживаемую архитектуру можно выбрать на странице Android Build (Сборка Android) в разделе Project Options (Параметры проекта) на вкладке Advanced (Дополнительно), как показано на следующем снимке экрана:

Существуют ситуации, когда нужно объявить поддержку дополнительного интерфейса ABI, например в следующих случаях:

развертывание приложения на устройстве x86 ;

развертывание приложения на устройстве armeabi-v7a с обеспечением потокобезопасности.

Источник

Android Virtual Device (AVD) – какой CPU / ABI я должен выбрать?

При создании AVD существует три варианта выбора для CPU / ABI:

Каковы различия и какие из них выбрать? Есть ли тот, который охватывает большинство устройств?

Согласно документации разработчика Android, вы должны фактически создать виртуальное устройство для всех фреймворков и платформ, на которых вы собираетесь запускать код, поскольку большинство мобильных устройств на рынке в настоящее время работают на архитектуре ARM. Вы все равно должны проверить свои Код на отдельном виртуальном устройстве для каждого уровня фреймворка, который поддерживает ваш код.

Изображение системы
Рекомендуемые. Хотя у вас может быть одно или несколько устройств на базе Android, на которых можно протестировать ваше приложение, маловероятно, что у вас есть устройство для каждой версии Android, поддерживаемого вашим приложением. Хорошая практика загрузки системных изображений для всех версий Android, поддерживаемых вашим приложением, и тестирования вашего приложения на них с помощью эмулятора Android.

90% мобильных устройств оснащено ARM. Так что это будет лучший вариант

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

Atom Emulation работает быстрее, поэтому я буду использовать их для разработки и окончательной проверки в режиме arm или с помощью реального телефона.

В современных телефонах Android есть три основные архитектуры процессора. ARM, пожалуй, самый распространенный, так как он оптимизирован для потребления батареи. ARM64 – это эволюция оригинальной архитектуры ARM, которая поддерживает 64-битную обработку для более мощных вычислений и быстро становится стандартом в новых устройствах.

Источник

Установить не удалось CPU ABI несовместимый на устройстве с помощью intellij

Я видел некоторые вопросы об этом, но ни с реальными ответами, ни с деталями. Вот мой случай:

У меня есть приложение, которое использует Google Maps API v2, который работает просто отлично. Недавно я узнал, что не могу установить его на этой Не устройство на основе ARM.

чтобы прибить проблему, я работаю с образцами Google Maps, предоставленными с SDK (sdkextrasgooglegoogle_play_servicessamples)

что дает мне то же сообщение об ошибке во время установки:

Я получаю это сообщение только на реальном устройстве с помощью Intellij (12.1.1)

он отлично работает как с Eclipse на реальном устройстве, так и с Intellij на эмуляторе, настроенном с CPU: Intel Atom (x86)

любая помощь будет высоко ценится!

обновление

как и ожидалось, то же самое происходит с Android Studio

3 ответов

по умолчанию, IntelliJ предполагает, что libs папка в корне модуля Android содержит собственные библиотеки, даже если она просто содержит банки. Таким образом, он упаковывает APK, делая его похожим на родные библиотеки. У меня просто была аналогичная проблема, когда мое приложение не имело собственного кода и работало на эмуляторе по умолчанию, но получило предупреждение ABI при установке на эмулятор Genymotion. Чтобы исправить это, скажите IntelliJ (или Android Studio), что ваши библиотеки не являются родными код:

последний Genymotion не будет поддерживать двоичный ARM. Если у вас есть собственный код, скомпилированный для ARM, вы можете использовать Genymotion-ARM-Translation. Просто перетащите этот файл в домашнюю папку Genymotion и перезагрузитесь.

В Android studio исправьте эту проблему:

1 Скачать Genymotion-ARM-Translation_v1.1.zip

2 перетащите zip-файл в работающее виртуальное устройство и нажмите ok

3 перезапустить виртуальное устройство Genymotion

Источник