ABI 관리

다양한 Android 핸드셋은 각기 다른 CPU를 사용하므로, 서로 다른 명령 집합을 지원합니다. CPU와 명령 집합의 조합별로 나름의 애플리케이션 바이너리 인터페이스(ABI)가 있습니다. ABI는 애플리케이션의 기계어 코드가 런타임 시 시스템과 상호작용하는 방식을 매우 정밀하게 정의합니다. 앱에서 사용하도록 할 각 CPU 아키텍처의 ABI를 지정해야 합니다.

전형적인 ABI는 다음과 같은 정보를 포함합니다.

  • 기계어 코드가 사용해야 하는 CPU 명령 집합
  • 런타임 시 메모리 저장 및 로드의 엔디언
  • 실행 가능한 바이너리의 형식(예: 프로그램 및 공유 라이브러리)과 이러한 바이너리에서 지원하는 콘텐츠의 유형
  • 코드와 시스템 간 데이터 전달을 위한 다양한 규칙. 이러한 규칙에는 정렬 제약 조건뿐 아니라 시스템에서 함수를 호출할 때 스택과 레지스터를 사용하는 방법이 포함됩니다.
  • 런타임 시 기계어 코드에 사용할 수 있는 함수 기호의 목록(일반적으로 매우 구체적인 라이브러리 집합에서 비롯됨)

이 페이지에는 NDK에서 지원하는 ABI와 각 ABI의 작동 방식에 대한 정보가 나와 있습니다. 32비트 시스템의 ABI 문제 목록은 32비트 ABI 버그를 참조하세요.

지원되는 ABI

각각의 ABI는 하나 이상의 명령 집합을 지원합니다. 표 1에는 각 ABI에서 지원하는 명령 집합의 간략한 개요가 나와 있습니다.

표 1. ABI 및 지원되는 명령 집합

ABI 지원되는 명령 집합 참고사항
armeabi
  • ARMV5TE 이상
  • Thumb-1
  • r16에서 지원 중단되고, r17에서 삭제되었으며, 하드웨어 부동 소수점 없음
    armeabi-v7a
  • armeabi
  • Thumb-2
  • VFPv3-D16
  • 기타, 선택사항
  • ARMv5, v6 기기와 호환되지 않음
    arm64-v8a
  • AArch64
  • 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
  • 참고: 예전에는 NDK에서 32비트 및 64비트 MIPS를 지원했지만, NDK r17에서 지원이 삭제되었습니다.

    각 ABI에 대한 자세한 내용은 아래에 나와 있습니다.

    armeabi

    참고: 이 ABI는 NDK r17에서 삭제되었습니다.

    이 ABI는 ARMv5TE 명령 집합 이상을 지원하는 ARM 기반 CPU용입니다. 자세한 내용은 다음 문서를 참조하세요.

    AAPCS 표준에서는 유사하지만 별개의 ABI 제품군으로 EABI를 정의합니다. 또한, Android는 리틀 엔디언 ARM GNU/Linux ABI를 따릅니다.

    이 ABI는 하드웨어 지원 부동 소수점 계산을 지원하지 않습니다. 대신 모든 부동 소수점 연산에서는 컴파일러의 libgcc.a 정적 라이브러리에서 소프트웨어 도우미 함수를 사용합니다.

    armeabi ABI에서는 ARM의 Thumb(Thumb-1이라고도 함) 명령 집합을 지원합니다. Android.mk 파일의 LOCAL_ARM_MODE 변수를 사용해 다른 동작을 지정하지 않는 한 NDK는 기본적으로 Thumb 코드를 생성합니다.

    armeabi-v7a

    이 ABI는 여러 CPU 명령 집합 확장을 포함하도록 armeabi를 확장합니다. 이 Android 관련 ABI에서 지원하는 명령 확장은 다음과 같습니다.

    • Thumb-1과 유사한 간결성으로 32비트 ARM 명령과 비슷한 성능을 제공하는 Thumb-2 명령 집합 확장
    • VFP 하드웨어 FPU 명령. 더 구체적으로는 ARM 코어에서 다른 16개의 32비트 레지스터 외에 16개의 전용 64비트 부동 소수점 레지스터가 포함된 VFPv3-D16입니다.

    이 ABI의 경우 Advanced SIMD(NEON이라고도 함), VFPv3-D32, ThumbEE를 비롯하여 v7-a ARM 사양에서 설명하는 다른 확장은 선택사항입니다. 이러한 확장이 있을 것이라고 보장하지 못하므로 시스템에서는 런타임 시 확장을 사용할 수 있는지 검사해야 합니다. 사용할 수 없다면, 다른 코드 경로를 사용해야 합니다. 이 검사는 시스템에서 MMX, SSE2 및 x86 CPU의 기타 특수한 명령 집합을 확인하거나 사용하기 위해 일반적으로 수행하는 검사 작업과 유사합니다.

    이 런타임 검사를 수행하는 방법에 대한 자세한 내용은 cpufeatures 라이브러리를 참조하세요. 또한 NEON용 기계어 코드 빌드를 위한 NDK의 지원에 대한 자세한 내용은 NEON 지원을 참조하세요.

    armeabi-v7a ABI는 -mfloat-abi=softfp 스위치를 사용하여 함수 호출 중에 컴파일러에서 전용 부동 소수점 값 대신 코어 레지스터 쌍의 모든 double 값을 전달해야 한다는 규칙을 적용합니다. 시스템에서는 FP 레지스터를 사용해 모든 내부 계산을 수행할 수 있습니다. 그렇게 하면 계산 속도가 대폭 빨라집니다.

    arm64-v8a

    이 ABI는 AArch64를 지원하는 ARMv8 기반 CPU용으로, NEON 및 VFPv4 명령 집합도 포함되어 있습니다.

    자세한 내용은 ARMv8 기술 미리보기를 참조하고 ARM에 문의하시기 바랍니다.

    x86

    이 ABI는 보통 'x86' 또는 'IA-32'라는 명령 집합을 지원하는 CPU용으로, 특징은 다음과 같습니다.

    • 보통 다음과 같은 컴파일러 플래그가 있는 GCC에 의해 생성되는 명령
          -march=i686 -mtune=intel -mssse3 -mfpmath=sse -m32
          

      이러한 플래그는 MMX, SSE, SSE2, SSE3, SSSE3 명령 집합 확장과 함께 Pentium Pro 명령 집합을 대상으로 하며, 최고의 Intel 32비트 CPU 전반에 균형을 맞춰 최적화된 코드가 생성됩니다.

      컴파일러 플래그(특히 성능 최적화 관련)에 대한 자세한 내용은 GCC x86 성능 힌트를 참조하세요.

    • SVR 규칙과 반대로 표준 Linux x86 32비트 호출 규칙 사용. 자세한 내용은 다양한 C++ 컴파일러 및 운영체제의 호출 규칙의 섹션 6, '레지스터 사용'을 참조하세요.

    ABI는 다음과 같이 다른 선택적 IA-32 명령 집합 확장은 포함하지 않습니다.

    • MOVBE
    • SSE4의 변형

    이러한 확장을 활성화하기 위한 런타임 기능 검색을 사용하는 한 확장을 계속 사용할 수 있으며, 이러한 확장을 지원하지 않는 기기에는 대체 기능을 제공할 수 있습니다.

    NDK 툴체인은 16바이트 스택 정렬 후에 함수를 호출하는 것으로 가정합니다. 기본 도구와 옵션은 이 규칙을 적용합니다. 어셈블리 코드를 작성할 경우 스택 정렬 상태를 유지하고 다른 컴파일러도 이 규칙을 준수하도록 해야 합니다.

    자세한 내용은 다음 문서를 참조하세요.

    x86_64

    이 ABI는 보통 'x86-64'라는 명령 집합을 지원하는 CPU용으로, GCC에서 일반적으로 다음 컴파일러 플래그로 생성하는 명령을 지원합니다.

        -march=x86-64 -msse4.2 -mpopcnt -m64 -mtune=intel
        

    이러한 플래그는 GCC 문서에 따라 MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT 명령 집합 확장과 함께 x86-64 명령 집합을 대상으로 하며, 최고의 Intel 64비트 CPU 전반에 균형을 맞춰 최적화된 코드가 생성됩니다.

    컴파일러 플래그(특히 성능 최적화 관련)에 대한 자세한 내용은 GCC x86 성능을 참조하세요.

    이 ABI는 다음과 같이 다른 선택적 x86-64 명령 집합 확장은 포함하지 않습니다.

    • MOVBE
    • SHA
    • AVX
    • AVX2

    이러한 확장을 활성화하기 위한 런타임 기능 검색을 사용하는 한 확장을 계속 사용할 수 있으며, 이러한 확장을 지원하지 않는 기기에는 대체 기능을 제공할 수 있습니다.

    자세한 내용은 다음 문서를 참조하세요.

    특정 ABI를 위한 코드 생성

    기본적으로 NDK는 지원이 중단되지 않은 모든 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를 참조하세요.

    빌드 시스템의 기본 동작은 fat APK로도 알려진 단일 APK에 각 ABI용 바이너리를 포함하는 것입니다. fat APK는 단일 ABI용 바이너리만 포함한 APK보다 훨씬 큽니다. 따라서 호환성의 폭은 더 넓어지지만 APK가 커진다는 단점이 있습니다. 이 경우 분할 APK를 이용하여 최대 기기 호환성을 유지하면서 APK의 크기를 줄이는 것이 좋습니다.

    설치 시 패키지 관리자는 대상 기기에 가장 알맞은 기계어 코드만 압축을 풉니다. 자세한 내용은 설치 시 네이티브 코드의 자동 압축 풀기를 참조하세요.

    Android 플랫폼에서의 ABI 관리

    이 섹션에서는 Android 플랫폼이 APK에서 네이티브 코드를 관리하는 방법을 자세히 설명합니다.

    앱 패키지의 네이티브 코드

    Play 스토어와 Package Manager는 모두 다음 패턴과 일치하는 APK 내부의 파일 경로에서 NDK가 생성한 라이브러리를 찾을 수 있을 것으로 예상합니다.

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

    여기에서 <abi>지원되는 ABI에 표시된 ABI 이름 중 하나이고, <name>Android.mk 파일의 LOCAL_MODULE 변수에 정의된 라이브러리의 이름입니다. APK 파일은 zip 파일에 불과하므로 파일을 열어서 공유된 네이티브 라이브러리가 속한 위치를 간단히 확인할 수 있습니다.

    시스템이 예상한 위치에서 네이티브 공유 라이브러리를 찾지 못하면 이러한 라이브러리를 사용할 수 없습니다. 그럴 때는 앱 자체에서 라이브러리를 복사한 다음 dlopen()을 수행해야 합니다.

    fat APK에서 각 라이브러리는 해당 ABI와 이름이 일치하는 각 디렉토리 아래에 위치합니다. 예를 들어 fat 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 기기는 armeabi 디렉토리와 armeabi-v7a 디렉토리가 모두 있는 경우 armeabi-v7a 대신 armeabi 디렉토리에서 네이티브 라이브러리를 설치합니다. 이는 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로 정의하는데, 이는 각각에 대해 생성되는 애플리케이션 네이티브 바이너리를 실행할 수 있기 때문입니다.

    64비트 기기는 32비트 변형도 지원합니다. arm64-v8a 기기를 예로 들면 이 기기는 armeabi 및 armeabi-v7a 코드도 실행할 수 있습니다. 다만 애플리케이션이 arm64-v8a를 대상으로 하는 경우 armeabi-v7a 버전 애플리케이션을 실행하는 기기에 의존하는 것 보다 64비트 기기에서 더욱 잘 수행된다는 점에 유의해야 합니다.

    많은 x86 기반 기기는 armeabi-v7aarmeabi NDK 바이너리를 실행할 수도 있습니다. 이러한 기기의 경우 기본 ABI는 x86, 보조 ABI는 armeabi-v7a가 됩니다.

    설치 시 네이티브 코드의 자동 압축 풀기

    애플리케이션을 설치할 때 패키지 관리자 서비스는 APK를 검사하여 다음 양식의 공유 라이브러리가 있는지 찾아봅니다.

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

    공유 라이브러리가 하나도 발견되지 않고 보조 ABI가 정의된 경우 이 서비스는 다음 양식의 공유 라이브러리가 있는지 검사합니다.

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

    위 양식의 라이브러리가 발견되면 패키지 관리자는 이를 애플리케이션의 data 디렉토리(data/data/<package_name>/lib/)에 있는 /lib/lib<name>.so로 복사합니다.

    공유 객체 파일이 하나도 없으면 애플리케이션이 빌드되고 설치되지만 런타임 시 다운됩니다.