여러 빌드 버전이 필요할 때 코드를 수정하시나요? 아니면 디버그 릴리즈만 분류하거나 간단한 플레이버를 쓰는 것에 그치시나요? 안세원님이 GDG 모임에서 FlavorDimension을 사용하여 간단하게 여러 버전을 관리하는 방법을 소개합니다.

FlavorDimension 소개 및 활용사례

안세원님의 10월 23일 GDG 발표 입니다.

FlavorDimension에 대한 소개와 적용방법, staged rollout과 multiple apk에 대해서 발표해 주셨습니다. FlavorDimension을 도입하게 되었는지에 대한 이유와, 어떻게 사용하는 지에 소개한 발표였습니다. 또한 staged rollout과 multiple apk에 대해서도 다뤘습니다.

FlavorDimension 소개 및 도입 배경

• 기존에는 Gradle을 사용하면서 build type과 flavor를 이용해서 signing과 서버 구분을 해서 apk 생성
  • 생성되는 buildVariants 조합은 4가지
    • devDebug
    • devRelease
    • realDebug
    • realRelease
• 그러나 프로젝트를 더 진행하다 생기는 이슈들로 인해 minSdkLevel 구분도 필요해지면서 조합이 너무 많아짐
  • 생각해본 해결방법
    • build type 이중화: debugIcs, debugBelowIcs, …
    • flavor 이중화: IcsReal, IcsDebug, BelowIcsReal, BelowIcsDebug, …
• 모두 좋지 않아서 문서를 찾아보다가 FlavorGroup이 FlavorDimension으로 바뀐 것을 발견
• FlavorDimension이란 여러 가지 apk를 만드는데 사용할 수 있는 구글의 multi-apk support

FlavorDimension 사용법

android {
   ...
   flavorDimensions "api", "server"
   productFlavors {
      belowIcs {
         flavorDimension "api"
         ...
      }
      dev {
         flavorDimension "server"
         ...
      }
   }
}

• flavorDimensions에서 사용할 차원을 선언
• productFlavors에 flavor이름과 어느 차원의 flavor인지 정의
• 이름이 만들어지는데 관련이 있으므로 flavorDimensions 순서에 주의
• buildVariants = dimension_1 * dimension_2 * build_type 만큼의 조합 개수

Gradle에서의 활용

applicationVariants.all { variant ->
   // get the version code of each flavor
   def 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
}

• array처럼 만들어지므로 가져와서 사용할 수 있음 (stackoverflow 참고)
• 매번 버전 코드를 수동 생성하는 수고를 덜 수 있음
• BuildConfig.java 파일에 각 dimension 별로 상수가 생겨서 쉽게 접근할 수 있음

staged rollout과 multiple apk

• staged rollout의 경우 둘 이상의 apk에 적용하는 것은 어려움
• 다음 두 전략 중 하나를 사용하는 것을 권장
  • A를 먼저 100%로 내보낸 후 B를 staged rollout
  • A를 staged rollout -> 100%로 내보낸 후 B를 릴리즈