ABI란?

ABI란? (<https://developer.android.com/ndk/guides/abis.html?hl=ko>)

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

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

  1. 기계어 코드가 사용해야 하는 CPU 명령 집합

  2. 런타임 시 메모리 저장 및 로드의 엔디언

  3. 실행 가능한 바이너리의 형식(예: 프로그램 및 공유 라이브러리)과 이러한 바이너리가 지원하는 콘텐츠의 유형

  4. 코드와 시스템 간에 데이터를 전달하기 위한 다양한 규칙. 이러한 규칙에는 정렬 제약 조건뿐 아니라 시스템에서 함수를 호출할 때 스택과 레지스터를 사용하는 방법이 포함된다.

  5. 런타임 기계어 코드에 사용 가능한 함수 기호의 목록(일반적으로 매우 구체적인 라이브러리 집합에서 비롯됨)

• 지원되는 ABI

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

    ABI 지원되는

    [`armeabi`](https://developer.android.com/ndk/guides/abis.html?hl=ko#armeabi)	ARMV5TE 이상Thumb-1	r16에서 지원 중단됨. r17에서 삭제됨. 하드웨어 부동 소수점 없음.
    [`armeabi-v7a`](https://developer.android.com/ndk/guides/abis.html?hl=ko#v7a)	armeabiThumb-2VFPv3-D16기타, 선택 사항	ARMv5, v6 기기와 호환 안 됨.
    [`arm64-v8a`](https://developer.android.com/ndk/guides/abis.html?hl=ko#arm64-v8a)	AArch64
    [`x86`](https://developer.android.com/ndk/guides/abis.html?hl=ko#x86)	x86(IA-32)MMXSSE/2/3SSSE3	MOVBE 또는 SSE4에 대한 지원 없음.
    [`x86_64`](https://developer.android.com/ndk/guides/abis.html?hl=ko#86-64)	x86-64MMXSSE/2/3SSSE3SSE4.1, 4.2POPCNT

    **참고: 예전에는 NDK가 32비트 및 64비트 MIPS를 지원했지만, NDK r17에서 지원이 제거되었다.

  • armeabi (참고: 이 ABI는 NDK r17에서 삭제되었다)

    • 이 ABI는 최소한 ARMv5TE 명령 집합을 지원하는 ARM 기반 CPU를 위한 것이다.

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

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

    • armeabi ABI는 ARM의 Thumb 명령 집합을 지원한다. LOCAL_ARM_MODE 파일에서 Android.mk 변수를 사용해 다른 동작을 지정하지 않는 한, NDK는 기본적으로 Thumb 코드를 생성한다.

  • armeabi-v7a

    • 이 ABI는 armeabi를 확장해 여러 CPU 명령 집합 확장을 포함한다. 이 Android 고유의 ABI가 지원하는 명령 확장은 다음과 같다.

      • Thumb-1과 유사한 간결성으로 32비트 ARM 명령에 필적하는 성능을 제공하는 Thumb-2 명령 집합 확장.

      • VFP 하드웨어 FPU 명령. 더 구체적으로는, ARM 코어에서 다른 16개의 32비트 레지스터 외에 16개의 전용 64비트 부동 소수점 레지스터를 포함하는 VFPv3-D16

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

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

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

  • arm64-v8a

    • 이 ABI는 AArch64를 지원하는 ARMv8 기반 CPU를 위한 것이다. 여기에는 NEON 및 VFPv4 명령 집합도 포함된다.

  • x86

    • 이 ABI는 보통 "x86" 또는 "IA-32"라고 하는 명령 집합을 지원하는 CPU를 위한 것이다. 이 ABI의 특징은 다음과 같다.

      1. 보통 다음과 같은 컴파일러 플래그가 있는 GCC에 의해 생성되는 명령: `-march=i686 -mtune=intel -mssse3 -mfpmath=sse -m32` 이러한 플래그는 MMX, SSE, SSE2, SSE3, SSSE3 명령 집합 확장과 함께 Pentium Pro 명령 집합을 대상으로 한다. 생성된 코드는 최고 Intel 32비트 CPU 전반에 균형을 맞춰 최적화된 코드이다.

      2. SVR에 대한 규칙과는 반대로, 표준 Linux x86 32비트 호출 규칙 사용.

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

      1. MOVBE

      2. SSE4의 변형

    • 이러한 확장 사용 설정을 위한 런타임 기능 검색을 사용하는 한 이를 계속 사용할 수 있고, 이러한 확장을 지원하지 않는 기기에 대해서는 폴백을 제공할 수 있다.

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

  • x86_64

    • 이 ABI는 보통 "x86-64"라고 하는 명령 집합을 지원하는 CPU를 위한 것으로, GCC가 일반적으로 다음 컴파일러 플래그로 생성하는 명령을 지원한다..

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

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

    • 이 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의 바이너리만 포함한 API보다 크다. 그 덕분에 호환성의 폭은 더 넓어지지만, APK가 커진다는 대가를 치러야 한다. 스플릿 APK의 이점을 살려 최대 기기 호환성을 유지하면서도 APK의 크기를 줄이는 것을 적극 권장한다.

• Android 플랫폼에서의 ABI 관리

  • 앱 패키지의 네이티브 코드

    • 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 디렉터리가 둘 다 있으면 후자 대신 전자의 네이티브 라이브러리를 설치한다. 이는 APK에서 /lib/armeabi/가 /lib/armeabi-v7a/ 뒤에 오기 때문이다. 4.0.4 버전부터는 이 문제가 수정되었다.

  • Android 플랫폼 ABI 지원

    • 빌드 고유의 시스템 속성이 다음을 표시하기 때문에, Android 시스템은 런타임에 어떤 ABI를 지원하는지 알게 된다.

      1. 시스템 이미지 자체에 사용되는 기계어 코드에 해당하는, 기기에 대한 기본 ABI.

      2. 시스템 이미지도 지원하는 다른 ABI에 해당하는, 선택적인 보조 ABI.

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

    • 애플리케이션을 설치할 때, 패키지 관리자 서비스는 APK를 검사해 다음 양식의 라이브러리가 있는지 찾아본다.

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

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

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

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

    • 공유 객체 파일이 하나도 없을 경우 애플리케이션이 빌드되고 설치되지만 런타임에 다운된다.