안녕하세요 리앱팀입니다~ :)
어느덧 무더운 여름이 시작 되었네요.
오늘은 AAB의 에 대해서 소개하고자 합니다.
우리의 앱 서비스를 성장 시키기 위해 가장 필요한 것 중 하나는 앱의 신규 다운로드 또는 신규 설치 수의 증가일 것입니다.
이와 관련한 구글의 보고에 따르면 앱 다운로드는 앱 패키지의 사이즈가 매우 중요한 역할을 한다고 말하고 있으며, 이로 인해 우리는 앱 패키지의 사이즈를 줄이기 위해 많은 노력을 해왔습니다. 하지만 이러한 노력에도 불구하고 최근 구글 플레이에서의 64bit 지원정책으로 인해 패키지 사이즈의 증가에 대한 고민이 다시 화두가 되고 있습니다.
이러한 앱 패키지 사이즈 증가를 해결할 수 있는 ANDROID APP BUNDLE (AAB)에 대해 이야기 하고 AAB로의 전환 시 손쉽게 동작 테스트를 할 수 있는 방안을 이야기 합니다.
google에서 발표한 자료에 따르면 2012년 3월부터 2018년 1월 까지 앱 패키지의 용량은 5배씩 증가 하고 있으며 앱 패키지의 용량은 앱 다운로드에 매우 중요한 역할을 한다고 보고 하고 있습니다.
또한 앱 패키지의 사이즈가 6MB씩 증가할 때마다 심각한 전환율의 손실이 발생한다고 발표하고 있습니다.
기존 안드로이드 시스템에서는 32bit native library만 구비 하면 32비트 기기 뿐 아니라 64비트 기기에서도 32비트 모드로 동작이 가능 했으며 x86 기기에서도 Houdini system을 통하여 native library의 추가 없이 정상적으로 동작이 가능 하였습니다.
하지만 이번 64비트 지원 정책으로 인해 64비트용 native library를 build하여 패키지에 추가 하여야 했기 때문에 앱 패키지의 용량은 불가피하게 증가할 수 밖에 없는 상황에 직면 하였습니다. 특히 UNITY 를 이용한 앱일 경우 64bit를 지원하기 위해서 IL2CPP 모드를 사용해야 하고 이를 32비트용 64비트용 모두 패키징하면 앱 패키지의 크기가 많이 늘어 남을 체감할 수 있습니다.
이러한 앱 패키지의 용량 증가 이슈 때문에 이를 해결하기 위한 방안으로 AAB가 제시 되고 있습니다.
ANDROID APP BUNDLE(AAB)
AAB는 IOS의 appthinning과 비슷한 목적을 가진 기능으로써 구글에서 패키지의 용량을 감소시켜 효율적인 앱 서비스 운영을 위해 제안하는 모델입니다. 구글에서 안내하는 AAB의 이점을 요약하면 아래와 같습니다.
여기서 AAB가 우리에게 줄 수 있는 이점 중 패키지의 용량에 관한 부분을 추려 보면, 각 사용자의 디바이스에 맞는 리소스와 구성품으로 구성된 APK를 만들어 배포함으로써 사용자에게 다운로드의 시간을 줄여 준다는 것입니다.
사용자가 기존의 앱 패키지를 AAB로 손쉽게 전환하기 위해서 android studio 와 UNITY에서는 간편한 설정 변경만으로 적용할 수 있도록 지원하고 있습니다. 아래는 기존의 앱 패키지가 AAB로 전환되었을 때의 구조를 나타냅니다.
AAB TEST
이렇게 변환된 AAB는 실제 서비스에 업데이트 되기 전 호환성 검증을 위한 QA가 필요하며, 이를 위한 일반적인 AAB 테스트 방안은 크게 아래 두가지 중 하나를 선택하여 진행이 되어 집니다.
1.GOOGLE PLAY BETA TEST에 등록
2.개발환경과 연결된 디바이스에 직접 설치
1번의 구글 플레이를 이용하는 방안은 BETA TEST에 테스터의 계정을 추가하여 테스트 진행할 수 있습니다. 많은 개발자 및 QA 인력들이 기존 APK를 테스트할 때 2번의 방법을 가장 많이 사용하였을 것입니다.
APK 파일 상태에서는 앱 QA를 위해 adb를 이용하여 apk파일을 직접 디바이스에 설치하여 테스트 하였지만 AAB 로 변환하게 되면 기존 adb를 이용한 디바이스 인스톨은 불가능해지며 bundletool이라는 툴을 이용하여 디바이스에 설치할 수 있습니다.
Bundletool을 이용하여 디바이스에 설치하기 위해서는 'aab' 파일을 'apks'로 변환하고 apks를 디바이스에 'Install'하는 순으로 진행이 되어야 합니다. Bundletool로 AAB파일을 APKs로 변환 시 옵션에 따라 크게 아래와 같이 2가지의 모드로 나눌 수 있습니다.
[ AAB INSTALL ]
AAB -> APKs -> INSTALL
[ APKs Mode ]
APKs ( dynamic feature modules )
APKs ( universal module )
APKs ( dynamic feature modules )는 AAB로 앱 서비스 시 GOOGLE PLAY를 통하여 배포되는 방식과 가장 유사하며, APKs 패키지 안에 각 디바이스에 맞는 많은 split apk들이 포함되어 있습니다. APKs ( universal module )는 단일의 apk로 구성되어 있으며, 하나의 apk를 통하여 모든 디바이스에 설치가 가능한 모드 입니다. 해당 모드는 AAB의 이점이 없는 기존 APK와 동일한 구성을 가지고 있으며, 이는 GOOGLE PLAY를 통한 배포가 아닌 다른 목적의 배포를 위해 사용될 수 있습니다.
각 모드로 변환 시키는 command는 아래와 같습니다.
APKs ( dynamic feature modules )
java -jar "bundletool-all-0.10.0.jar" build-apks --bundle="your.aab" --output="dynamic.apks"
APKs ( universal module )
java -jar "bundletool-all-0.10.0.jar" build-apks --mode=universal --bundle="your.aab" --output="universal.apks"
또한 APKs ( dynamic feature modules )모드로 변환 시 다소 많은 시간과 리소스가 사용됨으로 현재 연결되어 있는 디바이스에 맞는 APKs만을 추출하고 INSTALL하고 싶을 때는 '--connected-device'를 통해 시간과 리소스를 절약할 수 있습니다.
이렇게 위와 같이 추출된 APKs를 통해 디바이스에 설치할 수 있습니다.
[ APKs ( dynamic feature modules ) '--connected-device']
java -jar "bundletool-all-0.10.0.jar" build-apks --connected-device --bundle="your.aab" --output="dynamic.apks"
[ Bundletool install ]
java -jar "bundletool-all-0.10.0.jar" install-apks --apks="dynamic.apks"
지금 까지 AAB를 APKs로 변환하고 INSTALL할 수 있는 방법을 알아 보았습니다. 만약 build한 AAB에 LIAPP과 같은 앱 보안 서비스를 적용하여 앱 패키지가 변경되는 경우 jarsigner를 이용하여 앱 사이닝을 수동으로 진행 할 수 있습니다. AAB에 앱 사이닝을 하실 경우 signing algorithm을 SHA256 이상으로 진행 하여야 GOOGLE PLAY에 정상적으로 업데이트 됨으로 이를 유의 하셔야 합니다.
[ AAB SIGNING ]
jarsigner -verbose -sigalg SHA256withRSA -digestalg SHA-256 -keystore [키스토어 파일 Path][사이닝 할 APP의 Path] [키 생성 시 만들었던 사용자의 alias_name]
ex. jarsigner -verbose -sigalg SHA256withRSA -digestalg SHA-256 -keystore /your.keystore /your.aab LOCKINCOMPANY
지금 까지 AAB의 구조와 장점 그리고 TEST방안에 대해서 이야기를 해 보았습니다. 이 글에서 쓴 예시는 가장 일반적이고 쉽게 이용할 수 있는 커맨드로 예를 들었음으로 추가 옵션을 통해서 더욱 많은 기능들을 사용할 수 있으니 함께 보시면 도움이 될 것이라 생각 됩니다.
좋은글 감사힙니다!!