Skip to content

Most visited

Recently visited

navigation

빌드 변형 구성

이 페이지는 빌드 개요 구성을 토대로 하며, 단일 프로젝트에서 다양한 버전의 앱을 생성하기 위해 빌드 변형을 구성하는 방법과 종속성 및 서명 구성을 올바로 관리하는 방법을 보여줍니다.

빌드 변형은 여러분이 빌드할 수 있는 다양한 버전의 앱을 나타냅니다. 예를 들어, 콘텐츠가 제한된 무료 버전의 앱을 빌드하고, 더 많은 콘텐츠가 포함된 유료 버전의 앱을 빌드할 수 있습니다. 또한 API 레벨이나 기타 기기 변화에 따라 다양한 기기에 맞게 다양한 버전의 앱을 빌드할 수도 있습니다. 그러나, 기기 ABI나 화면 밀도에 따라 다양한 버전을 빌드하려는 경우에는 그 대신 APK 분할을 사용합니다.

빌드 변형은 Gradle이 특정 규칙 세트를 사용하여 빌드 유형과 제품 버전에 구성된 설정, 코드 및 리소스를 조합한 결과입니다. 여러분이 빌드 변형을 직접 구성하는 것은 아니며, 이를 형성하는 빌드 유형과 제품 버전을 구성하는 것입니다.

예를 들어, "데모" 제품 버전에서는 다양한 기능과 기기 요구사항을 지정할 수 있는 반면(예: 사용자 지정 소스 코드, 리소스 및 최소 API 레벨), "디버그" 빌드 유형에서는 다양한 빌드 및 패키징 설정을 적용할 수 있습니다(예: 디버그 옵션 및 서명 키). 결과 빌드 변형은 "demoDebug" 버전의 앱이며 여기에는 "데모" 제품 버전, "디버그" 빌드 유형 및 main/ 소스 세트에 포함된 구성 및 리소스의 조합이 포함됩니다.

빌드 유형 구성

모듈 레벨 build.gradle 파일의 android {} 블록 내에 빌드 유형을 생성하고 구성할 수 있습니다. 여러분이 새 모듈을 생성하면 Android Studio가 여러분을 대신하여 디버그 및 릴리스 빌드 유형을 자동으로 생성합니다. 디버그 빌드 유형이 빌드 구성 파일에 나타나지 않더라도, Android Studio는 debuggable true로 이 빌드 유형을 구성합니다. 따라서 보안 Android 기기에서 앱을 디버깅할 수 있으며 일반 디버그 키스토어로 APK 서명을 구성합니다.

특정 설정을 추가하거나 변경하려는 경우 이 디버그 빌드 유형을 자신의 구성에 추가할 수 있습니다. 다음 샘플에서는 디버그 빌드 유형에 대해 applicationIdSuffix를 지정하고, 디버그 빌드 유형의 설정을 사용하여 초기화된 "jnidebug" 빌드 유형을 구성합니다.

android {
    ...
    defaultConfig {...}
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
        }

        /**
         * The 'initWith' property allows you to copy configurations from other build types,
         * so you don't have to configure one from the beginning. You can then configure
         * just the settings you want to change. The following line initializes
         * 'jnidebug' using the debug build type, and changes only the
         * applicationIdSuffix and versionNameSuffix settings.
         */

        jnidebug {

            // This copies the debuggable attribute and debug signing configurations.
            initWith debug

            applicationIdSuffix ".jnidebug"
            jniDebuggable true
        }
    }
}

참고: 빌드 구성 파일을 변경하면 Android Studio가 프로젝트를 새 구성으로 동기화하도록 요청합니다. 프로젝트를 동기화하려면, 변경을 수행하자마자 바로 나타나는 알림 막대에서 Sync Now를 클릭하거나 또는 툴바에서 Sync Project 를 클릭합니다. Android Studio에서 구성 오류가 발견되면, 문제가 무엇인지 설명해주는 Messages 창이 나타납니다.

빌드 유형에서 구성할 수 있는 모든 속성에 대해 자세히 알아보려면 빌드 유형 DSL 참조를 읽어보세요.

제품 버전 구성

제품 버전을 생성하는 것은 빌드 유형을 생성하는 것과 유사하며, 제품 버전을 productFlavors {} 블록에 추가하고 원하는 설정을 구성하면 됩니다. 제품 버전은 defaultConfig와 동일한 속성을 지원합니다. 그 이유는 defaultConfig가 실제로 ProductFlavor 클래스에 속해 있기 때문입니다. 즉, defaultConfig {} 블록에 있는 모든 버전에 대해 기본 구성을 제공할 수 있으며, 각 버전은 applicationId와 같은 모든 기본값을 재정의할 수 있습니다.

참고: 그래도 여전히 main/ 매니페스트 파일에 있는 package 특성을 사용하여 패키지 이름을 지정해야 합니다. 또한 소스 코드에서 해당 패키지 이름을 사용하여 R 클래스를 참조하거나 상대적 액티비티나 서비스 등록을 확인해야 합니다. 이렇게 하면 소스 코드를 변경할 필요 없이 applicationId를 사용하여 각 제품 버전에 패키징 및 배포용 고유 ID를 제공할 수 있습니다.

다음 코드 샘플에서는 applicationIdversionName으로 "데모" 제품 버전과 "풀" 제품 버전을 생성합니다.

android {
    ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {
        demo {
            applicationId "com.example.myapp.demo"
            versionName "1.0-demo"
        }
        full {
            applicationId "com.example.myapp.full"
            versionName "1.0-full"
        }
    }
}

참고: Google Play에서 다중 APK 지원을 사용하여 앱을 배포하려면, 모든 변형에 동일한 applicationId 값을 할당하고 각 변형에 다른 versionCode를 부여합니다. 다양한 앱 변형을 별도의 앱으로 Google Play에 배포하려면, 각 변형에 다른 applicationId를 할당해야 합니다.

제품 버전을 생성하고 구성한 후, 알림 막대에서 Sync Now를 클릭합니다. 동기화가 완료되면 Gradle은 빌드 유형과 제품 버전에 따라 자동으로 빌드 변형을 생성하고 <product-flavor><Build-Type>에 따라 빌드 변형의 이름을 지정합니다. 예를 들어, '데모' 및 '풀' 제품 버전을 생성하고 기본 '디버그' 및 '릴리스' 빌드 유형을 유지하면 Gradle은 다음과 같은 빌드 변형을 만듭니다.

빌드 변형을 여러분이 빌드하고 실행하고자 하는 것으로 변경할 수 있습니다. Build > Select Build Variant로 이동하여 드롭다운 메뉴에서 빌드 변형을 선택합니다. 그러나 고유한 기능과 리소스를 가진 빌드 변형의 사용자 지정을 시작하려면, 소스 세트를 생성하고 관리하는 방법을 알아야 합니다.

빌드 변형의 소스 세트 생성

기본적으로 Android Studio는 모든 빌드 변형 간에 여러분이 공유하려는 모든 것에 대해 main/ 소스 세트 및 디렉토리를 생성합니다. 그러나 특정 빌드 유형, 제품 버전 및 빌드 변형에 대해 Gradle이 컴파일하고 패키징하는 파일을 정확히 제어하기 위해 새로운 소스 세트를 생성할 수 있습니다. 예를 들어, 기본적인 기능은 main/ 소스 세트에 정의하고, 제품 버전 소스 세트를 사용하여 다양한 클라이언트에 대해 앱 브랜드를 변경하거나 디버그 빌드 유형을 사용하는 빌드 변형에 대해서만 특별 권한과 로깅 기능을 포함할 수 있습니다.

Gradle은 여러분이 main/ 소스 세트와 유사한 방식으로 소스 세트 파일과 디렉토리를 구성할 것으로 예상합니다. 예를 들어, Gradle은 "디버그" 빌드 유형 전용의 Java 클래스 파일이 src/debug/java/ 디렉토리에 있을 것으로 예상합니다.

Gradle용 Android 플러그인은 각 빌드 유형, 제품 버전 및 빌드 변형에 대한 파일 구성 방법을 보여주는 유용한 Gradle 작업을 제공합니다. 예를 들어, 다음 보고서 섹션은 Gradle이 "디버그" 빌드 유형에 대해 특정 파일을 찾을 것으로 예상되는 위치를 설명합니다.

------------------------------------------------------------
Project :app
------------------------------------------------------------

...

debug
----
Compile configuration: compile
build.gradle name: android.sourceSets.debug
Java sources: [app/src/debug/java]
Manifest file: app/src/debug/AndroidManifest.xml
Android resources: [app/src/debug/res]
Assets: [app/src/debug/assets]
AIDL sources: [app/src/debug/aidl]
RenderScript sources: [app/src/debug/rs]
JNI sources: [app/src/debug/jni]
JNI libraries: [app/src/debug/jniLibs]
Java-style resources: [app/src/debug/resources]

여러분의 빌드 구성에 대해 이 보고서를 생성하고 보려면, 다음 단계를 진행하세요.

  1. IDE 창 오른쪽에서 Gradle 을 클릭합니다.
  2. MyApplication > Tasks > android로 이동하여 sourceSets을 두 번 클릭합니다.
  3. 보고서를 보려면, IDE 창 아래쪽에서 Gradle Console 을 클릭합니다.

참고: 이 보고서는 또한 앱에 테스트를 실행하는 데 사용할 파일의 소스 세트를 구성하는 방법도 보여줍니다(예: test/androidTest/ 테스트 소스 세트).

새 빌드 변형을 생성할 때 Android Studio가 소스 세트 디렉토리를 자동으로 생성하지는 않지만, 도움이 되는 몇 가지 옵션을 제공합니다. 예를 들어, "디버그" 빌드 유형에 대해 java/ 디렉토리만 생성하려면:

  1. Project 창을 열고 창 상단의 드롭다운 메뉴에서 Project 뷰를 선택합니다.
  2. MyProject/app/src/로 이동합니다.
  3. src 디렉토리를 마우스 오른쪽 버튼으로 클릭하고 New > Folder > Java Folder를 선택합니다.
  4. Target Source Set 옆의 드롭다운 메뉴에서 debug를 선택합니다.
  5. Finish를 클릭합니다.

Android Studio가 디버그 빌드 유형에 대해 소스 세트 디렉토리를 생성한 다음, 그 안에 java/ 디렉토리를 생성합니다. 또는 특정 빌드 변형에 대해 새 파일을 생성할 때, Android Studio가 자동으로 디렉토리를 생성하도록 할 수도 있습니다. 예를 들어, "디버그" 빌드 유형에 대해 Values XML 파일을 생성하려면:

  1. 동일한 Project 창에서 src 디렉토리를 마우스 오른쪽 버튼으로 클릭하고 New > XML > Values XML File을 선택합니다.
  2. XML 파일의 이름을 입력하거나 기본 이름을 유지합니다.
  3. Target Source Set 옆의 드롭다운 메뉴에서 debug를 선택합니다.
  4. Finish를 클릭합니다.

"디버그" 빌드 유형이 대상 소스 세트로 지정되었기 때문에, Android Studio는 XML 파일을 생성할 때 필요한 디렉토리를 자동으로 생성합니다. 결과 디렉토리 구조는 그림 2와 같아야 합니다.

그림 2. 디버그 빌드 유형에 대한 새 소스 세트 디렉토리.

또한 동일한 절차를 사용하여 제품 버전(예: src/demo/)과 빌드 변형(예: src/demoDebug/)에 대한 소스 세트 디렉토리를 생성할 수도 있습니다. 또는 특정 빌드 변형을 대상으로 하는 테스트 소스 세트를 생성할 수 있습니다(예: src/androidTestDemoDebug/). 자세히 알아보려면 테스트 소스 세트로 이동하세요.

소스 세트로 빌드

소스 세트 디렉토리를 사용하여 특정 구성으로만 패키징하려는 코드와 리소스를 포함할 수 있습니다. 예를 들어, "데모" 제품 버전과 "디버그" 빌드 유형의 교차 제품(crossproduct)인 "demoDebug" 빌드 변형을 빌드하는 경우, Gradle은 아래의 디렉토리를 찾아서 다음과 같이 우선순위를 부여합니다.

  1. src/demoDebug/ (빌드 변형 소스 세트)
  2. src/debug/ (빌드 유형 소스 세트)
  3. src/demo/ (제품 버전 소스 세트)
  4. src/main/ (메인 소스 세트)

위에 나열된 순서는 Gradle이 코드와 리소스를 조합할 때 어떤 소스 세트의 우선순위가 더 높은지를 결정합니다. demoDebug/ 소스 세트 디렉토리에는 해당 빌드 변형에 특정한 파일이 포함될 가능성이 높으므로, debug/에 정의된 파일이 demoDebug/에도 포함된 경우, Gradle은 demoDebug/ 소스 세트에 있는 파일을 사용합니다. 마찬가지로, Gradle은 main/에 있는 파일보다 빌드 유형 및 제품 버전 소스 세트에 있는 동일한 파일에 더 높은 우선순위를 부여합니다. Gradle은 다음과 같은 빌드 규칙을 적용할 때 이 우선순위를 고려합니다.

종속성 선언

다음 예에서는 다양한 종류의 직접 종속성을 app/ 모듈의 build.gradle 파일에 선언합니다.

android {...}
...
dependencies {
    // The 'compile' configuration tells Gradle to add the dependency to the
    // compilation classpath and include it in the final package.

    // Dependency on the "mylibrary" module from this project
    compile project(":mylibrary")

    // Remote binary dependency
    compile 'com.android.support:appcompat-v7:25.1.0'

    // Local binary dependency
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

이러한 각 직접 종속성이 아래에 설명되어 있습니다.

모듈 종속성
compile project(':mylibrary') 줄은 "mylibrary"라는 로컬 Android 라이브러리 모듈을 종속성으로 선언하며, 앱을 빌드할 때 로컬 모듈을 컴파일하고 포함하도록 빌드 시스템에 요구합니다.
원격 바이너리 종속성
compile 'com.android.support:appcompat-v7:25.1.0' 줄은 JCenter 좌표를 지정하여 버전 25.1.0의 Android Support Library에 대한 종속성을 선언합니다. 기본적으로, Android Studio는 JCenter Repository를 최상위 빌드 파일에서 사용하도록 프로젝트를 구성합니다. 프로젝트를 빌드 구성 파일과 동기화할 때 Gradle은 자동으로 JCenter에서 종속성을 가져옵니다. 또는, SDK Manager를 사용하여 특정 종속성을 다운로드하고 설치할 수 있습니다.
로컬 바이너리 종속성
compile fileTree(dir: 'libs', include: ['*.jar']) 줄은 app/libs/ 디렉토리 내의 모든 JAR 파일을 컴파일 클래스 경로와 최종 앱 패키지에 포함하도록 빌드 시스템에 알립니다. 로컬 바이너리 종속성을 요구하는 모듈이 있는 경우, 이 종속성에 대한 JAR 파일을 프로젝트 내의 <moduleName>/libs에 복사합니다.

모듈의 직접 종속성 중 일부는 모듈의 이행성 종속성이라고 하는 자체 종속성이 있을 수 있습니다. 각 이행성 종속성을 수동으로 선언할 필요가 없으며, Gradle이 이 종속성을 자동으로 수집하고 추가합니다. Gradle용 Android 플러그인은 각 빌드 변형 및 테스트 소스 세트에 대해 종속성 트리를 생성할 수 있는 유용한 Gradle 작업을 제공하므로, 모듈의 직접 종속성 및 이행성 종속성을 쉽게 시각화할 수 있습니다. 이 보고서를 생성하려면, 다음 단계를 진행하세요.

  1. IDE 창 오른쪽에서 Gradle 을 클릭합니다.
  2. MyApplication > Tasks > android로 이동하여 androidDependencies를 두 번 클릭합니다.
  3. 보고서를 보려면, IDE 창 아래쪽에서 Gradle Console 을 클릭합니다.

다음 샘플은 디버그 빌드 변형에 대한 종속성 트리를 보여주며, 이전 예시의 로컬 모듈 종속성과 원격 종속성을 포함합니다.

Executing tasks: [androidDependencies]
:app:androidDependencies
debug
/**
 * Both the library module dependency and remote binary dependency are listed
 * with their transitive dependencies.
 */
+--- MyApp:mylibrary:unspecified
|    \--- com.android.support:appcompat-v7:25.1.0
|         +--- com.android.support:animated-vector-drawable:25.1.0
|         |    \--- com.android.support:support-vector-drawable:25.1.0
|         |         \--- com.android.support:support-v4:25.1.0
|         |              \--- LOCAL: internal_impl-25.1.0.jar
|         +--- com.android.support:support-v4:25.1.0
|         |    \--- LOCAL: internal_impl-25.1.0.jar
|         \--- com.android.support:support-vector-drawable:25.1.0
|              \--- com.android.support:support-v4:25.1.0
|                   \--- LOCAL: internal_impl-25.1.0.jar
\--- com.android.support:appcompat-v7:25.1.0
     +--- com.android.support:animated-vector-drawable:25.1.0
     |    \--- com.android.support:support-vector-drawable:25.1.0
     |         \--- com.android.support:support-v4:25.1.0
     |              \--- LOCAL: internal_impl-25.1.0.jar
     +--- com.android.support:support-v4:25.1.0
     |    \--- LOCAL: internal_impl-25.1.0.jar
     \--- com.android.support:support-vector-drawable:25.1.0
          \--- com.android.support:support-v4:25.1.0
               \--- LOCAL: internal_impl-25.1.0.jar
...

Gradle에서 종속성 관리에 대한 자세한 내용은, Gradle 사용자 가이드의 종속성 관리 기본 사항을 참조하세요.

종속성 구성

종속성을 사용하는 방법과 시기를 Gradle에 알리기 위해 특정한 구성 키워드를 사용할 수 있습니다(예: 이전 예시의 compile 키워드). 아래에서는 종속성 구성에 사용할 수 있는 몇 가지 키워드를 설명합니다.

compile
컴파일 시 종속성을 지정합니다. Gradle은 이 구성이 있는 종속성을 클래스 경로와 앱의 APK 모두에 추가합니다. 이는 기본 구성입니다.
apk
Gradle이 앱의 APK와 함께 패키징해야 하는 런타임 전용 종속성을 지정합니다. 이 구성은 JAR 바이너리 종속성과 함께 사용될 수 있지만, 다른 라이브러리 모듈 종속성이나 AAR 바이너리 종속성과는 사용될 수 없습니다.
provided
Gradle이 앱의 APK와 함께 패키징하지 않는 컴파일 시 종속성을 지정합니다. 따라서 런타임 중에 종속성이 불필요하면 APK의 크기를 줄일 수 있습니다. 이 구성은 JAR 바이너리 종속성과 함께 사용될 수 있지만, 다른 라이브러리 모듈 종속성이나 AAR 바이너리 종속성과는 사용될 수 없습니다.

또는 다음 샘플에 나오는 것처럼, 빌드 변형 또는 테스트 소스 세트의 이름을 구성 키워드에 적용하여 특정 빌드 변형 또는 테스트 소스 세트에 대한 종속성을 구성할 수 있습니다.

dependencies {
    ...
    // Adds specific library module dependencies as compile time dependencies
    // to the fullRelease and fullDebug build variants.
    fullReleaseCompile project(path: ':library', configuration: 'release')
    fullDebugCompile project(path: ':library', configuration: 'debug')

    // Adds a compile time dependency for local tests.
    testCompile 'junit:junit:4.12'

    // Adds a compile time dependency for the test APK.
    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2'
}

서명 설정 구성

릴리스 빌드의 서명 구성을 명시적으로 구성하지 않는 경우, Gradle은 이 빌드의 APK를 서명하지 않습니다. Android Studio를 사용하여 쉽게 릴리스 키를 만들고 릴리스 빌드 유형을 서명할 수 있습니다.

Gradle 빌드 구성을 사용하여 릴리스 빌드 유형의 서명 구성을 수동으로 구성하려면:

  1. 키스토어를 생성합니다. 키스토어는 개인 키 세트가 포함된 바이너리 파일입니다. 키스토어는 안전하고 보안이 유지되는 장소에 보관해야 합니다.
  2. 개인 키를 생성합니다. 개인 키는 개인이나 회사와 같이 앱으로 식별되는 엔티티를 나타냅니다.
  3. 서명 구성을 모듈 레벨 build.gradle 파일에 추가합니다.

    ...
    android {
        ...
        defaultConfig {...}
        signingConfigs {
            release {
                storeFile file("myreleasekey.keystore")
                storePassword "password"
                keyAlias "MyReleaseKey"
                keyPassword "password"
            }
        }
        buildTypes {
            release {
                ...
                signingConfig signingConfigs.release
            }
        }
    }
    

서명된 APK를 생성하려면, 메뉴 모음에서 Build > Generate Signed APK를 선택합니다. 이제 app/build/apk/app-release.apk의 패키지가 릴리스 키로 서명됩니다.

참고: 릴리스 키와 키스토어의 암호를 빌드 파일 내에 포함하는 것은 보안에 좋지 않습니다. 대신 환경 변수에서 이러한 암호를 가져오도록 빌드 파일을 구성하거나 빌드 프로세스에서 이러한 암호를 입력하도록 메시지를 표시할 수 있습니다.

환경 변수에서 이러한 암호를 가져오려면:

storePassword System.getenv("KSTOREPWD")
keyPassword System.getenv("KEYPWD")

명령줄에서 빌드를 호출하는 경우, 빌드 프로세스에서 이러한 암호를 입력하도록 메시지를 표시하려면:

storePassword System.console().readLine("\nKeystore password: ")
keyPassword System.console().readLine("\nKey password: ")

이 프로세스를 완료한 후 앱을 배포하고 Google Play에 게시할 수 있습니다.

경고: 키스토어와 개인 키는 안전하고 보안된 장소에 보관하고 보안된 백업을 갖고 있어야 합니다. Google Play에 앱을 게시하고 앱에 서명한 개인 키를 분실하면 앱에 업데이트를 전혀 게시할 수 없게 됩니다. 항상 모든 앱 버전에서 같은 키로 서명해야 하기 때문입니다.

Android Wear 앱 서명

Android Wear 앱을 게시할 때는 핸드헬드 앱의 내부에 웨어러블 앱을 패키징합니다. 사용자가 웨어러블에서 직접 앱을 탐색, 설치할 수 없기 때문입니다. 두 앱은 모두 서명을 받아야 합니다. Android Wear 앱 패키징과 서명에 관한 자세한 정보는 웨어러블 앱 패키징을 참조하세요.

This site uses cookies to store your preferences for site-specific language and display options.

Hooray!

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.