그로 인해 적용되어야 하는 폰이 아닌 경우에도 모두 1개의 APK로 처리해야 하여 그만큼의 용량을 비효율적으로 사용하게 되는 경우 등이 있습니다. 멀티 APK 지원을 통해 이를 해결할 수 있도록 변경되었습니다.
여러개의 APK를 둬야 하는 아래 사항에 대하여 Multiple APK 적용이 가능한 경우들 입니다.
- CPU마다 최적화를 처리해야 하는 경우 (NDK 빌드 시)
- 이미지 사이즈를 각각 적용해야하는 경우 (DPI 순으로)
- 플렛폼 버전별로 별도의 앱을 구현해야 할 경우
- OpenGL Texture 지원 포멧에 따라서
이렇게 4가지 방식의 경우 Multiple APK를 통해 동일한 Package 이름을 사용하여 1개의 앱을 마켓에 등록하고, 위의 사항에 따라서 다운받는 안드로이드 종류에 따라서 모두 다르게 적용이 가능하도록 지원하게 됩니다.
이미지를 사이즈별로 각각 적용해야 하는 경우에는 지원하지 않는 사이즈를 가진 폰에서까지 APK에 포함되어 있는
모든 이미지를 가지게 되는 사항을 말합니다. 내폰은 XHDPI를 적용하는 폰인데 HDPI, MDPI, LDPI의 사이즈 이미지까지 모두 가지고 있어야 하는 경우입니다. 이들의 이미지 때문에 APK 파일도 커지는 경우에 적용하시면 됩니다. 이미지 1~2개를 가지고 분리하는것은 .. 의미가 없겠죠?
위와 같은 이유로 분리해야 할 경우가 있다면 Multiple APK 지원을 하시면 됩니다.
Multiple APK Rules
응용 프로그램을 Multiple APK를 지원하는 고급모드를 사용하기 전에 지켜야할 내용입니다.
- 제가 작성하는 내용은 아래 사이트를 참고하여 중요해 보이는 내용을 작성하였습니다. 모든 내용이 포함되어 있지 않으므로 자세한 내용은 아래 사이트를 참고해주세요.
- 버전 코드는 서로 다르게 가지고 있어야 합니다. 아래 Multiple APK 생성하기 부분을 참고하세요.
- 위의 분리 조건을 제외하고 지원되는 내용이 일치해야 합니다.
위에서 작성한 Multiple APK 분리 가능 조건의 내용과 일치해야 합니다. 그 외 완전히 다르게 처리하는 경우가 발생해서는 안된다는 이야기입니다. 이 경우는 전혀 다른 앱이 되는것이겠죠?
- 버전 코드가 기존에는 0400이고 새로 적용하는 APK가 0300이라면 업데이트가 불가능하게 됩니다. 버전 코드에 주의하세요.
이 정도로 정리는 했지만 더 디테일한 내용이 많이 있습니다. 대부분 버전코드에 대한 내용입니다. 안드로이드 마켓에서는 버전 코드가 기존에 작성한 코드가 1.0.0 이라면 다음 코드는 1.0.0 보다 커야 합니다. 이를 Multiple APK 룰에 따라서 적용 받으시는게 가장 안전하다는 이야기가 됩니다. 그리고 이미지 사이즈의 경우 XHDPI를 지원하는 APK가 있고, HDPI를 지원하는 APK가 있습니다. 하지만 실제로 2개 모두 XHDPI가 지원되는 형태를 가지고 있을 수 있습니다. 이럴 경우에는 오류를 발생시키게 됩니다. 모두 버전과 이미지 사이즈 등 겹치지 않게 설계해야 Multiple APK를 지원 할 수 있다는 이야기가 되겠습니다.
Multiple APK 생성하기
Multiple APK를 지원하기 위해서는 별도의 프로젝트가 필요하게 됩니다. 이렇게 별도의 프로젝트 폴더를 가지고 있어야 한다면 당연히 소스코드도 변경되어야 합니다. 그렇다고 버전에 따라서 소스코드까지 다르게 처리하기에는 너무 많은 코드를 가지게 되는 단점이 있습니다. 이럴 때는 적적하게 작성된 중복코드를 라이브러리 형태의 코드로 처리하는 것이 가장 좋은 방법이라고 합니다. 이미지만 다르게 처리하거나, 버전만 다르게 처리하거나, OpenGL Texture 지원 포멧방식만 다르게 하거나 등이있습니다. 모두 라이브러리를 통해 적절하게 처리해주면 중복 코드를 최소화 할 수 있는 방법이라고 합니다.
- Multiple APK의 버전 코드명 작성법
싱글 APK의 경우 1개의 APK 파일에 버그 패치를 하더라도 모든 폰에 적용이 되게 됩니다. 하지만 Multiple APK를 지원한 이후에는 수많은 APK에 모두 버그 패치를 적용할 필요는 없습니다. 내가 버그 패치할 1개의 파일에 대해서만 업로드하면 됩니다.
기존 싱글 APK에서는 버전 코드이름이 1.0.0 의 순서를 사용하여 버그 패치라면 1.0.1 등의 숫자가 적용됩니다. 하지만 Multiple APK는 7자리 이상의 숫자를 사용할 것을 권장한다고 합니다. 바로 아래와 같습니다.
그림의 설명에도 있지만 API Level 2자리 코드, 가운데 2자리는 스크린 사이즈이거나 OpenGL texture 지원 포멧 형식에 따른 번호, 안드로이드 앱의 현재 앱 버전코드 3자리로 구분되어 있습니다. 위에서 제공하는 버전코드는 API 4 버전에서 동작하며 스크린사이즈가 small-normal을 지원하는 3.1 버전의 앱을 의미하게 됩니다.
버전별로 스크린사이즈를 세분화 화고 싶을 경우 위와 같이 작성합니다. 위에 작성된 코드는 하나의 예일 뿐 개발자가 직접 정의하여 사용하시면 됩니다. 난 API만 구분하고 싶어의 경우라면 2.3.3을 지원하는 버전과 그 이상의 버전을 지원하는 버전 2개로 구분하는 번호를 작성하시면 됩니다.
17100 이라는 숫자를 예로 들면 17 버전의 API를 사용하고, 현재 앱 버전은 1.0.0 이라는 의미가 됩니다. minSdkVersion만 구분하시면 2.3.3 을 지원하는 앱과 구분이 가능하게 됩니다. 2.3.3 을 지원하는 경우는 10100 이 되겠죠?
이 글은 APK Support에는 없지만 참고하면 좋을것 같아추가해보았습니다.
최근 안드로이드의 해상도, 버전이 많이 추가되고 있습니다. 안드로이드에서 지원하는 해상도는 LDPI부터 XXHDPI까지 지원합니다. (XXHDPI는 최근에 추가되었지만 기존 XHDPI를 통해서도 지금은 10인치까지 지원이 되더군요) 최근에 조사한 자료에 따르면 아래 표와 같은 점유율을 가지고 있습니다. 아직 2.3.3~2.3.7 버전을 사용하는 사용자가 전체 1위에 해당됩니다. 40%가 넘게 3.0 미만의 버전을 사용하는 셈이죠. (2013.05.18)
그 다음으로 JellyBean(4.1, 4.2), ICS 27.5%, Honeycomb가 0.1% 입니다.
이번엔 적용가능한 DPI를 살펴보겠습니다. 아래와 같이 4가지 DPI 사이즈를 가지고 있습니다. 거기에 최근에 추가된 XXHDPI도 있습니다. (이 XXHDPI는 새로운 어플리케이션 생성시에 확인가능합니다.)
마무리
수많은 플렛폼과 수많은 해상도를 지원하기 위해서 단일 APK를 통해 지원할 수있는 앱이 일반적입니다. 그렇지만 게임과 같이 고해상도의 이미지가 많은 경우에는 Multiple APK를 작성하여 구분하면 됩니다. 이렇게 Multiple APK를 지원하고 싶다면 위에서 작성한 코드네임을 주의하여 작성해야 한다고 합니다. 싱글 APK의 경우는 상관 없습니다. 테블릿과 스마트폰앱을 따로 올릴 필요가 없다는 설명을.. 최종적으로 하고^^;; 마치겠습니다. 부족한 내용이 많으니 댓글로 잘못된 부분 지적 부탁드립니다.
안드로이드, Multiple APK Support
단적인 예로 현재 마켓에 등록 가능한 APK 파일은 50MB로 제한되어 있다.
이 경우 화면 해상도에 따른 여러셋의 리소스를 한 APK 에 포함할 수 없는 경우가 발생하기도 한다.
구글 플레이에서는 하나 이상의 APK 파일을 동일한 이름을 갖는 하나의 어플리케이션으로 등록할 수 있도록 지원된다.
멀티플 APK 지원을 위한 조건
다음 세 가지 형태의 메니페스트의 필터를 기반으로 구분된다.
1. OpenGL 텍스쳐 압축 포맷.
<support-gl-texture>
2. Screen Configuration
<supports-screens>, <compatible-screens> 로 표현
3. 플랫폼 버전
<uses-sdk>. 하위 호환성을 최소화하며 유지는 가져가는 데 필요하다.
UX 는?
여러개의 APK 가 있어도, 조건에 최적화된 하나의 APK 만 마켓에 표시된다. 그리고 별점과 댓글 등은 하나의 앱으로 관리된다.
결론
하나의 앱을 여러 APK 로 분리하여 배포하는 것은 권장사항은 아니지만, 제약조건이 있을 때는 더 좋은 조건이 될 수도 있다.
하나의 APK 는 배포 과정도 단순하고, 코드 유지 보수에도 장점이 많다.
Building multiple APKs inside Android Studio
Build variants are a huge feature for Android development. The use cases for such a feature are many. It can be as simple as having a free version of your app and a paid version. Or maybe you are making generic software that can be sold to many companies that all want they're own branding.
Whatever your use case may be, Gradle comes to the rescue. Not only can you configure your variants but you can also select which ones actually get built. You are probably already aware of the standard way to do this in Android Studio which is to use the "Build Variants" tool window and select the variant that you want to build.
This builds one variant at a time and is very practical while you are developing as it allows you to quickly switch from one variant to the another.
Once development is done, you will want to build all of your release variants for final testing and distribution. You can do this in Android Studio as well. Simply open the "Gradle Tasks" tool window, which is usually on the right. You will see many tasks that start with 'assemble', double click on one of those and your APKs will be created.
For example, double clicking on 'assembleRelease' will create all your release apks.
From the docs:
Building and Tasks
We previously saw that each Build Type creates its own assemble task , but that Build Variants are a combination of Build Type and Product Flavor.
When Product Flavors are used, more assemble-type tasks are created. These are:
1) assemble[Variant Name]
2) assemble[Build Type Name]
3) assemble[Product Flavor Name]
1) allows directly building a single variant. For instance assembleFlavor1Debug.
2) allows building all APKs for a given Build Type. For instance assembleDebug will build both Flavor1Debug and Flavor2Debug variants.
3) allows building all APKs for a given flavor. For instance assembleFlavor1 will build both Flavor1Debug and Flavor1Release variants.
The task assemble will build all possible variants.
Note the "Recent tasks" section which allows you to quickly execute previously run tasks.
[참고]
Android Studio / Gradle
build.gradle을 아래와 같이 수정하세요:
android {
// 앱 로직의 남은 부분
splits {
abi {
enable true
reset()
include 'x86', 'x86_64', 'arm64-v8a', 'armeabi-v7a', 'armeabi'
Taking the Ks off your APKs (part 1) EverythingMe had a long time running bug related to orientation change, caused by the (crazy fact in 3…2…1…) fact that View will not get the Activity’s onConfigurationChange() when it’s not attached. The bug manifested in phones, although they were programmatically configured to dump any orientation change events, some did slip in as the launcher activity started while phone is in landscape mode, causing the views to not receive the programatic forced portrait configuration change, and keep the landscape resources loaded when in portrait mode.
The original solution
While looking for a solution, we determined that the best solution for us would be totally eliminating configuration changes on phones (while keeping everything operational for tablets). Gradle’s apk splits seemed like the perfect solution. Moreover, it will shrink our user-facing APK size and lower our resource count (no tablet resources on the phone builds), making it much faster to install with Android’s package installer.
Android Tools Project have released abi splits around v0.14 of com.android.tools.build:gradle, and density splits around v1.0 (?) (I couldn’t find the actual version where it was released), but at the time of writing these lines, there still is no built-in solution for phone-tablet apk splits.
I came across this thread in google groups. Douglas Ferguson and Matthew Townsend came up with a solution (a bit hacky, but hey, it works!). The solution involves manipulation on the AndroidManifest.xml files at build time. Gradle creates different versions the project’s resources in intermediates directory, just before they are wrapped into the final APKs.But this solution stopped working after gradle 0.6.3, and after digging into changes in gradle’s source code I came back with these findings:
There was a gradle api change: variant.processManifest.doLast has been moved deeper into output.processManifest.doLast
intermediate manifest files have been moved frombuild/filtered_manifested/${variant.name}/AndroidManifest.xml to${buildDir}/intermediates/manifests/full/${screenSize}/${density}/${abi}/${buildType}/AndroidManifest.xml
Let’s see how the revised solution works:
Background
First, we’ll need to take a look at the gradle configuration of a density splitted apk:
When we add the compatibleScreens tag in density splits configuration, gradle will add the following lines in each splitted manifest file (this example is taken for the xhdpi manifest):
In order to split the apks to phones and tablets we thought that removing the android:screenSize=”xlarge” line from phone builds, we’d be able to easily tell google play to distribute this build only to phones. Taking a closer look showed us that Android largeScreens refers both to 5” devices and 7” devices, therefore in here google notes:
NOTE: Android 3.2 introduces new attributes: android:requiresSmallestWidthDp, android:compatibleWidthLimitDp, and android:largestWidthLimitDp. If you’re developing your application for Android 3.2 and higher, you should use these attributes to declare your screen size support, instead of the attributes based on generalized screen sizes.So by using both requiresSmallestWidthDp and xScreens google play developer console will both distribute the correct APK to big screen phones and tablets, and show what screen layout the specific APK supports (this example is taken for the same phone-xhdpi manifest).
In some case, one may want to create several versions of the same apps based on more than one criteria. For instance, multi-apk support in Google Play supports 4 different filters. Creating different APKs split on each filter requires being able to use more than one dimension of Product Flavors.
Consider the example of a game that has a demo and a paid version and wants to use the ABI filter in the multi-apk support. With 3 ABIs and two versions of the application, 6 APKs needs to be generated (not counting the variants introduced by the different Build Types). However, the code of the paid version is the same for all three ABIs, so creating simply 6 flavors is not the way to go. Instead, there are two dimensions of flavors, and variants should automatically build all possible combinations.
This feature is implemented using Flavor Dimensions. Flavors are assigned to a specific dimension android { ...
flavorGroups was replaced by flavorDimensions, so you need to use next code at build.gradle
// 2 dimensions of flavors. API is more important than ABI.
flavorDimensions "api","abi"
productFlavors {
gingerbread {
flavorDimension "api"
minSdkVersion 10
versionCode =1}
icecreamSandwich {
flavorDimension "api"
minSdkVersion 14// this must be higher than the gingerbread version to ensure update of the// app when the device gets a system update from GB to ICS
versionCode =2}
x86 {
flavorDimension "abi"
ndk.abiFilter "x86"// this is the flavor part of the version code.// It must be higher than the arm one for devices supporting// both, as x86 is preferred.
versionCode =3}
arm {
flavorDimension "abi"
ndk.abiFilter "armeabi-v7a"
versionCode =1}
mips {
flavorDimension "abi"// It must be higher than the arm one for devices supporting// both, as mips is preferred.
ndk.abiFilter "mips"
versionCode =2}
fat {
flavorDimension "abi"// fat binary, lowest version code to be// the last option
versionCode =0}}// make per-variant version code
applicationVariants.all { variant ->// get the version code of each flavordef apiVersion = variant.productFlavors.get(0).versionCode
def abiVersion = variant.productFlavors.get(1).versionCode
// set the composite code
variant.mergedFlavor.versionCode = apiVersion *1000000+ abiVersion *100000+ defaultConfig.versionCode
}
Update:
Add these lines to be able see versionCode at generated names of apk
gradle-27508708-master.zip