[android] Gradle Tutorial #1 |
http://tools.android.com/tech-docs/new-build-system/user-guide
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
}
}
}
'프로그래밍 놀이터 > 안드로이드, Java' 카테고리의 다른 글
[android] Background Optimization ( 백그라운드 최적화 ) (0) | 2018.10.08 |
---|---|
[android] Gradle Tutorial #2 (0) | 2018.10.05 |
[정리] 안드로이드 전문가 되는 법 (0) | 2018.10.03 |
[android] Java8 을 사용해보자! (0) | 2018.10.02 |
[android] Shared Element Transition Tutorial ( with transparent bg ) (0) | 2018.09.28 |
댓글