Android ABI

不同的 Android 设备使用不同的 CPU,这些 CPU 又支持不同的指令集。CPU 和指令集的每种组合都有自己的应用二进制接口 (ABI)。ABI 包含以下信息

  • 可使用的 CPU 指令集(及扩展)。
  • 运行时内存存储和加载的字节序。Android 始终采用小端序。
  • 应用与系统之间传递数据的约定,包括对齐限制以及系统调用函数时如何使用堆栈和寄存器。
  • 可执行二进制文件的格式,例如程序和共享库,以及它们支持的内容类型。Android 始终使用 ELF。有关详情,请参阅 ELF System V 应用二进制接口
  • C++ 名称的重整方式。有关详情,请参阅 通用/Itanium C++ ABI

本页列出了 NDK 支持的 ABI,并提供了关于每种 ABI 工作原理的信息。

ABI 还可以指平台支持的原生 API。如需查看影响 32 位系统的此类 ABI 问题列表,请参阅32 位 ABI 错误

支持的 ABI

表 1. ABI 和支持的指令集。

ABI 支持的指令集 备注
armeabi-v7a
  • armeabi
  • Thumb-2
  • Neon
  • 与 ARMv5/v6 设备不兼容。
    arm64-v8a
  • AArch64
  • 仅限 Armv8.0。
    x86
  • x86 (IA-32)
  • MMX
  • SSE/2/3
  • SSSE3
  • 不支持 MOVBE 或 SSE4。
    x86_64
  • x86-64
  • MMX
  • SSE/2/3
  • SSSE3
  • SSE4.1, 4.2
  • POPCNT
  • CMPXCHG16B
  • LAHF-SAHF
  • 完整的 x86-64-v2

    注意:NDK 历史版本曾支持 ARMv5 (armeabi) 以及 32 位和 64 位 MIPS,但对这些 ABI 的支持已在 NDK r17 中移除。

    armeabi-v7a

    此 ABI 适用于 32 位 ARM CPU。它包含 Thumb-2 和 Neon。

    有关 ABI 中非 Android 特定部分的信息,请参阅 面向 ARM 架构的应用二进制接口 (ABI)

    NDK 的构建系统默认会生成 Thumb-2 代码,除非您在 Android.mk 文件中使用 LOCAL_ARM_MODE(用于 ndk-build)或在配置 CMake 时使用 ANDROID_ARM_MODE

    如需了解有关 Neon 历史记录的更多信息,请参阅Neon 支持

    出于历史原因,此 ABI 使用 -mfloat-abi=softfp,导致在进行函数调用时,所有 float 值都通过整数寄存器传递,所有 double 值都通过整数寄存器对传递。尽管名称如此,这仅影响浮点数的调用约定:编译器仍将使用硬件浮点指令进行算术运算。

    此 ABI 使用 64 位 long double(与 double 相同的 IEEE binary64)。

    arm64-v8a

    此 ABI 适用于 64 位 ARM CPU。

    有关 ABI 中非 Android 特定部分的完整详细信息,请参阅 Arm 的学习架构。Arm 还在64 位 Android 开发中提供了一些移植建议。

    您可以在 C 和 C++ 代码中使用Neon 内联函数来利用高级 SIMD 扩展。面向 Armv8-A 的 Neon 程序员指南提供了有关 Neon 内联函数和 Neon 编程的更多信息。

    在 Android 上,平台特定的 x18 寄存器保留用于 ShadowCallStack,您的代码不应触及此寄存器。当前版本的 Clang 在 Android 上默认使用 -ffixed-x18 选项,因此除非您有手写的汇编代码(或非常旧的编译器),否则无需担心此问题。

    此 ABI 使用 128 位 long double (IEEE binary128)。

    x86

    此 ABI 适用于支持通常称为“x86”、“i386”或“IA-32”指令集的 CPU。

    Android 的 ABI 包含基本指令集以及 MMXSSESSE2SSE3SSSE3 扩展。

    此 ABI 不包含任何其他可选的 IA-32 指令集扩展,例如 MOVBE 或 SSE4 的任何变体。您仍然可以使用这些扩展,前提是使用运行时特征探测来启用它们,并为不支持它们的设备提供备用方案。

    NDK 工具链假定函数调用前栈对齐为 16 字节。默认工具和选项强制执行此规则。如果您正在编写汇编代码,必须确保保持栈对齐,并确保其他编译器也遵守此规则。

    如需了解详情,请参阅以下文档

    此 ABI 使用 64 位 long double(与 double 相同的 IEEE binary64,而不是更常见的仅适用于 Intel 的 80 位 long double)。

    x86_64

    此 ABI 适用于支持通常称为“x86-64”指令集的 CPU。

    Android 的 ABI 包含基本指令集以及 MMXSSESSE2SSE3SSSE3SSE4.1SSE4.2 以及 POPCNT 指令。

    此 ABI 不包含任何其他可选的 x86-64 指令集扩展,例如 MOVBE、SHA 或 AVX 的任何变体。您仍然可以使用这些扩展,前提是使用运行时特征探测来启用它们,并为不支持它们的设备提供备用方案。

    如需了解详情,请参阅以下文档

    此 ABI 使用 128 位 long double (IEEE binary128)。

    为特定 ABI 生成代码

    Gradle

    Gradle(无论是通过 Android Studio 还是从命令行使用)默认会为所有非弃用的 ABI 构建。如需限制应用支持的 ABI 集,请使用 abiFilters。例如,要仅为 64 位 ABI 构建,请在您的 build.gradle 中设置以下配置

    android {
        defaultConfig {
            ndk {
                abiFilters 'arm64-v8a', 'x86_64'
            }
        }
    }
    

    ndk-build

    ndk-build 默认会为所有非弃用的 ABI 构建。您可以通过在 Application.mk 文件中设置 APP_ABI 来指定特定 ABI。以下代码段展示了使用 APP_ABI 的几个示例

    APP_ABI := arm64-v8a  # Target only arm64-v8a
    APP_ABI := all  # Target all ABIs, including those that are deprecated.
    APP_ABI := armeabi-v7a x86_64  # Target only armeabi-v7a and x86_64.
    

    有关可以为 APP_ABI 指定的值的更多信息,请参阅 Application.mk

    CMake

    对于 CMake,您一次只能构建一个 ABI,并且必须明确指定您的 ABI。您可以通过 ANDROID_ABI 变量来完成此操作,该变量必须在命令行中指定(不能在 CMakeLists.txt 中设置)。例如

    $ cmake -DANDROID_ABI=arm64-v8a ...
    $ cmake -DANDROID_ABI=armeabi-v7a ...
    $ cmake -DANDROID_ABI=x86 ...
    $ cmake -DANDROID_ABI=x86_64 ...
    

    对于使用 NDK 构建时必须传递给 CMake 的其他标志,请参阅 CMake 指南

    构建系统的默认行为是将每种 ABI 的二进制文件包含在单个 APK 中,也称为胖 APK。胖 APK 明显大于仅包含单一 ABI 二进制文件的 APK;这样做的好处是获得了更广泛的兼容性,但代价是 APK 体积更大。强烈建议您利用App BundleAPK Splits来减小 APK 的大小,同时仍保持设备的最大兼容性。

    在安装时,软件包管理器仅解包目标设备最合适的机器码。有关详细信息,请参阅安装时原生代码的自动提取

    Android 平台上的 ABI 管理

    本部分详细介绍了 Android 平台如何在 APK 中管理原生代码。

    应用包中的原生代码

    Play 商店和软件包管理器都期望在 APK 中找到与以下模式匹配的文件路径上的 NDK 生成库

    /lib/<abi>/lib<name>.so
    

    此处,<abi>支持的 ABI 下列出的 ABI 名称之一,<name> 是您在 Android.mk 文件中为 LOCAL_MODULE 变量定义的库名称。由于 APK 文件只是 zip 文件,因此打开它们并确认共享原生库是否位于正确位置非常简单。

    如果系统未在其期望的位置找到原生共享库,则无法使用它们。在这种情况下,应用本身必须复制这些库,然后执行 dlopen()

    在胖 APK 中,每个库都位于与相应 ABI 名称匹配的目录中。例如,胖 APK 可能包含

    /lib/armeabi/libfoo.so
    /lib/armeabi-v7a/libfoo.so
    /lib/arm64-v8a/libfoo.so
    /lib/x86/libfoo.so
    /lib/x86_64/libfoo.so
    

    注意:运行 4.0.3 或更早版本的基于 ARMv7 的 Android 设备,如果 armeabiarmeabi-v7a 目录都存在,则会从 armeabi 目录安装原生库,而不是 armeabi-v7a 目录。这是因为在 APK 中,/lib/armeabi/ 出现在 /lib/armeabi-v7a/ 之后。此问题已在 4.0.4 版本中修复。

    Android 平台 ABI 支持

    Android 系统在运行时知道它支持哪些 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-v7aarmeabi NDK 二进制文件。对于此类设备,主要 ABI 将是 x86,辅助 ABI 是 armeabi-v7a

    您可以强制安装适用于特定ABI 的 APK。这对于测试很有用。使用以下命令

    adb install --abi abi-identifier path_to_apk
    

    安装时原生代码的自动提取

    安装应用时,软件包管理器服务会扫描 APK,并查找任何形式的共享库

    lib/<primary-abi>/lib<name>.so
    

    如果未找到,并且您定义了辅助 ABI,则服务会扫描形式为

    lib/<secondary-abi>/lib<name>.so
    

    找到所需的库后,软件包管理器会将其复制到应用原生库目录 (<nativeLibraryDir>/) 下的 /lib/lib<name>.so。以下代码段获取 nativeLibraryDir

    Kotlin

    import android.content.pm.PackageInfo
    import android.content.pm.ApplicationInfo
    import android.content.pm.PackageManager
    ...
    val ainfo = this.applicationContext.packageManager.getApplicationInfo(
            "com.domain.app",
            PackageManager.GET_SHARED_LIBRARY_FILES
    )
    Log.v(TAG, "native library dir ${ainfo.nativeLibraryDir}")

    Java

    import android.content.pm.PackageInfo;
    import android.content.pm.ApplicationInfo;
    import android.content.pm.PackageManager;
    ...
    ApplicationInfo ainfo = this.getApplicationContext().getPackageManager().getApplicationInfo
    (
        "com.domain.app",
        PackageManager.GET_SHARED_LIBRARY_FILES
    );
    Log.v( TAG, "native library dir " + ainfo.nativeLibraryDir );

    如果根本没有共享对象文件,则应用可以构建和安装,但在运行时会崩溃。

    ARMv9:为 C/C++ 启用 PAC 和 BTI

    启用 PAC/BTI 将提供针对某些攻击向量的保护。PAC 通过在函数序言中对返回地址进行加密签名,并在函数尾声中检查返回地址是否仍正确签名来保护返回地址。BTI 通过要求每个分支目标都是一个特殊指令来防止跳到代码中的任意位置,该指令除了告诉处理器可以在此处着陆外,不执行任何其他操作。

    Android 使用 PAC/BTI 指令,这些指令在不支持新指令的旧处理器上不起作用。只有 ARMv9 设备才具有 PAC/BTI 保护,但您也可以在 ARMv8 设备上运行相同的代码:无需为您的库创建多个变体。即使在 ARMv9 设备上,PAC/BTI 也仅适用于 64 位代码。

    启用 PAC/BTI 将导致代码大小略微增加,通常为 1%。

    请参阅 Arm 的学习架构 - 为复杂软件提供保护PDF),了解 PAC/BTI 目标攻击向量以及保护工作原理的详细说明。

    构建更改

    ndk-build

    在您的 Android.mk 文件中的每个模块中设置 LOCAL_BRANCH_PROTECTION := standard

    CMake

    在您的 CMakeLists.txt 中的每个目标中使用 target_compile_options($TARGET PRIVATE -mbranch-protection=standard)

    其他构建系统

    使用 -mbranch-protection=standard 编译您的代码。此标志仅在编译 arm64-v8a ABI 时有效。您在链接时无需使用此标志。

    故障排除

    我们尚未发现编译器对 PAC/BTI 的支持存在任何问题,但请注意

    • 链接时注意不要混用 BTI 和非 BTI 代码,否则生成的库将未启用 BTI 保护。您可以使用 llvm-readelf 检查生成的库是否包含 BTI 标记。
    $ llvm-readelf --notes LIBRARY.so
    [...]
    Displaying notes found in: .note.gnu.property
      Owner                Data size    Description
      GNU                  0x00000010   NT_GNU_PROPERTY_TYPE_0 (property note)
        Properties:    aarch64 feature: BTI, PAC
    [...]
    $
    
    • 旧版本的 OpenSSL(早于 1.1.1i)在手写汇编代码中存在导致 PAC 失败的错误。请升级到当前版本的 OpenSSL。

    • 某些应用 DRM 系统的旧版本会生成违反 PAC/BTI 要求的代码。如果您正在使用应用 DRM 并在启用 PAC/BTI 时遇到问题,请联系您的 DRM 供应商获取修复版本。