본문 바로가기

Programming/Android

Multiple APK support

link : https://developer.android.com/google/play/publishing/multiple-apks

 

Multiple APK support  |  Android Developers

Multiple APK support is a feature on Google Play that allows you to publish different APKs for your application that are each targeted to different device configurations. Each APK is a complete and independent version of your application, but they share…

developer.android.com

 

*Multiple APK support
여러 APK 지원은 Google Play의 기능으로 각기 다른 기기 구성을 타겟팅하는 애플리케이션에 대해 서로 다른 APK를 게시 할 수 있습니다. 각 APK는 애플리케이션의 완전하고 독립적 인 버전이지만 Google Play에서 동일한 애플리케이션 목록을 공유하며 동일한 패키지 이름을 공유하고 동일한 출시 키로 서명해야합니다. 이 기능은 애플리케이션이 단일 APK로 모든 원하는 기기에 도달 할 수없는 경우에 유용합니다.

Android 탑재 기기는 여러면에서 다를 수 있으며 가능한 한 많은 기기에서 사용할 수 있도록 애플리케이션의 성공에 중요합니다. 안드로이드 응용 프로그램은 대개 서로 다른 구성 (예 : 다른 화면 크기의 다른 레이아웃)에 대한 대체 리소스를 제공하여 단일 APK로 대부분의 호환 장치에서 실행되며, Android 시스템은 런타임에 장치에 적합한 리소스를 선택합니다. 그러나 대체 리소스가 APK 파일을 너무 크게 만들거나 단일 APK가 모든 장치에서 작동하지 못하도록하는 기술적 인 문제로 인해 단일 APK가 모든 장치 구성을 지원할 수없는 경우가 있습니다.

최대한 많은 기기에서 애플리케이션을 게시 할 수 있도록 Google Play에서는 동일한 애플리케이션 목록에 여러 개의 APK를 게시 할 수 있습니다. 그런 다음 Google Play는 각 APK의 매니페스트 파일에 선언 된 구성 지원에 따라 각 APK를 적절한 기기에 제공합니다.

여러 APK로 애플리케이션을 게시하면 다음 작업을 수행 할 수 있습니다:
1) 각 APK로 다양한 OpenGL 텍스처 압축 형식을 지원하십시오.
2) 각 APK로 다양한 화면 크기와 밀도를 지원하십시오.
3) 각 APK로 다양한 장치 기능 세트를 지원하십시오.
4) 각 APK로 다양한 플랫폼 버전을 지원하십시오.
5) 각 APK로 다양한 CPU 아키텍처를 지원합니다 (예 : Android NDK를 사용하는 ARM 또는 x86).
6) Android (Go 버전)를 실행하는 기기와 같은 엔트리 레벨 기기에 맞게 최적화합니다.
현재 Google Play가 여러 APK를 동일한 애플리케이션으로 게시 할 때 지원하는 유일한 기기 특성입니다.

참고 : Google Play에서 APK를 준비하고 게시하는 방법에 대해 알아 보려면 준비 및 출시 출시 지원 문서를 참조하세요.


*How multiple APKs work
Google Play에서 여러 APK를 사용하는 개념은 애플리케이션에 대해 Google Play에 단 하나의 항목 만 있지만 다른 기기에서 다른 APK를 다운로드 할 수 있다는 것입니다. 이는 다음을 의미합니다.

제품 세부 정보 (앱 설명, 아이콘, 스크린 샷 등)를 한 세트 만 유지합니다. 이는 또한 다른 APK에 대해 다른 가격을 청구 할 수 없다는 것을 의미합니다.
모든 사용자는 Google Play에서 한 버전의 애플리케이션 만 볼 수 있으므로 '태블릿 용'또는 '휴대 전화 용'인 다른 버전으로 혼동하지 않습니다.
다른 기기의 사용자가 다른 APK를 가지고있을지라도 모든 사용자 리뷰는 동일한 애플리케이션 목록에 적용됩니다.
다양한 API 버전에 대해 다양한 Android 버전에 대해 서로 다른 APK를 게시하면 사용자의 기기가 게시 한 다른 APK에 적합한 시스템 업데이트를 받으면 Google Play에서 사용자의 애플리케이션을 해당 APK로 업데이트합니다. Android의 상위 버전. 응용 프로그램과 관련된 모든 시스템 데이터가 유지됩니다 (단일 APK를 사용하는 경우 일반 응용 프로그램 업데이트와 동일 함).


*Supported filters
각 APK를 수신하는 기기는 각 APK의 매니페스트 파일 요소에 지정된 Google Play 필터에 의해 결정됩니다. 그러나 Google Play에서는 각 APK가 필터를 사용하여 다음 기기 특성의 변형을 지원할 때만 여러 APK를 게시 할 수 있습니다.

1) OpenGL texture compression formats
이것은 매니페스트 파일의  요소를 기반으로합니다.

예를 들어, OpenGL ES를 사용하는 게임을 개발할 때 ATI 텍스처 압축을 지원하는 장치에는 하나의 APK를 제공하고 PowerVR 압축을 지원하는 장치에는 다른 APK를 제공 할 수 있습니다.

2) Screen size (and, optionally, screen density)
이것은 매니 페스트 파일의  또는  요소를 기반으로합니다. 가능하면 두 요소를 모두 사용하지 말아야하며  만 사용해야합니다.

예를 들어 소형 및 일반 크기의 화면을 지원하는 APK 하나와 크고 큰 화면을 지원하는 다른 APK를 제공 할 수 있습니다. 화면 크기 나 밀도에 따라 별도의 APK를 생성하는 방법에 대해 자세히 알아 보려면 여러 APK 빌드로 이동하십시오.

모든 화면 크기를 지원하는 다음과 같은 최상의 방법을 고려하십시오:
- Android 시스템은 단일 APK로 모든 화면 구성을 지원하는 응용 프로그램에 대한 강력한 지원을 제공합니다. 절대적으로 필요한 경우가 아니면 다른 화면을 지원하기 위해 여러 개의 APK를 만들지 말고 대신 여러 개의 화면 지원 가이드를 따라 응용 프로그램이 유연하고 단일 APK로 모든 화면 구성에 적응할 수 있도록해야합니다.
- 기본적으로  요소의 모든 화면 크기 속성은 사용자가 달리 선언하지 않으면 "true"입니다. 그러나 android : xlargeScreens 속성이 Android 2.3 (API 레벨 9)에 추가 되었기 때문에 애플리케이션에서 android : minSdkVersion 또는 android : targetSdkVersion을 '9'이상으로 설정하지 않으면 Google Play에서 'false'로 간주합니다.
- 매니페스트 파일에  및  요소를 결합하면 안됩니다. 둘을 함께 사용하면 충돌로 인해 오류가 발생할 가능성이 높아집니다. 어떤 것을 사용할 지 결정하는 데 도움이 필요하면 특정 화면에 배포를 읽으십시오. 둘 다 사용하는 것을 피할 수 없다면 주어진 크기 사이의 모든 충돌에 대해 "false"가 이깁니다.

3) Device feature sets
이는 매니페스트 파일의  요소를 기반으로합니다.

예를 들어 멀티 터치를 지원하는 기기에 대해 하나의 APK를 제공하고 멀티 터치를 지원하지 않는 기기에 대해 다른 APK를 제공 할 수 있습니다. 플랫폼에서 지원하는 기능 목록은 기능 참조를 참조하십시오.

4) Android (Go edition)
Android (Go 버전)를 실행하는 기기를 타겟팅하려면 APK가 android.hardware.ram.low"android : required = "true">를 선언해야합니다.
API 레벨 26 이상을 타겟팅하고 Go 버전이 아닌 APK보다 높은 버전의 코드를 사용하십시오.

5) API Level
이는 매니페스트 파일의  요소를 기반으로합니다. android : minSdkVersion 및 android : maxSdkVersion 속성을 사용하여 다양한 API 수준에 대한 지원을 지정할 수 있습니다.

예를 들어 API 레벨 16 - 19 (Android 4.1.x - 4.4.4)를 지원하는 하나의 APK (API 레벨 16 이하에서 사용 가능한 API 만 사용)와 API 레벨 21 이상을 지원하는 다른 APK를 사용하여 애플리케이션을 게시 할 수 있습니다 (Android 5.0 이상) - API 레벨 21 이하부터 사용 가능한 API를 사용합니다. 다양한 범위의 API를 대상으로하는 별도의 APK를 작성하는 방법을 배우려면 Configure Product Flavors를 방문하십시오.

이 특성을 여러 APK를 구분하는 요소로 사용하면 더 높은 android : minSdkVersion 값을 가진 APK의 android : versionCode 값이 높아야합니다. 두 개의 APK가 지원되는 다른 필터를 기반으로 장치 지원을 겹치는 경우에도 마찬가지입니다. 이렇게하면 기기가 시스템 업데이트를 받으면 Google Play에서 사용자에게 앱 버전 업데이트를 제공 할 수 있습니다 (업데이트는 앱 버전 코드가 증가했기 때문에). 이 요구 사항은 여러 APK 규칙에 대한 아래 섹션에서 자세히 설명합니다.

공개 API를 사용하여 애플리케이션을 적절히 개발하면 Android의 향후 버전과 항상 호환되므로 일반적으로 android : maxSdkVersion을 사용하지 않아야합니다. 더 높은 API 레벨을 위해 다른 APK를 게시하려는 경우 최대 버전을 지정할 필요가 없습니다. 하나의 APK에서 android : minSdkVersion이 '16'이고 다른 API에서 '21'인 경우 API 레벨 21을 지원하는 기기 이상은 항상 이전 노트와 같이 버전 코드가 높기 때문에 두 번째 APK를 받게됩니다.

5) CPU architecture (ABI)
일부 기본 라이브러리는 특정 CPU 아키텍처 또는 ABI (응용 프로그램 이진 인터페이스)에 대해 별도의 패키지를 제공합니다. 사용 가능한 모든 라이브러리를 하나의 APK로 패키징하는 대신 각 ABI에 대해 별도의 APK를 만들고 해당 ABI에 필요한 라이브러리 만 포함 할 수 있습니다.

위에 나열되지 않은 Google Play 필터를 사용하도록 설정하는 기타 매니페스트 요소는 각 APK에 평소와 같이 적용됩니다. 하지만 Google Play에서는 이러한 기기 특성의 변형을 기반으로 별도의 APK를 게시하는 것을 허용하지 않습니다. 따라서 위에 나열된 필터가 각 APK에 대해 동일하지만 APK가 매니페스트 또는 APK의 다른 특성에 따라 다른 경우 여러 APK를 게시 할 수 없습니다. 예를 들어 순수하게  특성이 다른 여러 APK를 제공 할 수는 없습니다.


*Rules for multiple APKs
애플리케이션에 여러 개의 APK를 게시하기 전에 다음 규칙을 이해해야합니다.

1) 동일한 애플리케이션에 대해 게시하는 모든 APK는 동일한 패키지 이름을 가져야하며 동일한 인증서 키로 서명해야합니다.
2) 각 APK에는 android : versionCode 속성으로 지정된 다른 버전 코드가 있어야합니다.
3) 각 APK는 다른 APK의 구성 지원과 정확히 일치하지 않아야합니다. 즉, 각 APK는 위에 나열된 지원되는 Google Play 필터 중 적어도 하나에 대해 약간 다른 지원을 선언해야합니다.
일반적으로 지원되는 텍스처 압축 형식과 같은 특정 특성을 기반으로 APK를 차별화하므로 각 APK는 서로 다른 장치에 대한 지원을 선언합니다. 그러나 지원을 약간 중복하는 여러 개의 APK를 게시하는 것이 좋습니다. 두 개의 APK가 겹치면 (동일한 기기 구성 중 일부를 지원하는 경우) 중복되는 범위 내에있는 기기는 더 높은 버전의 코드 (android : versionCode로 정의)와 함께 APK를 수신합니다.
4) 교체되는 APK보다 낮은 버전 코드를 가진 새 APK를 활성화 할 수 없습니다. 예를 들어 버전 코드 0400의 화면 크기가 작은 APK가 활성 상태 인 경우 버전 0300으로 동일한 화면 크기의 APK로 바꾸어보십시오. 이전 버전의 사용자를 의미하므로 오류가 발생합니다. APK는 애플리케이션을 업데이트 할 수 없습니다.
5) 높은 API 수준이 필요한 APK의 버전 코드가 높아야합니다.
이는 APK가 지원되는 API 수준 (APK를 서로 구별하지 않는 다른 지원되는 필터 없음) 또는 APK가 다른 지원되는 필터를 사용하지만 APK가 해당 필터 내에서 중복되는 경우에만 해당됩니다.
이는 사용자의 기기가 Google Play의 APK 버전 코드가 현재 기기에있는 APK의 버전 코드보다 높은 경우에만 Google Play에서 애플리케이션 업데이트를 받기 때문에 중요합니다. 이렇게하면 장치가 더 높은 API 수준을 위해 APK를 설치하도록 시스템 업데이트를받는 경우 버전 코드가 증가하기 때문에 장치가 응용 프로그램 업데이트를 수신합니다.
@참고 : 단순히 버전 코드를 증가시키는 것은 부적합합니다. 더 높은 API 레벨을 지원하는 버전에서 커질 필요가 있습니다.

여기 예시들이 있습니다 :

1) API 레벨 16 이상 (Android 4.1.x +)으로 업로드 한 APK의 버전 코드가 0400 인 경우 API 레벨 21 이상 (Android 5.0 이상)의 APK는 0401 이상이어야합니다. 이 경우 API 수준 만 사용되는 지원 필터이므로 각 APK에 대한 API 수준 지원과의 상관 관계에서 버전 코드가 증가해야 사용자가 시스템 업데이트를받을 때 업데이트를 얻을 수 있습니다.
2) API 레벨 16 (이상) 및 소형 대형 화면 용 APK가 하나 있고 API 레벨 21 (이상) 및 대형 대형 화면 용 APK가 하나있는 경우 버전 코드는 API 레벨과 관련하여 증가해야합니다. 이 경우 API 수준 필터는 각 APK를 구분하는 데 사용되지만 화면 크기도 다릅니다. 화면 크기가 겹치기 때문에 (두 APK 모두 큰 화면을 지원함) 버전 코드는 계속 유지되어야합니다. 이렇게하면 API 레벨 21로 시스템 업데이트를받는 큰 화면 장치가 두 번째 APK에 대한 업데이트를 수신하게됩니다.
3) API 레벨 16 (이상) 및 소형 일반 화면 용 APK 1 개와 API 레벨 21 (이상) 및 대형 대형 화면 용 APK 1 개가있는 경우 버전 코드는 다음과 관련하여 증가 할 필요가 없습니다. API 수준. 화면 크기 필터에는 겹침이 없으므로 두 APK 사이를 이동할 수있는 장치가 없기 때문에 더 낮은 API 레벨에서 높은 API 레벨로 버전 코드를 늘릴 필요가 없습니다.
4) API 레벨 16 (이상) 및 ARMv7 CPU 용 APK 1 개와 API 레벨 21 (이상) 및 ARMv5TE CPU 용 APK 1 개가있는 경우 버전 코드는 API 레벨과 관련하여 증가해야합니다. 이 경우 API 수준 필터는 각 APK를 구분하는 데 사용되지만 CPU 아키텍처도 구분됩니다. ARMv5TE 라이브러리가있는 APK는 ARMv7 CPU가있는 장치와 호환되므로 APK는이 특성에 중첩됩니다. 따라서 API 레벨 21 이상을 지원하는 APK의 버전 코드가 높아야합니다. 이렇게하면 API 레벨 21에 대한 시스템 업데이트를받는 ARMv7 CPU가있는 장치는 API 레벨 21 용으로 설계된 두 번째 APK에 대한 업데이트를 받게됩니다. 그러나 이러한 종류의 업데이트로 인해 APK를 사용하는 ARMv7 장치가 생성되기 때문에 해당 장치의 CPU에 완벽하게 최적화 된 경우 각 CPU에서 응용 프로그램 성능을 최적화하기 위해 각 API 수준에서 ARMv5TE 및 ARMv7 아키텍처 용 APK를 제공해야합니다. 
@참고 : 이는 APK를 ARMv5TE 및 ARMv7 라이브러리와 비교할 때만 적용되며 다른 기본 라이브러리를 비교할 때는 적용되지 않습니다.

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

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

1) APK를 수정하여 장치의 특성에 대한 지원을 "shrink"하면 다른 APK는 지원되는 범위를 벗어나는 장치를 지원하지 않습니다. 예를 들어 APK가 현재 소형 및 일반 크기 화면을 지원하고 작은 화면 만 지원하도록 변경 한 경우 지원되는 기기 풀이 축소되어 일부 기기는 더 이상 Google Play에서 내 애플리케이션을 볼 수 없습니다. 이전에 지원되는 모든 장치가 계속 지원되도록 일반 크기 화면을 지원하는 다른 APK를 추가하여이 문제를 해결할 수 있습니다.
2) 두 개 이상의 APK 사이에 "overlap"이 있는 경우. 예를 들어 APK가 화면 크기를 작게, 보통 및 크게 지원하는 경우 APK가 큰 화면 및 큰 화면을 지원하기 때문에 다른 APK가 큰 화면 및 큰 화면을 지원할 때 겹치는 부분이 있습니다. 이 문제를 해결하지 않으면 두 APK (이 예에서는 대형 화면 장치)를 모두 충족하는 장치에 가장 높은 버전 코드가있는 APK가 수신됩니다.
@참고 : 참고 : 서로 다른 CPU 아키텍처에 대해 별도의 APK를 만드는 경우 ARMv5TE의 APK가 ARMv7의 APK와 겹칠 수 있습니다. 즉, ARMv5TE 용으로 설계된 APK는 ARMv7 장치와 호환되지만 그 반대의 경우는 아닙니다 (ARMv7 라이브러리 만있는 APK는 ARMv5TE 장치와 호환되지 않습니다).

이러한 충돌이 발생하면 경고 메시지가 표시되지만 응용 프로그램을 게시 할 수는 있습니다.


*Creating multiple APKs
여러 APK를 게시하기로 결정한 후에는 게시하려는 각 APK별로 별도의 Android 프로젝트를 만들어 필요할 때 적절하게 개발할 수 있도록해야합니다. 기존 프로젝트를 복제하여 새 이름을 지정하면됩니다. (또는 빌드 구성에 따라 텍스처와 같은 다른 리소스를 출력 할 수있는 빌드 시스템을 사용할 수도 있습니다.)
@팁 : 응용 프로그램 코드의 상당 부분을 복제하지 않으려면 라이브러리 프로젝트를 사용하는 것이 좋습니다. 라이브러리 프로젝트는 공유 코드와 리소스를 보유하고 있으며 실제 응용 프로그램 프로젝트에 포함 할 수 있습니다.

동일한 애플리케이션에 대해 여러 프로젝트를 생성 할 때 APK에 배치 할 장치 제한을 나타내는 이름을 사용하여 각 애플리케이션을 식별하여 쉽게 식별 할 수 있도록하는 것이 좋습니다. 예를 들어, "HelloWorld_21"은 API 레벨 21 이상으로 설계된 응용 프로그램의 좋은 이름 일 수 있습니다.

@참고 : 동일한 애플리케이션에 대해 게시하는 모든 APK는 동일한 패키지 이름을 가져야하며 동일한 인증서 키로 서명해야합니다. 여러 개의 APK에 대한 규칙을 이해해야합니다.


*Assigning version codes
동일한 애플리케이션에 대한 각 APK에는 android : versionCode 속성으로 지정된 고유 한 버전 코드가 있어야합니다. 여러 개의 APK를 게시 할 때 각 APK가 지원해야하는 구성에 따라 버전이 다를 수 있지만 경우에 따라 특정 순서로 정의되거나 정의되어야하기 때문에 버전 코드 할당에주의해야합니다.

- Ordering version codes
높은 API 수준이 필요한 APK는 일반적으로 높은 버전 코드가 있어야합니다. 예를 들어 서로 다른 API 수준을 지원하기 위해 두 개의 APK를 만드는 경우 상위 API 수준의 APK가 높은 버전 코드를 가져야합니다. 이렇게하면 기기가 더 높은 API 수준을 위해 APK를 설치하도록 시스템 업데이트를받은 경우 사용자는 앱을 업데이트하라는 알림을받습니다.

버전 코드의 순서가 다른 APK의 적용 범위 또는 APK에 대한 향후 변경 사항의 중복으로 인해 사용자가받는 APK에 어떤 영향을 미칠지 고려해야합니다.

예를 들어 화면 크기에 따라 APK가 다른 경우 (예 : 일반 - 대형 및 대형 - 대형) APK를 소형 및 일반 - xlarge로 변경하는 경우 APK를 변경할 예정입니다. large - xlarge 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 스토어는 대상 기기와 호환되며 버전 코드가 가장 높은 앱 버전을 설치하므로,
범용 APK에 lower versionCode를 할당하면 Google Play 스토어가 다른 APK 중 하나를 설치하려고 시도하기 전에보다 큰 범용 APK로 폴백합니다.

'Programming > Android' 카테고리의 다른 글

ABI에 대해 여러 개의 APK 구성  (0) 2019.07.01
AndroidManifest란?  (0) 2019.05.19
Application.mk란?  (0) 2019.05.19
Android.mk란?  (0) 2019.05.19
ABI란?  (0) 2019.04.22