Ch 4: Gradle Build Flashcards
The major Gradle Files
- Project Scoped Settings file:
- settings.gradle
- defines which modules should be included when building your application
- Project Scoped Build file:
- build.gradle (Project: * )
- Specifies the repositories and dependencies for Gradle itself
- Also specifies any repositories and dependencies common to all modules
- Module Scoped Build file:
- build.gradle( Module: * )
- Configure build settings for the application
- Includes:
- dependencies
- minimum and target platform versions
- application version information
- multiple build types and product flavors
The major Gradle Files:
Project Scoped Settings File
- Project Scoped Settings file:
- settings.gradle
- defines which modules should be included when building your application
- Includes your single application module by default:
- include ‘:app’
The major Gradle Files:
Project Scoped Build File
- build.gradle (Project: * )
- Specifies the repositories and dependencies for Gradle itself
- Also specifies any repositories and dependencies common to all modules
*
The major Gradle Files:
Module Scoped Build File
- Module Scoped Build file:
- build.gradle( Module: * )
- Configure build settings for the application
- Includes:
- dependencies
- minimum and target platform versions
- application version information
- multiple build types and product flavors
The major Gradle Files:
Project Scoped Build File:
File Blocks
-
‘buildscript’ node
- Indicates repositories and dependencies used by Gradle itself - not the application
-
‘repositories’ node
- Lists repositories, google() and jcenter() by default
-
‘dependencies’ node
- inlcudes Android Plugin for Gradle by default
- classpath ‘com.whatever.*’
-
‘allprojects’ node
- ‘repositories’ and ‘dependencies’
- ‘task clean(type: Delete)’
- Deletes previous builds for a new buil
Major Gradle Files:
Module-level Build File:
File Block Structure
-
apply plugin lines
- can be multiple plugins
- By default, applies Android Plugin for Gradle
-
‘android’ block
- compileSDKVersion
- ‘defaultConfig {…}’
- ‘buildTypes {…}’
- ‘flavorDimensions’ definitions - optional
- ‘productFlavors {…} ‘ - optional
- ‘splits {…}
- ‘sourceSets {…}’
-
‘dependencies’ block
- Module-specific dependencies
Major Gradle Files:
Module-level Build File:
Default Configuration block:
Purpose and Important Values to set
android/defaultConfig
- Specifies the default settings that will be shared across all the builds and product flavors, unless overridden
- Important Values:
- applicationId
- minSdkVersion
- targetSdkVersion
- versionCode
- versionName
- testInstrumentRunner
Major Gradle Files:
Module-level Build File:
Build Types block:
Purpose and Important Values to set
android/buildTypes {…
- Used to define multiple different build types - typically ‘debug’ and ‘release’
- Contains a subnode for each build type,
- specifies build parameters
- Android Studio automatically creates a ‘release’ build type
- it applies ‘Proguard’ settings to shrink and obfuscate the code,
- does not use a default signing key
Major Gradle Files:
Module-level Build File:
Product Flavors
Basic Idea
Product Flavors allow you to override any of the values defined in the Default Configuration block.
This allows you to support different versions( “flavors” ) of the application using the same codebase.
Can be grouped according to different Flavor Dimensions.
Note: Each Product Flavor should specify its own unique application ID, so each can be distributed and installed independently
Major Gradle Files:
Module-level Build File:
Flavor Dimensions
Basic Idea
Flavor Dimensions allow you to group different Product Flavors according to some category.
This lets each Product Flavor make only the necessary changes for a specific variation.
Then, multiple Product Flavors can be mixed and matched to create a large variety of final build varients, rather than specifying a Product Flavor for every possible build variant.
Major Gradle Files:
Module-level Build File:
Splits Block
android/splits
- optional
- Configure different APK builds that contain only the code and resources for each supported screen density or ABI
- Generally best practice to create and distribute a single APK to support all target devices
- In some cases, such as in games, this makes the APK very large
- Split APKs is a more advanced technique