resources 클래스의 경우

일반적으로 파일은 src/main에 놓여 있지만 debug 구축용 파일은 src/debug 디렉터리를 만들어서 설정합니다.

만약 main와 debug에 같은 정의가 있다면 (위의 그림 참조app_name debug를 구축할 때 main의 원본 <debug의 원본 극 우선순위에 따라 적용(정의가 덮어쓰기)할 수 있다.debug의 파일에서는 main의 모든 정의를 덮어쓸 필요가 없습니다. (debug로 덮어쓰려는 정의나 줄만 쓰면 됩니다.)layout 또는 drawable일 때 파일 단위로 debug 구축용 파일을 준비합니다.
debug가 아니라release가 구축할 때 원본 파일을 분리하는 경우도 마찬가지다.

Java 소스

자바의 원본 파일에 대해 main의 원본 파일은 debug 및 release와 공존할 수 없습니다.debug 구축할 때만 원본 파일을 준비할 경우 자바 오류release를 방지하기 위해서도 원본 파일을 준비해야 한다(빈public 방법 등을 설치해야 한다).

기타 debug 빌딩

debug 구축 라이브러리만 읽기

build.gradle

dependencies {
    // ...

    debugCompile 'com.facebook.stetho:stetho:1.2.0'

    // ...
}

마찬가지로 releaseCompilerelease가 구축될 때만 읽습니다.

debug 구축 시 적용 ID 변경

앱 ID가 debug/release라면 같은 터미널에서 앱이 공존할 수 없고, Fabric(Crashlytics)로 앱을 debug/release 관리하기도 어렵다.
이 경우 debug 구축 시 응용 ID의 끝에 부여.debug가 있기 때문에release 구축과 분리할 수 있다.
build.gradle

android {
    // ...

    buildTypes {
        debug {
            applicationIdSuffix = ".debug"
        }
        release {
            // ...
        }
    }

// ...
}

코드가 debug로 구축되었는지 확인

위에서 설명한 바와 같이 원본 코드나 구축으로 구분되지 않으면 일반적으로 코드if 문장으로 나누면 된다.요즘Android Studio 기반 프로젝트는 제작 시 자동으로 클래스BuildConfig를 생성해야 합니다.

예를 들어 debug를 구축할 때만 처리하면 다음과 같은 내용을 쓸 수 있습니다.

if (BuildConfig.DEBUG) {
    // ...
}

끝말

참고로 debug/release 빌딩은 안드로이드 스튜디오의 Build Variants 라벨에서 전환할 수 있습니다.

또한 상술한 모든 일에 관해서는 Product Flavor도 같은 느낌을 유지할 수 있다고 생각합니다.