Андроид abi что это

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

Android CPU ABI

Кратко об ABI

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

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

• Набор инструкций ЦП, который должен использовать машинный код.
• Порядок байтов хранения и загрузки памяти во время выполнения.
• Формат исполняемых двоичных файлов (например, программ и общих библиотек) и типы поддерживаемого содержимого.
• Различные соглашения, используемые для анализа данных между контентом и системой. Эти соглашения включают ограничения на выравнивание и то, как система использует стек и регистры при вызове функций.
• Список функциональных символов, доступных для машинного кода во время выполнения — обычно из очень определенного набора библиотек.

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

Архитектура процессора	описание
armeabi	ARM v5TE 5-го поколения, использующий программное вычисление с плавающей запятой, совместим со всеми устройствами ARM, высокая универсальность, низкая скорость
armeabi-v7a	ARM v7 7-го поколения, использующий аппаратные операции с плавающей запятой, с расширенными расширенными функциями
arm64-v8a	8-е поколение, 64-битное, включая AArch32 и AArch64, два состояния выполнения, соответствующие 32, 64-битным
x86	Intel 32 бит, обычно используется для планшетов
x86_64	Intel 64 бит, обычно используется для планшетов
mips	Меньше контактов
mips64	Меньше контактов

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

Если ваш проект включает разработку NDK, как правило, для уменьшения размера APK, вы выполните указанные выше настройки в build.gradle, чтобы объявить архитектуру ABI, поддерживаемую APK. Другие библиотеки, такие как .so, соответствующие ABI, которые не объявлены не будут упакованы в APK.

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

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

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

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

Источник

Андроид abi что это

Краткое описание:
Если вы никак не можете забыть легендарный Machinarium, эта новая история про маленького робота наверняка придется вам по душе.

Описание:
= PocketGamer Big Indie Pitch Asian Division Winner=
= IMGA Selected Game=
= Indieplay, Excellence at Visual Art, Nominee =

“Great example of storytelling and point and click genres…Absolutely loved it.” —PocketGamer

With the pace of technological development, our lives increasingly rely on machines. But is that a good thing?

Technology can lead us astray, but it can also be our redemption…
One day in the distant future, the obsolete household robot Abi finds the hibernating industrial robot DD, and together they escape the warehouse in which they have been locked away. Once they get out, they discover that humans have mysteriously disappeared from the earth. Where did the humans go and what can explain their disappearance? It’s up to you, Abi, and DD to find out.

In this one-of-a-kind and mysterious world, you will experience:
-Unique gameplay. Switch between the two main characters and unlock the secrets of this intriguing world by solving puzzles.
-Stunning artwork throughout, depicting an abandoned yet surprisingly beautiful world.
-Musical Score by well-known composer creates an immersive experience.
-A moving and thought-provoking story
-An intriguing post-apocalyptic journey

Русский интерфейс: Нет
Системные требования: Android 4.1+

Скачать: версия: 1.1
Abi — A Robots Tale v1.1.apk ( 80.4 МБ )

С запросами на обновление игры обращайтесь в тему Обновите игру!

Сообщение отредактировал Mr_Kumar — 28.12.17, 18:58

Источник

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

Анализ Android ABI

Концепция Android ABI

Полное название ABI: Application binary interface (двоичный интерфейс приложения), определяет набор правил, которые позволяют скомпилированным двоичным кодам объектов работать во всех операционных системах, совместимых с ABI, без изменений.

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

Некоторые процессоры могут поддерживать несколько правил взаимодействия, но это совместимо за счет производительности.

Основная архитектура ABI

1. armeabiv-v7a: процессоры ARM 7-го поколения и выше. Его используют большинство устройств Android, выпущенных после 2011 года.
2. arm64-v8a: 8-е поколение, 64-битный процессор ARM, несколько устройств, Samsung Galaxy S6 — одно из них.
3. armeabi: 5-е и 6-е поколения процессоров ARM в основном используются в первых мобильных телефонах.
4. x86: Больше используются планшеты и симуляторы.
5. x86_64: 64-битный планшет.

Связь между ABI и CPU

Когда приложение установлено на устройстве, будет установлен только файл .so, соответствующий архитектуре ЦП, поддерживаемой устройством. Если поддерживается несколько архитектур ABI, он будет следовать приоритету

Конкретные типы поддержки следующие:

ARMv5(CPU):armeabi(ABI)
ARMv7:armeabi,armeabi-v7a
ARMv8:armeabi,armeabi-v7a，arm64-v8a
MIPS:mips
MIPS64:mips,mips64
x86:x86(1),armeabi(2),armeabi-v7a(3)
x86_64:armeabi,x86,x86_64

Видно, что большинство процессоров имеют прямую совместимость, но при выборе ABI будет приоритет.

Например, для процессоров X86 предпочтительнее использовать пакет .so в каталоге x86. Если он существует, другие поддерживаемые архитектуры ABI не будут установлены; если нет каталога x86, будет выбран .so в каталоге armeabi-v7a, и будет выбран последний. Выберите файл .so в каталоге armeabi.

ps: Хотя устройства X86 могут запускать библиотеку so под armeabi, производительность может быть потеряна, и нет гарантии, что сбоев не произойдет, особенно если есть библиотеки, созданные небольшими компаниями.

Проблемы при использовании

.so файл, поместите в каталог ABI с низким приоритетом

Архитектура процессора устройства — ARMv7, а файл ABI — armeabi-v7a, но он помещается в каталог armeabi.

1. Если в проекте есть каталог armeabi-v7a и в нем нет библиотеки so, ARMv7 сначала загружает каталог armeabi-v7a, а если нет соответствующей библиотеки so, будет сообщено об ошибке.

2. В проекте есть только каталог armeabi. ARMv7 одновременно загрузит каталог armeabi и библиотеку so в каталог, что эквивалентно загрузке библиотеки armeabi rule so. Из-за функции прямой совместимости он не будет сообщать об ошибке и может работать, но Производительность будет потеряна.

Файлы .so помещаются в каталог ABI с высоким приоритетом.

Архитектура ЦП устройства — ARMv7, а файл ABI — armeabi, но он помещается в каталог armeabi-v7a.

Может загружаться, но можно ли пользоваться? Я тоже не уверен. Поскольку библиотека so armeabi может не обязательно поддерживать правила взаимодействия с интерфейсом, установленные armeabi-v7a.

Приоритет файлов ABI в нескольких сторонних SDK различается.

Приоритет файлов ABI в двух сторонних SDK различается. Когда мобильный телефон загружен и работает, библиотека с низким приоритетом не загружается.

Архитектура процессора моего мобильного телефона — ARMv7, и в проекте используются два сторонних SDK: Enterprise A и Enterprise B.

Предприятие A: ABI-файл — это armeabi-v7a, поместите его в каталог armeabi-v7a.
Предприятие B: файл ABI — это armeabi-v5te, поместите его в каталог armeabi.

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

Это связано с тем, что низкий приоритет, то есть пакет so предприятия B, не загружен, и его нельзя использовать в обычном режиме, что приводит к ошибке.

Решение:

1. Используйте файлы ABI с одинаковым приоритетом и поместите файлы ABI в каталог ABI с тем же приоритетом.

Предприятие A: ABI-файл — это armeabi-v5te, он находится в каталоге armeabi.
Предприятие B: файл ABI — это armeabi-v5te, поместите его в каталог armeabi.
или

Предприятие A: ABI-файл — это armeabi-v7a, поместите его в каталог armeabi-v7a.
Предприятие B: файл ABI — armeabi-v7a, поместите его в каталог armeabi-v7a.

2. Используйте файлы ABI с разными приоритетами и помещайте файлы ABI в каталоги ABI с одинаковым приоритетом. Обычно это не рекомендуется.

Предприятие A: ABI-файл — это armeabi-v7a, но он находится в каталоге armeabi.
Предприятие B: файл ABI — это armeabi-v5te, поместите его в каталог armeabi.
или

Предприятие A: ABI-файл — это armeabi-v7a, поместите его в каталог armeabi-v7a.
Предприятие B: файл ABI — это armeabi-v5te, но он помещается в каталог armeabi-v7a.

Важные правила so файлов

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

Совместимость с NDK

При использовании NDK выберите платформу компиляции, соответствующую minsdkVersion приложения, поскольку NDK имеет обратную совместимость.

Меры предосторожности

Таким образом, все папки ABI должны быть согласованы

Если наше приложение решает поддерживать несколько ABI, мы должны обратить особое внимание: для этого в каждом ABI поддерживается либо все, либо ни один. Он не должен смешиваться, но должен предоставлять соответствующий файл .so для каждого каталога ABI.

Источник

Android ABIs

Different Android devices use different CPUs, which in turn support different instruction sets. Each combination of CPU and instruction set has its own Application Binary Interface (ABI). An ABI includes the following information:

• The CPU instruction set (and extensions) that can be used.
• The endianness of memory stores and loads at runtime. Android is always little-endian.
• Conventions for passing data between applications and the system, including alignment constraints, and how the system uses the stack and registers when it calls functions.
• The format of executable binaries, such as programs and shared libraries, and the types of content they support. Android always uses ELF. For more information, see ELF System V Application Binary Interface.
• How C++ names are mangled. For more information, see Generic/Itanium C++ ABI.

This page enumerates the ABIs that the NDK supports, and provides information about how each ABI works.

ABI can also refer to the native API supported by the platform. For a list of those kinds of ABI issues affecting 32-bit systems, see 32-bit ABI bugs.

Supported ABIs

Table 1. ABIs and supported instruction sets.

ABI	Supported Instruction Sets	Notes
armeabi-v7a	armeabi Thumb-2 VFPv3-D16	Incompatible with ARMv5/v6 devices.
arm64-v8a	AArch64
x86	x86 (IA-32) MMX SSE/2/3 SSSE3	No support for MOVBE or SSE4.
x86_64	x86-64 MMX SSE/2/3 SSSE3 SSE4.1, 4.2 POPCNT

Note: Historically the NDK supported ARMv5 (armeabi), and 32-bit and 64-bit MIPS, but support for these ABIs was removed in NDK r17.

armeabi-v7a

This ABI is for 32-bit ARM-based CPUs. The Android variant includes Thumb-2 and the VFP hardware floating point instructions, specifically VFPv3-D16, which includes 16 dedicated 64-bit floating point registers.

For information about the parts of the ABI that aren’t Android-specific, see Application Binary Interface (ABI) for the ARM Architecture

The NDK’s build systems generate Thumb-2 code by default unless you use LOCAL_ARM_MODE in your Android.mk for ndk-build or ANDROID_ARM_MODE when configuring CMake.

Other extensions including Advanced SIMD (Neon) and VFPv3-D32 are optional. For more information, see Neon Support.

The armeabi-v7a ABI uses -mfloat-abi=softfp to enforce the rule that, although system can execute floating-point code, the compiler must pass all float values in integer registers and all double values in integer register pairs when making function calls.

arm64-v8a

This ABI is for ARMv8-A based CPUs, which support the 64-bit AArch64 architecture. It includes the Advanced SIMD (Neon) architecture extensions.

You can use Neon intrinsics in C and C++ code to take advantage of the Advanced SIMD extension. The Neon Programmer’s Guide for Armv8-A provides more information about Neon intrinsics and Neon programming in general.

See Arm’s Learn the Architecture for complete details of the parts of the ABI that aren’t Android-specific. Arm also offers some porting advice in 64-bit Android Development.

On Android, the platform-specific x18 register is reserved for ShadowCallStack and should not be touched by your code. Current versions of Clang default to using the -ffixed-x18 option on Android, so unless you have hand-written assembler (or a very old compiler) you shouldn’t need to worry about this.

This ABI is for CPUs supporting the instruction set commonly known as «x86», «i386», or «IA-32». Characteristics of this ABI include:

Instructions normally generated by GCC with compiler flags such as the following:

These flags target the Pentium Pro instruction set, along with the the MMX, SSE, SSE2, SSE3, and SSSE3 instruction set extensions. The generated code is an optimization balanced across the top Intel 32-bit CPUs.

For more information on compiler flags, particularly related to performance optimization, refer to GCC x86 Performance Hints.

Use of the standard Linux x86 32-bit calling convention, as opposed to the one for SVR. For more information, see section 6, «Register Usage», of Calling conventions for different C++ compilers and operating systems.

The ABI does not include any other optional IA-32 instruction set extensions, such as:

You can still use these extensions, as long as you use runtime feature-probing to enable them, and provide fallbacks for devices that do not support them.

The NDK toolchain assumes 16-byte stack alignment before a function call. The default tools and options enforce this rule. If you are writing assembly code, you must make sure to maintain stack alignment, and ensure that other compilers also obey this rule.

Refer to the following documents for more details:

x86_64

This ABI is for CPUs supporting the instruction set commonly referred to as «x86-64.» It supports instructions that GCC typically generates with the following compiler flags:

These flags target the x86-64 instruction set, according to the GCC documentation. along with the MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, and POPCNT instruction-set extensions. The generated code is an optimization balanced across the top Intel 64-bit CPUs.

For more information on compiler flags, particularly related to performance optimization, refer to GCC x86 Performance Hints.

This ABI does not include any other optional x86-64 instruction set extensions, such as:

You can still use these extensions, as long as you use runtime feature probing to enable them, and provide fallbacks for devices that do not support them.

Refer to the following documents for more details:

Generate code for a specific ABI

Gradle

Gradle (whether used via Android Studio or from the command line) builds for all non-deprecated ABIs by default. To restrict the set of ABIs that your application supports, use abiFilters . For example, to build for only 64-bit ABIs, set the following configuration in your build.gradle :

ndk-build

ndk-build builds for all non-deprecated ABIs by default. You can target a specific ABIs by setting APP_ABI in your Application.mk file. The following snippet shows a few examples of using APP_ABI :

For more information on the values you can specify for APP_ABI , see Application.mk.

CMake

With CMake, you build for a single ABI at a time and must specify your ABI explicitly. You do this with the ANDROID_ABI variable, which must be specified on the command line (cannot be set in your CMakeLists.txt). For example:

For the other flags that must be passed to CMake to build with the NDK, see the CMake guide.

The default behavior of the build system is to include the binaries for each ABI in a single APK, also known as a fat APK. A fat APK is significantly larger than one containing only the binaries for a single ABI; the tradeoff is gaining wider compatibility, but at the expense of a larger APK. It is strongly recommended that you take advantage of either App Bundles or APK Splits to reduce the size of your APKs while still maintaining maximum device compatibility.

At installation time, the package manager unpacks only the most appropriate machine code for the target device. For details, see Automatic extraction of native code at install time.

ABI management on the Android platform

This section provides details about how the Android platform manages native code in APKs.

Native code in app packages

Both the Play Store and Package Manager expect to find NDK-generated libraries on filepaths inside the APK matching the following pattern:

Here, is one of the ABI names listed under Supported ABIs, and is the name of the library as you defined it for the LOCAL_MODULE variable in the Android.mk file. Since APK files are just zip files, it is trivial to open them and confirm that the shared native libraries are where they belong.

If the system does not find the native shared libraries where it expects them, it cannot use them. In such a case, the app itself has to copy the libraries over, and then perform dlopen() .

In a fat APK, each library resides under a directory whose name matches a corresponding ABI. For example, a fat APK may contain:

Note: ARMv7-based Android devices running 4.0.3 or earlier install native libraries from the armeabi directory instead of the armeabi-v7a directory if both directories exist. This is because /lib/armeabi/ comes after /lib/armeabi-v7a/ in the APK. This issue is fixed from 4.0.4.

Android platform ABI support

The Android system knows at runtime which ABI(s) it supports, because build-specific system properties indicate:

• The primary ABI for the device, corresponding to the machine code used in the system image itself.
• Optionally, secondary ABIs, corresponding to other ABI that the system image also supports.

This mechanism ensures that the system extracts the best machine code from the package at installation time.

For best performance, you should compile directly for the primary ABI. For example, a typical ARMv5TE-based device would only define the primary ABI: armeabi . By contrast, a typical, ARMv7-based device would define the primary ABI as armeabi-v7a and the secondary one as armeabi , since it can run application native binaries generated for each of them.

64-bit devices also support their 32-bit variants. Using arm64-v8a devices as an example, the device can also run armeabi and armeabi-v7a code. Note, however, that your application will perform much better on 64-bit devices if it targets arm64-v8a rather than relying on the device running the armeabi-v7a version of your application.

Many x86-based devices can also run armeabi-v7a and armeabi NDK binaries. For such devices, the primary ABI would be x86 , and the second one, armeabi-v7a .

You can force install an apk for a specific ABI. This is useful for testing. Use the following command:

Automatic extraction of native code at install time

When installing an application, the package manager service scans the APK, and looks for any shared libraries of the form:

If none is found, and you have defined a secondary ABI, the service scans for shared libraries of the form:

When it finds the libraries that it’s looking for, the package manager copies them to /lib/lib .so , under the application’s native library directory ( / ). The following snippets retrieve the nativeLibraryDir :

Kotlin

If there is no shared-object file at all, the application builds and installs, but crashes at runtime.

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник