안드로이드 build.gradle 파일

1. ABI(Application Binary Interface) 응용 프로그램 바이너리 인터페이스

실제로 ABI를 설정할 수 없으므로 컴파일할 때 프로젝트의 종속 리소스 패키지에 있는 모든 라이브러리가 최종 apk에 입력됩니다. 그러나 ABI 지원이 많을수록 apk가 커지므로 일반적으로 한 가지 유형만 지원됩니다. 현재 Android 버전, ABI 일반 구성armeabi-v7a.

注意：

新增so库

新增so库的话，需要在每个在用的文件夹内（armeabi、armeabi-v7a、arm64-v8a ==）放置，否则so库找不到。多个目录，目录下的so库文件数需要相同。

armeabi-v7a 和 armeabi

如果设置支持armeabi-v7a 和 armeabi：如若第三方提供的so只有armeabi，那么armeabi-v7a 内也需要拷贝一份，原因是armeabi-v7a 和 armeabi必须so数一致，且armeabi-v7a支持armeabi hardware does not support

ABI设置错误，可能出现硬件不支持的问题，提示：hardware does not support

둘, 분할 속성

1、아비

유형: AbiSplitOptions
설명: abi에 대한 도급 처리 자세한 내용은 아래 AbiSplitOptions 설명을 참조하십시오.

2. AbiSplitOptions 유형

2.1 활성화

설명: abi 하도급 활성화 여부, 기본적으로 활성화되어 있지 않음
사용:

splits { abi { enable true } } 효과 다이어그램은 다음과 같습니다.

여기에 이미지 설명 삽입

2.2 제외
설명: 불필요한 아키텍처를 제외합니다.
사용:

abi { // 활성화 여부 enable true

// 불필요한 아키텍처 제외
exclude 'x86','arm64-v8a'
}

효과 그림:

여기에 이미지 설명 삽입
2.3 재설정
설명: 기본 아키텍처 목록을 지웁니다. abi 하도급을 활성화하면 gradle이 아키텍처 목록을 초기화하는 데 도움이 됩니다. ", "x86_64".
초기화 목록은 gradle 버전에 따라 다릅니다.

사용:

abi { // 활성화 여부 enable true

// 포함된 디렉토리 재설정
reset()
}
2.4
설명 포함: 필요한 아키텍처를 설정합니다. 기본 목록을 설정하기 전에 재설정 방법을 사용하여 기본 목록을 지워야 합니다.

사용:

abi { // 활성화 여부 enable true

// 모든 reset()이 이미 포함되어 있으므로 포함된 디렉토리를 재설정합니다. // 포함을 설정합니다. 기본 포함 'armeabi-v7a', 'x86'을
지우기 위해 호출하기 전에 재설정을 사용해야 합니다. } 효과 그림:

2.5 universalApk
설명: 모든 아키텍처를 포함하는 apk를 컴파일할지 여부.
사용:

abi { // 활성화 여부 enable true

// 모든 apk
universalApk true
}
렌더링을 표시할지 여부:

셋, sourceSets 속성 - 파일 경로 구성

sourceSets { main { manifest.srcFile 'AndroidManifest.xml' // 매니페스트 파일 지정 res.srcDirs = ['res'] // res 리소스 디렉터리 지정 assets.srcDirs = ['assets'] // 자산 리소스 디렉터리 jni.srcDirs ' src/main/jni' // jni 코드 디렉토리 jniLibs.srcDir 'src/main/jniLibs' // jni 라이브러리 디렉토리 java.srcDirs = ['src'] // 자바 소스 코드 디렉토리 지정 resources.srcDirs = ['src' ] // 리소스 디렉토리 지정 aidl.srcDirs = ['src'] // aidl 디렉토리 지정 renderscript.srcDirs = ['src'] // 소스 디렉토리 지정 } debug.setRoot('build-types/debug') // 지정 디버그 모드의 경로 release.setRoot('build-types/release') // 릴리스 모드의 경로 지정

}

네, packagingOptions 속성 - 패키징 구성

패키징 구성:
1. pickFirsts: 중복 파일이 있는 경우 첫 번째로 일치하는 파일을 apk로 압축합니다.
2. merges: 중복 파일이 있는 경우 중복 파일을 apk로 병합합니다.
3. excludes: 패키징 시 일치하는 파일 제외
packagingOptions { pickFirsts = ['META-INF/LICENSE'] //직접 사용 안 함 = 기본값을 덮어쓰지 않도록 여기에 값을 할당 merge 'META-INF/LICENSE' //직접 사용 안 함 = 기본값을 덮어쓰지 않도록 여기에 값을 할당 'META -INF/라이센스' 제외 }

다섯, compileOptions 속성 - 자바 버전 구성

컴파일 옵션 {

// 여기에서 Java 버전을 구성할 수 있습니다.

// 해당 버전의 일부 새로운 기능을 사용하기 위해

}

여섯, flavorDimensions 속성 - 다차원적 이해(버전 차별화 패키징)

flavorDimensions는 "flavor dimension"이라는 단어의 문자 그대로의 이해를 통해 알고 있습니다.

"제품 맛(예: productFlavors)"과 함께 사용해야 합니다.

android { // 다른 매개변수 생략 flavorDimensions 'ENV', "DEVICE_TYPE" }

env 및 device_type의 두 가지 차원이 정의됩니다. 하나의 매개변수 하나의 차원

다차원 이해는
실제로 버전 차동 패키징의 내용을 포함합니다.3.0 이전 버전의 차동 패키징이 제조업체에 대해 더 사용자 정의된 경우 3.0 이후 버전의 차동 패키징은 기계 추가를 기반으로 합니다.유형 및 채널과 같은 일부 매개 변수는 다차원 제품이 됩니다.

즉, 이전에는 하나의 매개변수로만 제품을 설명했다면 이제는 제조업체 A 채널의 A 모델, 제조업체 B 채널의 C 모델 등 여러 매개변수를 추가하여 구성할 수 있습니다. A 등 차원이 다를수록 제품의 스타일이 더욱 풍성해집니다.

글쎄, 이론은 끝났고 다음 단계는 이해하기 쉬운 몇 가지 예를 제공하는 것입니다 연습 만이 진실을 테스트 할 수 있습니다.

새 프로젝트를 생성한 다음 app/build.gradle 파일에서 다음과 같이 두 가지 플레이버 차원("company", "channel")을 구성합니다.

defaultConfig { applicationId "com.voctex.flavorsapp" minSdkVersion 18 targetSdkVersion 27 versionCode 1 versionName "1.0" testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" flavorDimensions "company","channel" }

그런 다음 제품의 다차원 구성을 수행합니다.

productFlavors{ //쉽게 이름을 지정하되 차원 companyA{ 차원 "company" } companyB{ 차원 "company" } channelA{ 차원 "channel" } channelB{ 차원 "channel" } 에 따라 이름을 지정하는 것이 좋습니다. }

구성 후 동기화는 프로젝트를 빌드합니다.

포장 및 제작 후 그림과 같이 다음과 같은 여러 차원의 제품이 있습니다.

기업(기업)과 채널(채널)의 총 2가지 차원이 존재한다는 것을 알 수 있으며, 여기서 기업의 차원이 1순위(정렬에 대한 요구 사항이 있으며 이는 아래에서 설명함)이므로 모든 제품은 A입니다. A사의 A 채널 제품, A사의 B 채널 제품, B사의 A 채널 제품, B사의 B 채널 제품.
차원을 높인 후에는 버전 차별화의 내용이 더욱 풍성해진 것을 알 수 있다.

위에서 언급한 바와 같이 차원의 정의에 대한 요구사항이 있으며 임의적일 수 없으며 이를 확인하기 위해 아래에서 테스트를 수행합니다. 특징적인 제품의 이름입니다. 다음과 같이:

productFlavors{ companyA{ 차원 "company" buildConfigField "String","FLAVOR_NAME","\"companyA\"" } companyB{ 차원 "company" buildConfigField "String","FLAVOR_NAME","\"companyB\"" } channelA{ 차원 "채널" buildConfigField "문자열","FLAVOR_NAME","\"channelA\"" } channelB{ 차원 "채널" buildConfigField "문자열","FLAVOR_NAME","\"channelB\"" } }

여기서 한 가지 주의할 점은 BuildConfig에서 문자열 상수를 정의할 때 큰따옴표를 추가해야 한다는 것입니다.

그런 다음 이전과 동일하게 빌드하고 여러 플레이버 차원의 BuildConfig 파일에서 FLAVOR_NAME 상수를 비교하면 첫 번째 차원 회사의 값이 항상 표시되고 두 번째 차원 채널의 값이 존재하지 않으므로 생성할 때 다차원 제품의 경우 정의된 일부 상수는 항상 첫 번째 차원의 구성을 따릅니다. 결과는 다음과 같습니다.

BuildConfig.java 파일이 생성되면 app/build/generated/source/buildConfig/companyAChannelA/release/com/voctex/flavorsapp/BuildConfig.java에 있습니다.

각 차원에서 동일한 상수 값을 정의하면 항상 첫 번째 차원이 우선하며 첫 번째 차원의 정의 또는 수정만 유효하다는 것이 실험을 통해 입증되었습니다.

일곱, productFlavors 속성 - 다른 채널 릴리스 구성

productFlavors는 문자 그대로 "제품 맛"을 의미합니다. 그는 플레이버 차원과 연결해야 합니다. 그렇지 않으면 오류가 보고됩니다.

위의 예에 따라 productFlavors를 사용하여 차원에 맛을 정의하고 dimension 연결을 사용합니다.

productFlavors { // 여기에서 제품 릴리스에 대한 몇 가지 사항을 설정할 수 있습니다. // 예를 들어 이제 총 소프트웨어를 다른 채널에 게시해야 하며 // 다른 채널의 패키지 이름이 다르면 구성할 수 있습니다. here; // 다른 AndroidManifest.xml 파일을 설정할 수도 있습니다. 헤베 { } googlePlay { } 솔로 {

// applicationId는 애플리케이션의 패키지 이름으로 defaultConfig의 applicationId를 재정의합니다.
// applicationId는 AndroidManifest.xml의 매니페스트 태그 아래 패키지 값을 대체합니다.
applicationId "com.zinc.power"
// 다음에 추가됩니다. 형성할 applicationId 문자열의 끝 최종 패키지 이름.
applicationIdSuffix '.debug'
// 현재 플레이버의 차원을 지정하는 플레이버 차원
dimension 'version'
차별화된 로고 및 앱 이름 구성
manifestPlaceholders = [
   logo : "@drawable/logo_bear",
   appName : "bear",
   ]
// 구성 서명
   서명구성 서명Configs.xiaopenyou

}
}

일곱, 종속성 속성 - 프로젝트 종속성 구성

// 현재 프로젝트의 모든 종속성 지정: 로컬 종속성, 라이브러리 종속성, 원격 종속성
// 로컬 종속성: 로컬 Jar 패키지 또는 디렉터리에 종속성을 추가할 수 있습니다.
// 라이브러리 종속성: 프로젝트의 라이브러리 모듈에 종속성을 추가할 수 있습니다.
// 원격 종속성: jcenter 라이브러리의 오픈 소스 프로젝트에 종속성을 추가할 수 있습니다.
// 표준 원격 종속성 형식은 도메인 이름: 조직 이름: 버전 번호
종속성 { 구현 fileTree(dir: 'libs', 포함: ['*.jar' ]) / /Local 종속성 //원격 종속성, com.android.support는 도메인 이름 부분, appcompat-v7은 그룹 이름, 26.1.0은 버전 번호 구현 'com.android.support:appcompat-v7:26.1 .0' implementation 'com.android.support.constraint:constraint-layout:1.0.2' implementation project(':hello') // 라이브러리 종속성 testImplementation 'junit:junit:4.12' // 테스트 열 라이브러리 선언 androidTestImplementation 'com .android.support.test :러너:1.0.1'

androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
}