모듈의 build.gradle을 철저히 읽습니다.

비망록도 겸해 모듈의 build.gradle의 견해를 흠뻑 해설

이번에 사용하는 샘플 gradle

apply plugin: 'com.android.application'

apply plugin: 'kotlin-android'

apply plugin: 'kotlin-android-extensions'

android {
    compileSdkVersion 27
    defaultConfig {
        applicationId "com.example.sho.gof"
        minSdkVersion 27
        targetSdkVersion 27
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            packageNameSuffix "release"
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
    productFlavors {
        dev {
            dimension "stage"
            versionName "1.0-development"
        }
        testing {
            dimension "stage"
            versionName "1.0-testing"
        }
        staging {
            dimension "stage"
            versionName "1.0-staging"
        }
        production {
            dimension "stage"
            versionName "1.0-production"
        }
    }
}

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation"org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
    implementation 'com.android.support:appcompat-v7:27.1.1'
    implementation 'com.android.support.constraint:constraint-layout:1.1.3'
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'com.android.support.test:runner:1.0.2'
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}

apply

빌드 스크립트에서 사용할 플러그인 선언

안드로이드 블록

Android 애플리케이션별 설정

defaultConfig 블록

앱 버전 관리

File -> Project Structure -> Flavors 탭에 대응

buildTypes 블록

빌드 타입의 관리와 개별의 설정을 기술(표준에서는 debug와 release, 명시적으로 release가 쓰고 있지만 debug도 유효하게 되어 있다)

예를 들어 위의 예에서는 release 만 packageName의 끝에 release라고 명명하는 것으로 구분하기 쉽다

File -> Project Structure -> Build Types 탭에 대응

productFlavors

어플리케이션별 관리에 사용

상기 예에서는 개발용(dev), 테스트 환경용(testing), 스테이징 환경용(staging), 프로덕션용(production)으로 하는 것으로, 개발에서의 동작 확인에서는 development를 프로덕션 릴리스용으로 production과 구분할 수 있습니다

그리고 이러한 buildTypes와 productFlavors의 조합에 의해, 다양한 환경의 APK 파일을 빌드할 수 있다 이 개념이 Build Variant이다.
Build Variants = productFlavors × buildTypes

Android Studio에서는 이 부분에서 조작하여 빌드하려는 환경을 지정합니다.

dependencies 블록

종속성 (도입중인 라이브러리, SDK 버전)을 작성하십시오.
라이브러리나 SDK는 Android의 대응 버전이나 다른 라이브러리와 의존하고 있는 경우가 있어, 그것을 관리하는데 사용한다

종속성을보고 싶다면,
* IDE의 오른쪽에 있는 Gradle을 클릭
* Tasks -> android -> androidDependencies 클릭
* 오른쪽 하단의 Gradle Console 확인


이런 식으로 나오면 오케이

마지막으로

모듈의 build.gradle을 흠뻑 해설해 보았습니다.
gradle의 설정은 상당히 안쪽이 깊습니다만, 잘 다룰 수 있으면 Android의 개발을 꽤 해킹할 수 있다고 생각합니다
나 자신 실력이 아직이므로 정진해 나가는 소존