다중 APK 지원

앱을 Google Play에 게시하면 Android App Bundle을 빌드하고 업로드해야 합니다. 이렇게 하면 Google Play에서 각 사용자의 기기 설정에 최적화된 APK를 자동으로 생성하여 제공하므로 사용자는 앱을 실행하는 데 필요한 코드와 리소스만 다운로드하면 됩니다. Google Play에 게시하지 않는다면 다중 APK 게시가 유용하지만 각 APK를 직접 빌드, 서명 및 관리해야 합니다.

다중 APK 지원은 Google Play의 기능으로 다양한 기기 설정에 타겟팅된 각 애플리케이션에 여러 APK를 게시할 수 있습니다. 각 APK는 애플리케이션의 완전하고 독립적인 버전입니다. 그러나 Google Play에서 동일한 애플리케이션 목록을 공유하여 동일한 패키지 이름을 공유해야 하고 동일한 출시 키로 서명되어야 합니다. 이 기능은 애플리케이션이 단일 APK로 원하는 모든 기기에 도달할 수 없는 경우에 유용합니다.

Android 지원 기기는 여러 면에서 다를 수 있으며 최대한 많은 기기에서 애플리케이션을 사용할 수 있도록 하는 것이 애플리케이션의 성공에 중요한 요소입니다. Android 애플리케이션은 일반적으로 다양한 구성(예: 다양한 화면 크기의 여러 레이아웃)에 대체 리소스를 제공하고 Android 시스템은 런타임 시 기기의 적절한 리소스를 선택하여 대부분의 호환되는 기기에서 단일 APK로 실행됩니다. 그러나 단일 APK가 모든 기기 설정을 지원할 수 없는 경우도 있습니다. 대체 리소스로 APK 파일이 너무 커지거나 다른 기술적 문제로 단일 APK가 모든 기기에서 작동하지 않기 때문입니다.

최대한 많은 기기에 애플리케이션을 게시할 수 있도록 Google Play는 개발자가 동일한 애플리케이션 목록에 다중 APK를 게시하는 것을 허용합니다. 그러면 Google Play에서는 각 APK의 매니페스트 파일에 개발자가 선언한 설정 지원에 기반하여 각 APK를 적절한 기기에 제공합니다.

다중 APK로 애플리케이션을 게시하면 다음을 실행할 수 있습니다.

  • 각 APK로 다양한 OpenGL 텍스처 압축 형식 지원
  • 각 APK로 다양한 화면 크기 및 화면 밀도 지원
  • 각 APK로 다양한 기기 기능 세트 지원
  • 각 APK로 다양한 플랫폼 버전 지원
  • 앱에서 Android NDK를 사용하는 경우 ARM 또는 x86과 같이 각 APK로 다양한 CPU 아키텍처를 지원합니다.
  • Android(Go 버전)를 실행하는 기기와 같은 엔트리 레벨 기기에 최적화합니다.

현재 이러한 특성은 동일한 애플리케이션으로 다중 APK를 게시할 수 있도록 Google Play에서 지원하는 유일한 기기 특성입니다.

참고: Google Play에서 APK를 준비하고 게시하는 방법에 관한 자세한 내용은 준비 및 출시 지원 도움말을 참고하세요.

다중 APK 작동 방식

Google Play에서 다중 APK를 사용한다는 개념은 Google Play에는 애플리케이션 항목이 하나뿐이지만 다양한 기기에서 여러 APK를 다운로드할 수 있다는 것입니다. 이 내용의 의미는 다음과 같습니다.

  • 개발자는 앱 설명, 아이콘, 스크린샷 등 제품 세부정보 세트를 하나만 유지합니다. 이는 다양한 APK에 다른 가격을 청구할 수 없다는 의미이기도 합니다.
  • 모든 사용자는 Google Play에서 한 가지 버전의 애플리케이션만 볼 수 있으므로 '태블릿용'이나 '스마트폰용'으로 게시했을 수 있는 다른 버전으로 인해 혼동할 일이 없습니다.
  • 다른 기기의 사용자에게 다른 APK가 있을 수 있지만 모든 사용자 리뷰는 동일한 애플리케이션 목록에 적용됩니다.
  • 다양한 버전의 Android(다양한 API 수준)에 여러 APK를 게시한다면 사용자의 기기가 개발자가 게시한 다양한 APK에 적합하도록 시스템 업데이트를 수신할 때 Google Play는 사용자의 애플리케이션을 더 높은 버전의 Android에 맞게 디자인된 APK로 업데이트합니다. 애플리케이션과 연결된 시스템 데이터는 단일 APK를 사용할 때 일반 애플리케이션 업데이트와 동일하게 유지됩니다.

지원되는 필터

각 APK를 어떤 기기가 수신할지는 각 APK의 매니페스트 파일에 있는 요소에서 지정한 Google Play 필터에서 판단합니다. 그러나 Google Play에서는 각 APK가 필터를 사용하여 다음 기기 특성의 변형을 지원할 때만 다중 APK를 게시할 수 있습니다.

  • OpenGL 텍스처 압축 형식

    매니페스트 파일의 <supports-gl-texture> 요소에 기반합니다.

    예를 들어 OpenGL ES를 사용하는 게임을 개발할 때 ATI 텍스처 압축을 지원하는 기기에 APK를 하나 제공하고 PowerVR 압축(다른 많은 것들 중에서)을 지원하는 기기에 별도의 APK를 제공할 수 있습니다.

  • 화면 크기 (및 선택적 화면 밀도)

    매니페스트 파일의 <supports-screens> 또는 <compatible-screens> 요소에 기반합니다. 두 요소를 모두 사용해서는 안 되며 가능한 경우 <supports-screens>만 사용해야 합니다.

    예를 들어, 소형 및 일반 크기의 화면을 지원하는 APK 하나, 대형 및 특대형 화면을 지원하는 다른 APK 하나를 제공할 수 있습니다. 화면 크기나 화면 밀도에 기반하여 별도의 APK를 생성하는 방법에 관한 자세한 내용은 다중 APK 빌드를 참조하세요.

    모든 화면 크기를 지원하려면 다음 권장사항을 고려합니다.

    • Android 시스템은 단일 APK로 모든 화면 구성을 지원하기 위해 애플리케이션에 강력한 지원을 제공합니다. 꼭 필요한 경우가 아니라면 다양한 화면을 지원하려고 다중 APK를 만들지 않아야 합니다. 대신 다중 화면 지원 가이드를 따라 애플리케이션이 단일 APK로 모든 화면 구성에 맞게 유연하게 조절될 수 있도록 해야 합니다.
    • 기본적으로 <supports-screens> 요소에서 모든 화면 크기 속성은 다르게 선언하지 않는다면 'true'입니다. 그러나 android:xlargeScreens 속성이 Android 2.3(API 수준 9)에 추가되었으므로 Google Play에서는 애플리케이션이 android:minSdkVersion 또는 android:targetSdkVersion을 '9' 이상으로 설정하지 않는다면 'false'라고 가정합니다.
    • 매니페스트 파일에서 <supports-screens> 및 <compatible-screens> 요소를 모두 결합해서는 안 됩니다. 둘을 모두 사용하면 둘 사이의 충돌로 인해 오류가 발생할 가능성이 높아집니다. 어떤 것을 사용할지 판단하는 방법에 관한 자세한 내용은 특정 화면에 배포를 참조하세요. 어쩔 수 없이 둘 다 사용해야 한다면 주어진 크기 사이에 동의된 모든 충돌에서 'false'가 이긴다는 사실에 유의하세요.
  • 기기 기능 세트

    매니페스트 파일의 <uses-feature> 요소에 기반합니다.

    예를 들어 멀티터치를 지원하는 기기에 APK 하나, 멀티터치를 지원하지 않는 기기에 다른 APK 하나를 제공할 수 있습니다. 플랫폼에서 지원하는 기능 목록은 기능 참조를 읽어보세요.

  • Android (Go 버전)

    Android (Go 버전)를 실행하는 기기를 타겟팅하려면 APK가 <uses-feature android:name="android.hardware.ram.low" android:required="true">을 선언하고 API 수준 26 이상을 타겟팅해야 하며 Go 버전이 아닌 APK보다 높은 버전 코드를 보유해야 합니다.

  • API 수준

    매니페스트 파일의 <uses-sdk> 요소에 기반합니다. android:minSdkVersion 및 android:maxSdkVersion 속성을 모두 사용하여 다양한 API 수준의 지원을 지정합니다.

    예를 들어 API 수준 16 이하부터 사용 가능한 API만 사용하여 API 수준 16~19(Android 4.1.x~4.4.4)를 지원하는 하나의 APK와 API 수준 21 이하부터 사용 가능한 API를 사용하여 API 수준 21 이상(Android 5.0+)을 지원하는 또 다른 APK로 애플리케이션을 게시할 수 있습니다. 다양한 범위의 API를 각각 타겟팅하는 별도의 APK를 빌드하는 방법에 관한 자세한 내용은 제품 버전 구성을 참고하세요.

    이 특성을 다중 APK를 구별하는 요소로 사용하면 android:minSdkVersion 값이 더 높은 APK가 android:versionCode 값도 더 높아야 합니다. 두 APK의 기기 지원이 다양한 지원 필터에 기반하여 중복되는 경우에도 마찬가지입니다. 이렇게 하면 기기가 시스템 업데이트를 수신할 때 Google Play에서 사용자에게 애플리케이션의 업데이트를 제공할 수 있습니다. 업데이트는 앱 버전 코드의 증가에 기반하기 때문입니다. 이 요구사항은 다중 APK 규칙에 관한 아래 섹션에서 자세히 설명됩니다.

    일반적으로 android:maxSdkVersion을 사용해서는 안 됩니다. 공개 API로 애플리케이션을 올바르게 개발했다면 항상 향후 버전의 Android와 호환되기 때문입니다. 더 높은 API 수준을 위해 다른 APK를 게시하려는 경우 여전히 최대 버전을 지정할 필요가 없습니다. android:minSdkVersion이 하나의 APK에서 "16"이고 다른 APK에서 "21"이라면 API 수준 21 이상을 지원하는 기기에서는 항상 두 번째 APK를 수신하기 때문입니다. 그 이유는 앞서 설명한 대로 버전 코드가 더 높아서입니다.


  • CPU 아키텍처 (ABI)

    일부 네이티브 라이브러리는 특정 CPU 아키텍처를 위한 별도의 패키지인 Application Binary Interface(ABI)를 제공합니다. 사용 가능한 모든 라이브러리를 하나의 APK로 패키징하는 대신 각 ABI에 별도의 APK를 빌드하고 ABI에 필요한 라이브러리만 포함할 수 있습니다. 타겟 ABI에 기반하여 별도의 APK를 생성하는 방법에 관한 자세한 내용은 다중 APK 빌드를 참조하세요.

Google Play 필터를 사용 설정하지만 위 목록에 나열되지 않은 다른 매니페스트 요소가 여전히 각 APK에 평소처럼 적용됩니다. 그러나 Google Play에서는 이러한 기기 특성의 변형에 기반하여 별도의 APK를 게시할 수 없습니다. 따라서 위에 나열된 필터가 각 APK에 동일하고 APK가 매니페스트 또는 APK의 다른 특성에 기반하여 다양한 경우 다중 APK를 게시할 수 없습니다. 예를 들어 <uses-configuration> 특성이 완전히 다른 다양한 APK를 제공할 수 없습니다.

다중 APK 규칙

애플리케이션에 다중 APK를 게시하기 전에 다음 규칙을 알아야 합니다.

  • 동일한 애플리케이션에 게시하는 모든 APK는 패키지 이름이 동일해야 하고 동일한 인증서 키로 서명되어야 합니다.
  • 각 APK에는 android:versionCode 속성에서 지정된 다양한 버전 코드가 있어야 합니다.
  • 각 APK는 다른 APK의 구성 지원과 정확히 일치해서는 안 됩니다.

    즉, 각 APK는 위에 나열된 지원되는 Google Play 필터 중 하나 이상에 약간 다른 지원을 선언해야 합니다.

    일반적으로 지원되는 텍스처 압축 형식과 같은 특정 특성에 기반하여 APK를 구별하므로 각 APK는 여러 기기에 지원을 선언합니다. 그러나 지원이 약간 중복되는 다중 APK를 게시해도 괜찮습니다. 두 개의 APK가 중복되면(일부 동일한 기기 설정 지원) 중복되는 범위 내에 있는 기기는 android:versionCode에서 정의된 더 높은 버전 코드의 APK를 수신합니다.

  • 교체하는 APK보다 버전 코드가 낮은 새로운 APK를 활성화할 수 없습니다. 예를 들어 버전 코드가 0400인 소형~일반 화면 크기의 활성 APK가 있다면 버전 코드가 0300인 동일한 화면 크기의 APK로 교체해보세요. 이전 APK 사용자가 애플리케이션을 업데이트할 수 없으므로 오류가 발생합니다.
  • API 수준이 더 높은 APK는 버전 코드도 더 높아야 합니다.

    이 규칙은 APK가 지원되는 API 수준에만 기반하여 달라지는 경우(다른 어떤 지원되는 필터도 APK를 서로 구별하지 않음) 또는 APK가 다른 지원되는 필터를 사용하지만 필터 내 APK 사이에 중복이 있는 경우에만 적용됩니다.

    이 규칙은 Google Play에서 APK의 버전 코드가 현재 기기의 APK 버전 코드보다 높은 경우에만 사용자의 기기가 Google Play에서 애플리케이션 업데이트를 수신하므로 중요합니다. 이 규칙으로 기기가 시스템 업데이트를 수신하고 API 수준이 더 높은 APK를 설치하는 데 적합하게 되면 기기는 버전 코드가 증가하기 때문에 애플리케이션 업데이트를 수신하게 됩니다.

    참고: 버전 코드의 증가 크기는 중요하지 않습니다. 더 높은 API 수준을 지원하는 버전에서 더 크기만 하면 됩니다.

    다음은 몇 가지 예입니다.

    • API 수준 16 이상(Android 4.1.x+)에 업로드한 APK의 버전 코드가 0400인 경우 API 수준 21 이상(Android 5.0+)의 APK는 0401 이상이어야 합니다. 이 경우 API 수준은 사용된 유일하게 지원되는 필터이므로 버전 코드는 각 APK의 API 수준 지원과 관련하여 증가해야 합니다. 이를 통해 사용자는 시스템 업데이트를 수신할 때 업데이트를 받을 수 있습니다.
    • API 수준 16 이상 및 소형~대형 화면에 하나의 APK가 있고 API 수준 21 이상 및 대형~특대형 화면에 또 하나의 APK가 있다면 버전 코드는 API 수준과 관련하여 증가해야 합니다. 이 경우 API 수준 필터는 각 APK를 구별하는 데 사용되고 화면 크기도 마찬가지입니다. 화면 크기가 중복되므로(두 APK가 모두 대형 화면 지원) 버전 코드는 순서대로 유지되어야 합니다. 그러면 API 수준 21 시스템 업데이트를 수신하는 대형 화면 기기에서 두 번째 APK의 업데이트를 수신하게 됩니다.
    • API 수준 16 이상 및 소형~일반 화면에 하나의 APK가 있고 API 수준 21 이상 및 대형~특대형 화면에 또 하나의 APK가 있다면 버전 코드는 API 수준과 관련하여 증가할 필요가 없습니다. 화면 크기 필터에는 중복이 없으므로 이러한 두 APK 사이에서 이동할 수 있는 기기가 없습니다. 따라서 버전 코드가 낮은 API 수준에서 높은 API 수준로 증가할 필요가 없습니다.
    • API 수준 16 이상 및 ARMv7 CPU에 하나의 APK가 있고 API 수준 21 이상 및 ARMv5TE CPU에 또 하나의 APK가 있다면 버전 코드는 API 수준과 관련하여 증가해야 합니다. 이 경우 API 수준 필터는 각 APK를 구별하는 데 사용되고 CPU 아키텍처도 마찬가지입니다. ARMv5TE 라이브러리가 있는 APK는 ARMv7 CPU가 있는 기기와 호환되므로 APK는 이 특성에서 중복됩니다. 따라서 API 수준 21 이상을 지원하는 APK의 버전 코드가 더 높아야 합니다. 그러면 API 수준 21 시스템 업데이트를 수신하는 ARMv7 CPU가 있는 기기에서 API 수준 21용으로 디자인된 두 번째 APK의 업데이트를 수신하게 됩니다. 그러나 이러한 업데이트로 인해 ARMv7 기기에서 기기의 CPU에 완전히 최적화되지 않은 APK를 사용하게 되므로 각 CPU의 앱 성능을 최적화하려면 각 API 수준에서 ARMv5TE 및 ARMv7 아키텍처에 모두 APK를 제공해야 합니다. 참고: 이 규칙은 APK를 ARMv5TE 및 ARMv7 라이브러리와 비교할 때만 적용되며 다른 네이티브 라이브러리와 비교할 때는 적용되지 않습니다.

위 규칙을 준수하지 않으면 APK를 활성화할 때 Google Play Console에서 오류가 발생하며 오류를 해결할 때까지 애플리케이션을 게시할 수 없습니다.

APK를 활성화할 때 발생할 수 있는 다른 충돌이 있지만 오류가 아닌 경고가 발생합니다. 경고는 다음과 같은 이유로 발생할 수 있습니다.

  • APK를 수정하여 기기 특성에 관한 지원을 '축소'하고 지원되는 범위 밖의 기기를 지원하는 다른 APK가 없는 경우. 예를 들어 APK가 현재 소형 및 일반 크기 화면을 지원하고 개발자가 소형 화면만 지원하도록 변경하면 지원되는 기기 풀이 축소되고 일부 기기에서는 더 이상 Google Play에서 애플리케이션이 표시되지 않습니다. 이 문제는 일반 크기 화면을 지원하는 다른 APK를 추가하여 이전에 지원된 모든 기기를 계속 지원하여 해결할 수 있습니다.
  • 두 개 이상의 APK 사이에 '중복'이 있는 경우. 예를 들어 소형, 일반, 대형 화면 크기를 지원하는 APK가 있고 대형 및 특대형 화면 크기를 지원하는 다른 APK가 있다면 두 APK가 모두 대형 화면을 지원하므로 중복이 생깁니다. 이 문제를 해결하지 않으면 두 APK에 모두 적합한 기기(예: 대형 화면 기기)는 버전 코드가 가장 높은 APK를 수신합니다.

    참고: 다양한 CPU 아키텍처에 별도의 APK를 만드는 경우 ARMv5TE의 APK가 ARMv7의 APK와 중복되는 것에 유의하세요. 즉, ARMv5TE용으로 디자인된 APK는 ARMv7 기기와 호환되지만, 그 반대는 아닙니다. ARMv7 라이브러리만 있는 APK는 ARMv5TE 기기와 호환되지 않습니다.

이러한 충돌이 발생하면 경고 메시지가 표시되지만, 여전히 애플리케이션을 게시할 수 있습니다.

다중 APK 만들기

다중 APK를 게시하려고 하는 경우 따로 적절하게 개발할 수 있도록 게시하려는 각 APK에 별도의 Android 프로젝트를 만들어야 할 수 있습니다. 기존 프로젝트를 복사하고 새로운 이름을 부여하기만 하면 됩니다. 또는 빌드 구성에 기반하여 다양한 리소스(예: 텍스처)를 출력할 수 있는 빌드 시스템을 사용해도 됩니다.

도움말: 애플리케이션 코드의 상당 부분이 중복되는 것을 방지하는 한 가지 방법은 라이브러리 프로젝트를 사용하는 것입니다. 라이브러리 프로젝트에는 공유 코드 및 리소스가 있으므로 실제 애플리케이션 프로젝트에 포함할 수 있습니다.

동일한 애플리케이션에 여러 프로젝트를 만드는 경우 APK에 적용할 기기 제한을 표시하는 이름으로 각 프로젝트를 식별하는 것이 좋습니다. 그러면 쉽게 식별할 수 있습니다. 예를 들어 'HelloWorld_21'은 API 수준 21 이상을 위해 디자인된 애플리케이션에 좋은 이름일 수 있습니다.

참고: 동일한 애플리케이션에 게시하는 모든 APK는 패키지 이름이 동일해야 하고 동일한 인증서 키로 서명되어야 합니다. 또한 다중 APK 규칙을 각각 알고 있어야 합니다.

버전 코드 할당

동일한 애플리케이션의 각 APK에는 android:versionCode 속성에서 지정한 고유한 버전 코드가 있어야 합니다. 다중 APK를 게시할 때 버전 코드는 주의해서 할당해야 합니다. 각기 달라야 하지만 어떤 경우에는 각 APK가 지원하는 구성에 기반하여 특정 순서로 정의되어야 하기 때문입니다.

버전 코드 순서 지정

일반적으로 API 수준이 더 높아야 하는 APK는 버전 코드도 더 높아야 합니다 예를 들어 APK 두 개를 만들어 다른 API 수준을 지원한다면 높은 API 수준의 APK에 더 높은 버전 코드가 있어야 합니다. 그러면 기기가 시스템 업데이트를 수신하여 더 높은 API 수준의 APK를 설치하는 데 적합해지면 사용자는 앱을 업데이트하라는 알림을 수신하게 됩니다. 이 요구사항이 적용되는 방법에 관한 자세한 내용은 다중 APK 규칙에 관한 위 섹션을 참조하세요.

적용 범위가 다양한 APK 사이의 중복이나 향후 있을 수 있는 APK의 변경사항으로 인해 사용자가 수신하는 APK에 버전 코드 순서가 어떤 영향을 미칠 수 있는지도 고려해야 합니다.

화면 크기에 기반한 다양한 APK(예: 소형~일반용 하나, 대형~특대형용 하나)가 있지만 소형용 하나와 일반~특대형용 하나로 APK를 변경하는 때를 예상한다면 대형~특대형 APK의 버전 코드를 더 높게 만들어야 합니다. 이렇게 해야 변경할 때 일반 크기의 기기에서 적절한 업데이트를 수신합니다. 버전 코드가 기존 APK에서 이제 기기를 지원하는 새로운 APK로 증가하기 때문입니다.

또한 다양한 OpenGL 텍스처 압축 형식의 지원에 기반하여 달라지는 다중 APK를 만들 때는 여러 기기가 다중 형식을 지원한다는 점에 유의하세요. APK 두 개 사이에 중복되는 적용 범위가 있으면 버전 코드가 가장 높은 APK를 기기에서 수신하므로 APK 간 버전 코드의 순서를 지정하여 선호하는 압축 형식의 APK가 가장 높은 버전 코드를 갖도록 해야 합니다. 예를 들어 PVRTC, ATITC, ETC1 압축 형식을 사용하여 앱에 별도의 빌드를 실행하는 것이 좋을 수 있습니다. 이러한 형식을 정확하게 이 순서로 선호한다면 PVRTC를 사용하는 APK의 버전 코드가 가장 높고 ATITC를 사용하는 APK가 그 다음으로 높고 ETC1이 있는 버전이 가장 낮습니다. 따라서 기기가 PVRTC와 ETC1을 모두 지원하면 PVRTC가 있는 APK를 수신합니다. 버전 코드가 가장 높기 때문입니다.

Google Play 스토어에서 타겟 기기에 설치할 올바른 APK를 식별할 수 없는 경우 지원하려는 다양한 모든 기기 변형의 리소스가 포함된 범용 APK를 만드는 것이 좋을 수도 있습니다. 범용 APK를 제공하는 경우 가장 낮은 versionCode를 할당해야 합니다. Google Play 스토어에서는 타겟 기기와 호환되며 가장 높은 versionCode가 있는 앱 버전을 설치하므로 낮은 versionCode를 범용 APK에 할당하면 Google Play 스토어에서 더 큰 범용 APK로 돌아가기 전에 다른 APK 중 하나를 설치하려고 시도하게 됩니다.

버전 코드 체계 사용

다양한 APK가 다른 APK와는 별도로 버전 코드를 업데이트할 수 있으려면(예: 하나의 APK에서만 버그를 수정하여 모든 APK를 업데이트할 필요가 없는 경우) 다른 APK 코드를 늘릴 필요 없이 하나의 APK 코드를 늘릴 수 있도록 각 APK 사이에 여유 공간을 충분히 제공하는 버전 코드 체계를 사용해야 합니다. 버전 코드와 버전 이름을 쉽게 연결할 수 있도록 코드에 실제 버전 이름(즉, android:versionName에 할당된 사용자 표시 버전)도 포함해야 합니다.

참고: APK의 버전 코드를 늘리면 Google Play에서 이전 버전의 사용자에게 애플리케이션을 업데이트하라는 메시지를 표시합니다. 따라서 불필요한 업데이트를 방지하려면 실제로 변경사항이 포함되지 않은 APK의 버전 코드를 늘리면 안 됩니다.

최소 7자리의 버전 코드를 사용하는 것이 좋습니다. 지원되는 구성을 표시하는 정수가 상위 비트이며 android:versionName의 버전 이름이 하위 비트입니다. 예를 들어 애플리케이션 버전 이름이 3.1.0인 경우 API 수준 4 APK 및 API 수준 11 APK의 버전 코드는 각각 0400310 및 1100310일 수 있습니다. 처음 두 자리는 API 수준(각각 4 및 11)을 위한 자리이고 가운데 두 자리는 화면 크기 또는 GL 텍스처 형식(이 예에서는 사용되지 않음)이며 마지막 세 자리는 애플리케이션의 버전 이름(3.1.0)입니다. 그림 1은 플랫폼 버전(API 수준)과 화면 크기에 기반하여 분할한 두 가지 예를 보여줍니다.

그림 1. API 수준에 첫 두 자리, 최소 및 최대 화면 크기(네 가지 크기를 각각 표시하는 1~4) 또는 텍스처 형식을 표시하는 세 번째, 네 번째 자리, 앱 버전에 마지막 세 자리를 사용하는 추천된 버전 코드 체계

이 버전 코드 체계는 애플리케이션이 발전함에 따라 확장 가능한 패턴을 설정해야 하는 방법에 관한 추천일 뿐입니다. 특히 이 체계는 다양한 텍스처 압축 형식을 식별하는 솔루션을 보여주지 않습니다. 한 가지 옵션은 애플리케이션에서 지원하는 여러 압축 형식에 각기 다른 정수를 지정하는 자체 표를 정의하는 것일 수 있습니다. 예를 들어 1은 ETC1과 일치할 수 있고 2는 ATITC와 일치하는 등입니다.

원하는 어떤 체계든 사용할 수 있지만 향후 버전의 애플리케이션에서 버전 코드를 어떻게 늘려야 할지, 기기 설정이 변경되거나(예: 시스템 업데이트로 인해) 하나 또는 여러 개의 APK 구성 지원을 수정할 때 기기에서 어떻게 업데이트를 수신할 수 있는지 신중하게 고려해야 합니다.

이전
다양한 픽셀 밀도 지원
다음
다양한 API 수준을 위한 다중 APK 만들기