Skip to content

Most visited

Recently visited

navigation

빌드 구성

동영상

새로운 Android SDK 빌드 시스템

Android 빌드 시스템은 앱 리소스 및 소스 코드를 컴파일하고 여러분이 테스트, 구축, 서명 및 배포할 수 있는 APK로 패키징합니다. Android Studio는 고급 빌드 툴킷인 Gradle을 사용하여 빌드 프로세스를 자동화하고 관리하는 한편, 여러분은 유용한 사용자 지정 빌드 구성을 정의할 수 있습니다. 각 빌드 구성에서는 자체적인 코드 및 리소스 세트를 정의할 수 있으며, 모든 앱 버전에 공통되는 부분을 재사용하기도 합니다. Gradle용 Android 플러그인과 빌드 툴킷을 함께 사용하면, Android 애플리케이션을 빌드하고 테스트하는 데 필요한 특정 프로세스와 구성 가능 설정을 제공할 수 있습니다.

Gradle과 Android 플러그인은 Android Studio와 독립적으로 실행됩니다. 즉, Android Studio 내에서나, 컴퓨터의 명령줄에서나, Android Studio가 설치되지 않은 컴퓨터(예: Continuous Integration 서버)에서도 Android 앱을 빌드할 수 있습니다. Android Studio를 사용하지 않는 경우에는 명령줄에서 앱을 빌드하고 실행하는 방법에 대해 알아볼 수 있습니다. 프로젝트를 명령줄에서 빌드하든, 원격 컴퓨터에서 빌드하든, Android Studio를 사용하여 빌드하든 간에 빌드의 출력은 동일합니다.

참고: Gradle과 Android 플러그인은 Android Studio와 독립적으로 실행되므로, 빌드 도구를 별도로 업데이트해야 합니다. Gradle 및 Android 플러그인의 업데이트에 대해 알아보려면 릴리스 노트를 참조하세요.

Andriod 빌드 시스템은 유연성이 탁월하므로 앱의 핵심 소스 파일을 수정할 필요 없이 사용자 지정 빌드 구성을 수행할 수 있습니다. 이 섹션에서는 Android 빌드 시스템의 작동 방식과 여러 개의 빌드 구성을 사용자 지정하고 자동화하는 방법에 대해 설명합니다. 앱 배포에 대해 자세히 알아보려면, Android Studio에서 빌드 및 실행을 참조하세요. 지금 바로 Android Studio를 사용하여 사용자 지정 빌드 구성을 생성하려면, 빌드 변형 구성을 참조하세요.

빌드 프로세스

빌드 프로세스에는 프로젝트를 Android 애플리케이션 패키지(APK)로 변환해주는 여러 가지 도구와 프로세스가 포함됩니다. 빌드 프로세스는 매우 유연하므로, 이 프로세스가 어떤 식으로 작동하는지 이해한다면 유용할 것입니다.

그림 1. 일반적인 Android 앱 모듈의 빌드 프로세스.

그림 1은 일반적인 Android 앱 모듈의 빌드 프로세스를 나타내며 다음과 같은 일반적인 단계를 따릅니다.

  1. 컴파일러는 소스 코드를 DEX(Dalvik Executable) 파일로 변환하고 그 외 모든 것을 컴파일된 리소스로 변환합니다. 이 DEX 파일에는 Android 기기에서 실행되는 바이트코드가 포함됩니다.
  2. APK Packager는 DEX 파일과 컴파일된 리소스를 단일 APK에 결합합니다. 그러나 앱을 Android 기기에 설치하고 배포할 수 있으려면 APK를 서명해야 합니다.
  3. APK Packager는 디버그 또는 릴리스 키스토어를 사용하여 APK를 서명합니다.
    1. 디버그 버전의 앱(즉, 테스트 및 프로파일링 전용의 앱)을 빌드 중인 경우에는, 패키저가 디버그 키스토어로 앱에 서명합니다. Android Studio는 디버그 키스토어로 새 프로젝트를 자동으로 구성합니다.
    2. 릴리스 버전의 앱(즉, 외부에 릴리스할 앱)을 빌드 중인 경우에는, 패키저가 릴리스 키스토어로 앱에 서명합니다. 릴리스 키스토어를 생성하려면, Android Studio에서 앱 서명을 참조하세요.
  4. 최종 APK를 생성하기 전에, 패키저는 기기에서 실행될 때 더 적은 메모리를 사용하도록 앱을 최적화하기 위해 zipalign 도구를 사용합니다.

빌드 프로세스가 끝나면 배포, 테스트 또는 외부 사용자에게 릴리스할 수 있는 디버그 APK 또는 릴리스 APK가 생성됩니다.

사용자 지정 빌드 구성

Gradle과 Android 플러그인을 사용하여 다음과 같은 빌드 요소를 구성할 수 있습니다.

빌드 유형
빌드 유형은 앱을 빌드하고 패키징할 때 Gradle이 사용하는 특정 속성을 정의합니다. 일반적으로 개발 주기의 다양한 단계에 대해 빌드 유형이 구성됩니다. 예를 들어, 디버그 빌드 유형은 디버그 옵션을 활성화하고 디버그 키로 APK를 서명하는 반면, 릴리스 빌드 유형은 배포를 위해 APK를 축소, 난독 처리하고 릴리스 키로 서명할 수도 있습니다. 앱을 빌드하려면 최소 하나 이상의 빌드 유형을 정의해야 하며, Android Studio는 기본적으로 디버그 및 릴리스 빌드 유형을 생성합니다. 앱의 패키징 설정을 사용자 지정하려면, 빌드 유형 구성 방법에 대해 알아보세요.
제품 버전
제품 버전이란 사용자에게 릴리스할 다른 버전의 앱을 말합니다(예: 무료 및 유료 버전 앱). 제품 버전을 사용자 지정하여 다양한 코드 및 리소스를 사용할 수 있으며, 모든 앱 버전에 공통되는 부분을 공유하거나 재사용할 수 있습니다. 제품 버전은 선택 항목이며 여러분이 직접 생성해야 합니다. 다양한 버전의 앱을 생성하기 시작하려면, 제품 버전 구성 방법에 대해 알아보세요.
빌드 변형
빌드 변형은 빌드 유형과 제품 버전의 교차 제품(crossproduct)이며, 앱을 빌드하기 위해 Gradle이 사용하는 구성입니다. 빌드 변형을 사용하면 개발 중에 디버그 버전의 제품 버전을 빌드하거나 배포용 제품 버전의 서명된 릴리스 버전을 빌드할 수 있습니다. 여러분이 빌드 변형을 직접 구성하는 것은 아니며, 이를 형성하는 빌드 유형과 제품 버전을 구성하는 것입니다. 빌드 유형이나 제품 버전을 추가로 생성하면 빌드 변형도 추가로 생성됩니다. 빌드 변형을 생성하고 관리하는 방법에 대해 알아보려면, 빌드 변형 구성 개요를 참조하세요.
매니페스트 항목
빌드 변형 구성에서 매니페스트 파일의 일부 속성에 대한 값을 지정할 수 있습니다. 이 빌드 값은 매니페스트 파일의 기존 값보다 우선합니다. 이는 모듈에 대해 여러 개의 APK를 생성하려는 경우 각 APK 파일의 애플리케이션 이름이 다르거나, 최소 SDK 버전 또는 대상 SDK 버전이 다를 때 유용합니다. 여러 개의 매니페스트가 존재하는 경우 Gradle은 매니페스트 설정을 병합합니다.
종속성
빌드 시스템은 로컬 파일 시스템과 원격 리포지토리에서 프로젝트 종속성을 관리합니다. 이렇게 하면 종속성의 바이너리 패키지를 수동으로 검색하여 다운로드하고 프로젝트 디렉토리에 복사할 필요가 없습니다. 자세한 내용을 원하면 종속성 선언 방법에 대해 알아보세요.
서명
빌드 시스템을 사용하여 빌드 구성에서 서명 설정을 지정할 수 있으며, 빌드 프로세스 중에 APK를 자동으로 서명할 수 있습니다. 빌드 시스템은 알려진 자격 증명을 사용하여 기본 키와 인증서로 디버그 버전을 서명합니다. 이렇게 하면 빌드 시에 암호를 묻는 메시지가 나타나지 않습니다. 이 빌드에 대해 서명 구성을 명시적으로 정의하지 않는 한, 빌드 시스템은 릴리스 버전을 서명하지 않습니다. 릴리스 키가 없는 경우에는, 앱 서명에 설명된 대로 릴리스 키를 생성할 수 있습니다.
ProGuard
빌드 시스템을 사용하여 각 빌드 변형에 대해 다양한 ProGuard 규칙 파일을 지정할 수 있습니다. 빌드 시스템은 빌드 프로세스 중에 클래스를 축소하고 난독 처리하기 위해 ProGuard를 실행할 수 있습니다.
APK 분할
빌드 시스템을 사용하면 특정 화면 밀도나 ABI(Application Binary Interface)에 필요한 코드와 리소스만을 포함하는 다양한 APK를 자동으로 빌드할 수 있습니다. 자세한 내용은 APK 분할 구성을 참조하세요.

빌드 구성 파일

사용자 지정 빌드 구성을 생성하려면 하나 이상의 빌드 구성 파일이나 build.gradle 파일을 변경해야 합니다. 이러한 일반 텍스트 파일은 Groovy를 사용하는 빌드 로직을 기술하고 조작하기 위해 DSL(Domain Specific Language)을 사용합니다. Groovy는 JVM(Java Virtual Machine)용 동적 언어입니다. 필요한 대부분의 DSL 요소가 Gradle용 Android 플러그인에 소개되므로, 여러분이 Groovy에 대해 몰라도 빌드 구성을 시작할 수가 있습니다. Android 플러그인 DSL에 대해 자세히 알아보려면, DSL 참조 문서를 참조하세요.

새 프로젝트를 시작할 때 그림 2와 같이 Android Studio가 이들 파일을 자동으로 만들고, 적합한 기본값에 따라 파일에 값을 채웁니다.

그림 2. Android 앱 모듈의 기본 프로젝트 구조.

Android 앱의 표준 프로젝트 구조에 속하는 몇 가지 Gradle 빌드 구성 파일이 있습니다. 빌드 구성을 시작하려면 그 전에 이들 파일의 각 범위와 목적 그리고 이들 파일이 정의해야 하는 기본 DSL 요소를 이해하는 것이 중요합니다.

Gradle 설정 파일

루트 프로젝트 디렉토리에 있는 settings.gradle 파일은 앱을 빌드할 때 어떤 모듈을 포함할지를 Gradle에 알려줍니다. 대부분의 프로젝트에서 이 파일은 간단하며 다음 코드만을 포함합니다.

include ‘:app’

그러나, 다중 모듈 프로젝트에서는 최종 빌드에 들어가야 하는 각 모듈을 지정해야 합니다.

최상위 빌드 파일

루트 프로젝트 디렉토리에 있는 최상위 build.gradle 파일은 프로젝트의 모든 모듈에 적용되는 빌드 구성을 정의합니다. 기본적으로, 최상위 빌드 파일은 프로젝트의 모든 모듈에 공통되는 Gradle 리포지토리종속성을 정의하기 위해 buildscript {} 블록을 사용합니다. 다음 코드 샘플에서는 새 프로젝트가 만들어진 후 최상위 build.gradle에서 찾을 수 있는 기본 설정과 DSL 요소에 대해 설명합니다.

/**
 * The buildscript {} block is where you configure the repositories and
 * dependencies for Gradle itself--meaning, you should not include dependencies
 * for your modules here. For example, this block includes the Android plugin for
 * Gradle as a dependency because it provides the additional instructions Gradle
 * needs to build Android app modules.
 */

buildscript {

    /**
     * The repositories {} block configures the repositories Gradle uses to
     * search or download the dependencies. Gradle pre-configures support for remote
     * repositories such as JCenter, Maven Central, and Ivy. You can also use local
     * repositories or define your own remote repositories. The code below defines
     * JCenter as the repository Gradle should use to look for its dependencies.
     */

    repositories {
        jcenter()
    }

    /**
     * The dependencies {} block configures the dependencies Gradle needs to use
     * to build your project. The following line adds Android Plugin for Gradle
     * version 3.0.1 as a classpath dependency.
     */

    dependencies {
        classpath 'com.android.tools.build:gradle:3.0.1'
    }
}

/**
 * The allprojects {} block is where you configure the repositories and
 * dependencies used by all modules in your project, such as third-party plugins
 * or libraries. Dependencies that are not required by all the modules in the
 * project should be configured in module-level build.gradle files. For new
 * projects, Android Studio configures JCenter as the default repository, but it
 * does not configure any dependencies.
 */

allprojects {
   repositories {
       jcenter()
   }
}

모듈 레벨 빌드 파일

<project>/<module>/ 디렉토리에 있는 모듈 레벨 build.gradle 파일을 사용하면 이 파일이 위치하는 특정 모듈의 빌드 설정을 구성할 수 있습니다. 이러한 빌드 설정을 구성하면 사용자 지정 패키징 옵션을 제공할 수 있으며(예: 추가적인 빌드 유형 및 제품 버전), main/ 앱 매니페스트 또는 최상위 build.gradle 파일에 있는 설정을 재정의할 수 있습니다.

아래의 샘플 Android 앱 모듈 build.gradle 파일에서는 여러분이 알아야 하는 기본 DSL 요소과 설정에 대해 간략히 설명합니다.

/**
 * The first line in the build configuration applies the Android plugin for
 * Gradle to this build and makes the android {} block available to specify
 * Android-specific build options.
 */

apply plugin: 'com.android.application'

/**
 * The android {} block is where you configure all your Android-specific
 * build options.
 */

android {

  /**
   * compileSdkVersion specifies the Android API level Gradle should use to
   * compile your app. This means your app can use the API features included in
   * this API level and lower.
   *
   * buildToolsVersion specifies the version of the SDK build tools, command-line
   * utilities, and compiler that Gradle should use to build your app. You need to
   * download the build tools using the SDK Manager.
   */

  compileSdkVersion 26
  buildToolsVersion "26.0.2"

  /**
   * The defaultConfig {} block encapsulates default settings and entries for all
   * build variants, and can override some attributes in main/AndroidManifest.xml
   * dynamically from the build system. You can configure product flavors to override
   * these values for different versions of your app.
   */

  defaultConfig {

    /**
     * applicationId uniquely identifies the package for publishing.
     * However, your source code should still reference the package name
     * defined by the package attribute in the main/AndroidManifest.xml file.
     */

    applicationId 'com.example.myapp'

    // Defines the minimum API level required to run the app.
    minSdkVersion 15

    // Specifies the API level used to test the app.
    targetSdkVersion 26

    // Defines the version number of your app.
    versionCode 1

    // Defines a user-friendly version name for your app.
    versionName "1.0"
  }

  /**
   * The buildTypes {} block is where you can configure multiple build types.
   * By default, the build system defines two build types: debug and release. The
   * debug build type is not explicitly shown in the default build configuration,
   * but it includes debugging tools and is signed with the debug key. The release
   * build type applies Proguard settings and is not signed by default.
   */

  buildTypes {

    /**
     * By default, Android Studio configures the release build type to enable code
     * shrinking, using minifyEnabled, and specifies the Proguard settings file.
     */

    release {
        minifyEnabled true // Enables code shrinking for the release build type.
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
  }

  /**
   * The productFlavors {} block is where you can configure multiple product
   * flavors. This allows you to create different versions of your app that can
   * override defaultConfig {} with their own settings. Product flavors are
   * optional, and the build system does not create them by default. This example
   * creates a free and paid product flavor. Each product flavor then specifies
   * its own application ID, so that they can exist on the Google Play Store, or
   * an Android device, simultaneously.
   */

  productFlavors {
    free {
      applicationId 'com.example.myapp.free'
    }

    paid {
      applicationId 'com.example.myapp.paid'
    }
  }

  /**
   * The splits {} block is where you can configure different APK builds that
   * each contain only code and resources for a supported screen density or
   * ABI. You'll also need to configure your build so that each APK has a
   * different versionCode.
   */

  splits {
    // Screen density split settings
    density {

      // Enable or disable the density split mechanism
      enable false

      // Exclude these densities from splits
      exclude "ldpi", "tvdpi", "xxxhdpi", "400dpi", "560dpi"
    }
  }
}

/**
 * The dependencies {} block in the module-level build configuration file
 * only specifies dependencies required to build the module itself.
 */

dependencies {
    compile project(":lib")
    compile 'com.android.support:appcompat-v7:27.0.2'
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

Gradle 속성 파일

Gradle에는 또한 두 개의 속성 파일이 루트 프로젝트 디렉토리에 포함되어 있으며, 이들 파일을 사용하여 Gradle 빌드 툴킷의 설정을 지정할 수 있습니다.

gradle.properties
이 위치에서는 프로젝트 범위의 Gradle 설정을 구성할 수 있습니다(예: Gradle 데몬의 최대 힙 크기). 자세한 내용은 빌드 환경을 참조하세요.
local.properties
빌드 시스템의 로컬 환경 속성을 구성합니다(예: SDK 설치의 경로). 이 파일의 내용은 Android Studio에 의해 자동으로 생성되고 로컬 개발자 환경에만 해당하므로, 이 파일을 직접 수정하거나 버전 제어 시스템에 체크인해서는 안됩니다.

프로젝트를 Gradle 파일로 동기화

프로젝트에서 빌드 구성 파일이 변경되면 Android Studio는 프로젝트 파일을 동기화하도록 요청합니다. 이렇게 하면 빌드 구성 변경사항을 가져올 수 있고 구성에서 빌드 오류가 발생하지 않도록 검사를 수행할 수 있습니다.

프로젝트 파일을 동기화하려면, 변경을 수행할 때 나타나는 알림 막대에서 Sync Now를 클릭하거나(그림 3 참조) 메뉴 모음에서 Sync Project 를 클릭합니다. Android Studio에서 구성 오류가 발견되면(예: compileSdkVersion보다 더 높은 API 레벨에서만 사용 가능한 API 기능이 소스 코드에 사용되는 경우), 문제가 무엇인지 설명해주는 Messages 창이 나타납니다.

그림 3. Android Studio에서 프로젝트를 빌드 구성 파일로 동기화.

소스 세트

Android Studio는 각 모듈의 소스 코드와 리소스를 논리적으로 소스 세트로 그룹화합니다. 모듈의 main/ 소스 세트에는 모든 빌드 변형에 사용되는 코드와 리소스가 포함됩니다. 추가적인 소스 세트 디렉토리는 선택 항목이며, 새 빌드 변형을 구성할 때 Android Studio가 자동으로 만들지는 않습니다. 그러나 main/과 유사한 소스 세트를 생성하면, 특정 앱 버전을 빌드할 때만 Gradle이 사용할 파일과 리소스를 쉽게 구성할 수 있습니다.

src/main/
이 소스 세트에는 모든 빌드 변형에 공통되는 코드와 리소스가 포함됩니다.
src/<buildType>/
특정 빌드 유형에 대한 코드와 리소스만 포함하려면 이 소스 세트를 생성합니다.
src/<productFlavor>/
특정 제품 버전에 대한 코드와 리소스만 포함하려면 이 소스 세트를 생성합니다.
src/<productFlavorBuildType>/
특정 빌드 변형에 대한 코드와 리소스만 포함하려면 이 소스 세트를 생성합니다.

예를 들어, "fullDebug" 버전의 앱을 생성하기 위해 빌드 시스템은 다음 소스 세트에서 코드, 설정 및 리소스를 병합합니다.

참고: Android Studio에서 새 파일이나 디렉토리를 만들 경우, File > New 메뉴 옵션을 사용하여 특정 소스 세트에 대한 파일이나 디렉토리를 만들 수 있습니다. 여러분이 선택할 수 있는 소스 세트는 빌드 구성을 기준으로 하며, 필수 디렉토리가 아직 없는 경우 Android Studio가 자동으로 만듭니다.

동일한 파일의 다른 버전이 다른 소스 세트에 포함된 경우, Gradle은 어떤 파일을 사용할지 결정하기 위해 다음 우선순위를 사용합니다(왼쪽 소스 세트가 오른쪽 소스 세트의 파일 및 설정보다 우선합니다).

빌드 변형 > 빌드 유형 > 제품 버전 > 메인 소스 세트 > 라이브러리 종속성

이렇게 하면 Gradle은 여러분이 빌드하려는 빌드 변형에 해당하는 파일만을 사용할 수 있으며, 다른 앱 버전에 공통되는 액티비티, 애플리케이션 로직 및 리소스를 재사용할 수 있습니다. 여러 매니페스트를 병합할 때 Gradle은 동일한 우선순위를 사용하므로, 각 빌드 변형에서 서로 다른 구성 요소나 권한을 최종 매니페스트에 정의할 수 있습니다. 사용자 지정 소스 세트 생성에 대해 자세히 알아보려면, 빌드 변형의 소스 세트 생성으로 이동하세요.

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

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

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 short survey?
Help us improve the Android developer experience. (Dec 2017 Android Platform & Tools Survey)