본문 바로가기
프로그래밍 놀이터/안드로이드, Java

[android] Gradle Tutorial #1

by 돼지왕 왕돼지 2018. 10. 4.
반응형

[android] Gradle Tutorial #1


http://tools.android.com/tech-docs/new-build-system/user-guide

AIDL, anchor task, Android, android dsl, android gradle requirement, android plugin, androidmanifest.xml, ANDROID_HOME, applicationid, applicationId packagename, applicationIdSuffix, ARTIFACT, Assemble, assemble vs build, assembleDebug, assembleRelease, assets, broovy, build, build process, Build System, build system 의 목적, build tasks, build tool, build toolkit, build type, build.gradle, buildscript, buildtoolsversion, CHECK, ci server, Classpath, Clean, compilesdkversion, connectedAndroidTest, connectedcheck, debug, debug apk, default build type, defaultconfig, dependency management, devicecheck, Domain Specific Language, DSL, env var, gradle convention, gradle plugin, gradle tutorial, gradle version, gradle 기초, initWith, install, installall, installdebug, installrelease, Ivy, Java, JNI, jnidebug, jniLibs, lint, local.properties, Main Source, manifest 값 수정, maven, maven artifact, minSdkVersion, multi-apk, project output, project root, release, release apk, remote device, Resources, RS, sdk path, sdk.dir, source set, sourceSets, src/androidTest, src/main, targetsdkversion, test code source, test extension plugin, testApplicationId, testInstrumentationRunner, Uninstall, uninstallall, uninstalldebug, uninstalldebugandroidtest, uninstallrelease, up-to-date, versioncode, versionName, [android] Gradle Tutorial, 기본 build customization, 빌드 시스템, 빌드 툴킷, 프로젝트 구조, 프로젝트 구조 설정


Build System 의 목적

    code 와 resource 의 reuse 를 쉽게 한다.

    app 의 여러 variant 에 따라 multi-apk 를 생성하거나, 약간 다른 기능을 하는 app 을 쉽게 생성해낸다.

    build process 를 쉽게 설정하고, 확장하고, 개인화 할 수 있다.

    IDE 와 잘 연동된다.




왜 Gradle 인가?

    plugin 을 통해 custom build logic 을 만들어 낼 수 있는 진보된 빌드 시스템 혹은 툴킷이다.

    Groovy 기반 DSL ( Domain Specific Language) 을 빌드 로직을 짜는 데 사용한다.

    빌드 파일들이 Groovy 기반이며, DSL 을 통해 여러가지 custom logic 을 제공할 수 있다.

    Maven, Ivy 등을 통해 Built-in dependency management 를 할 수 있다.

    매우 유기적이다.

    Plugin 이 DSL 을 공개할 수 있다.

    IDE 통합력이 좋다.




요구사항

    Gradle 2.2

    Build Tools 19.0.0 이상의 SDK




기본 Project 설정


project root 폴더에 build.gradle 파일이 존재한다.

buildscript {

    repositories { 

        jcenter()

    }


    dependencies {

        classpath 'com.android.tools.build:gradle:1.3.1’ // Maven artifact

    }

}


각 module 의 root 에도 build.gradle 파일이 존재한다.

apply plugin: ‘com.android.application’ // android app 이 되기 위한 plugin


android {

    compileSdkVersion 23

    buildToolsVersion "23.1.0"

}



-

buildscript{ … } 은 build 를 주관하는 code 가 들어간다.

이곳의 dependencies 의 classPath 에는 Maven artifact 에 대해 dependency 를 갖는다.

Artifact 란 gradle 을 위한 android plugin 을 담고 있는 library 이다.


project root 에 있는 build.gradle 은 project 에는 영향을 미치지 않고, 전체 build system 에 대해 영향을 미친다.



-

android{ … } 에는 android build 에 필요한 모든 설정이 들어간다.

이곳이 Android DSL 에 대한 진입점이다.

기본적으로 compileSdkVersion, buildToolsVersion 2개면 된다.



-

local.properties 파일에 sdk.dir 이라는 변수에 sdk path 가 설정되어 있어야 한다.

절대좌표가 되어도 되고, env var 인 ANDROID_HOME 을 assign 해도 된다.




프로젝트 구조


-

기본 build file 은 기본 folder 구조를 필요로 한다.

Gradle 은 config 보다는 convention 을 따른다.

기본 Project 는 다음 2개의 source set 을 갖는다. 

    하나는 main source 이며 폴더구조는 src/main

    다른 하나는 test code source 이며 폴더구조는 src/androidTest


각각의 폴더 안에는 java 와 resources 폴더를 가져야 한다.

Android plugin 으로 해당 폴더에 AndroidManifest.xml, assets, aidl, rs, jni, jniLibs 가 위치할 수 있다.



-

기본 프로젝트 구조를 사용하기 어려울 때에는 구조를 설정할 수 있다.

android {

    sourceSets {

        main {

            manifest.srcFile 'AndroidManifest.xml'

            java.srcDirs = ['src']

            resources.srcDirs = ['src']

            aidl.srcDirs = ['src']

            renderscript.srcDirs = ['src']

            res.srcDirs = [‘res']

            assets.srcDirs = ['assets']

        }


        androidTest.setRoot('tests')

    }

}






Build Tasks


-

plugin 을 추가하면 자동으로 build task 를 만든다.

다음은 일반적인 task 들이다.


assemble

    project output 을 만든다.


check

    모든 check 를 수행한다.


build

    assemble 과 check 를 모두 수행한다.


clean

    project output 을 clean 시킨다.


사실 assemble, check, build 는 아무것도 하지 않는다.

그들은 실제 작동하는 task 를 추가하기 위한 “anchor” task 들이다.



-

project 에 변화 없이 build task 를 2번 돌리면 Gradle 은 UP-TO-DATE 메시지를 뿌려준다.



-

Java project 에 대해서는 다음과 같은 task 들이 있다.

assemble

    jar (output 생성)


check

    test (test 수행)



-

Android project 에 대해서는 다음과 같은 task 들이 있다.

assemble

check

connectedCheck (연결된 단말이나 에뮬레이터를 요구하는 check 를 수행한다. 모든 연결된 단말에 대해 병렬수행한다.)

deviceCheck (remote device 를 연결하기 위한 API 를 사용해서 수행한다. CI server 에서 사용한다.)

build

clean



-

Android project 는 최소 다음 2개의 output 이 있다.

debug APK 와 release APK.

이들은 각각의 task 가 있다.

assemble

    assembleDebug

    assembleRelease



-

각각의 check 는 dependency 가 있다.

check

    lint


connectedCheck

    connectedAndroidTest


deviceCheck (다른 test extension plugin 이 있을 때)



-

plugin 이 build type(debug, releases, test)에 대해 install, uninstall 하는 task 들을 생성한다.

installDebug

installRelease

uninstallAll

    uninstallDebug

    uninstallRelease

    uninstallDebugAndroidTest




기본 Build Customization


-

Manifest 에 대해 다음의 것들을 수정할 수 있다.

모든 변경 가능한 설정값은.. http://google.github.io/android-gradle-dsl/current/ 를 참조


minSdkVersion

targetSdkVersion

versionCode

versionName

applicationId

testApplicationId

testInstrumentationRunner


android {

    compileSdkVersion 23

    buildToolsVersion "23.0.1"


    defaultConfig { 

        versionCode 12

        versionName "2.0"

        minSdkVersion 16

        targetSdkVersion 23

    }

}


위와 같이 설정했을 때의 장점은 build.gradle 설정만으로 dynamic 하게 앱의 설정을 바꿀 수 있다.


def computeVersionName() {

    ...

}


android {

    compileSdkVersion 23

    buildToolsVersion "23.0.1"


    defaultConfig {

        versionCode 12 

        versionName computeVersionName()

        minSdkVersion 16

        targetSdkVersion 23

    }

}



-

Android 기본 Build Type 은 debug 와 release 2가지가 있다.

buildTypes 를 통해 이 기본 build type 설정은 물론 build type 을 추가할 수도 있다.

android {

    buildTypes {

        debug {

            applicationIdSuffix ".debug” // package name 에 .debug 를 붙여 release 와 함께 설치 가능하게 한다.

        }


        jnidebug {

            initWith(buildTypes.debug) // debug 설정을 기본으로 다 가져온다.

            applicationIdSuffix ".jnidebug"

            jniDebuggable true

        }

    }

}


buildType 은 property 수정 이외에도, code 나 resource 를 추가할 수도 있다.

각각의 buildType 에 대해 src/<buildtypename> ( 예를 들어 src/debug/java ) sourceSet 을 만들어 쓸 수 있다.

이 말은 buildType 이름이 main 이나 androidTest 등이 되어서는 안 된다는 말이다.


각각의 buildType 에 대해 assemble<BuildTypeName> task 도 만들어진다. ( 예를 들면 assembleDebug )



-

Signing 하기 위해서는 아래의 것들이 필요하다.

    keystore

    keystore password

    key alias name

    key password

    store type



-

android {

    signingConfigs {

        debug {

            storeFile file("debug.keystore")

        }


        myConfig {

            storeFile file("other.keystore")

            storePassword "android"

            keyAlias "androiddebugkey"

            keyPassword "android"

        }

    }


    buildTypes {

        foo {

            signingConfig signingConfigs.myConfig

        }

    }

}




반응형

댓글